 15 extra seconds and I'm super excited about this. I'm a documentation mercenary, which means that you could hire me to come write your documentation instead of making your developers do it because I am cheaper and better than they are writing documentation. All right, let's talk about docs and DevOps. This talk is called Fear of the Bus, and it's about how we need to do documentation even though you haven't hired me yet and you may not ever. You still need to do documentation. It turns out, sorry people. So in development and ops and DevOps, we're always running as fast as we possibly can to get everything done only a little bit late. We're always running to catch up and we never feel like we have time to slow down and do documentation or anything silly like that because we don't have time. But it turns out the human memory is a lot like RAM. And if you lose the person who knows where everything is, it's like all the pointers to anything you have written down is gone. Even if they put it in a wiki, God help you, nobody knows which wiki page they put it in. So in IT, we have this thing called Fear of the Bus, which is if someone gets hit by a bus, what happens to your organization? Do you go under because no one knows how to make a build the way that one person knew how to make a build? The obvious solution is to hire a writer to chase your DevOps team around and make them write things down and then put them in human understandable language, but we all know that's not gonna happen because that's money. And nobody wants to spend money. When you are a figure skater, your coach makes you skate backwards around the rank in the way that you don't usually go and you whine about it because it's unusual. When you're in DevOps, you need to make people do the thing that is unusual for them because that's how you're going to find out where they're weak. Everybody on your team needs to be switching positions and trying new things out. If you've ever done a 100 push up program, it's super painful to build those muscles. But it turns out that once you do them, you get amazing guns and I want you to make your team amazing. Because News Flash, most of us work in corporate America and we never know who's the next rabbit to vanish. We never know what's gonna happen next. And it could be that you don't get to hold on to your senior expensive person and you get a bunch of juniors. As a technical writer, I care a lot about the horizontal and the vertical and the kerning and the task based process. I really care about how my documentation looks. But as a DevOps writer, I really don't give a fig for what your documentation looks like. All I want is it written down and I swear to you, I think the best way to do it is to put it in one giant file, just add new things to the top and scroll it down. That way everybody has one bookmark to look at and they can search on it and find something. This is Basalmic, it's my favorite design tool because it looks really ugly and sketchy and it turns out if you give somebody something nicely finished and polished and colored, they never want to change it and they bike shed. But if you give them something ugly, they'll work on it. So I want you to give everybody a chance to put things in this one scrolling document and make it ugly and then search on it. Because it turns out that here in the future, search is actually a really reliable way to find things. Because unless you have security issues, you are practicing security through obscurity on your own organization by hiding things in antique wikis or in people's memory. One of the cool ways I've seen people to handle this is by putting a unique emoji in a Slack channel every time somebody says we should put that in the build book, they just put a little emoji by it. And then you can search through on that emoji and find the things that need to get documented. But you have to figure out where your team is and put documentation in front of them so it is more of a pain in the ass for them to avoid the documentation than it is for them to do it, since they don't want to be doing it. Figure out where your team is and put it in front of them. How do you know you've succeeded? You invoke the chaos monkey. You take away somebody's phone, you turn off all their access, you say have a vacation day, a real vacation day, you're not on call. And something is going to go wrong. It's gonna be a disaster. It will be a tire fire, you won't be able to build or you won't be able to deploy or something will go terribly wrong. But you know what? It's a drill, you're prepared for that. Now you know what it is that you didn't know, you didn't know. You found your blind spot because if Maria is the one key point and you can't find her stuff during the drill, at least you know that now and not when she's in the hospital doing something else, more important. None of you had better ever call a hospital to track somebody down for this. In conclusion, you should do docs for your DevOps because otherwise you end up writing the equivalent of the Hindenburg picture on your status uptime page and nobody wants to do that. So write it down before it becomes an emergency. And if you would like to talk more about this, I'm gonna do a open space and we're gonna do an ask me anything and we're gonna talk about how I can make your documentation better in like five minutes. So thank you very much.