The Power of Writing Shit Down
A Reputation of Drudgery, a Culture of Enablement
Wandering in the Desert…
Eschewing documentation and other written communication has somehow become a badge of startup honor.
Maybe this isn’t surprising since the entire industry appears to believe its ability to innovate stems from its lack of “process”, or “management”, or “structure”. Meanwhile, documentation’s main purpose is to prove the existence of, explain, or help enforce all those things. There’s also that age old argument that documentation isn’t “agile” or “efficient”; that it’s a “waste of time” versus “real” work like coding, writing emails, or whatever other kind of type-y typing thing you do in your specific role.
But arguing that you should be coding a service, selling a product or running an organization without proper documentation is just logically, well…dumb.
It’s like arguing that you can get from San Francisco to Galsgow, Montana faster without a map.
Not having a map just means it will take longer to figure out when you’ve made a wrong turn and harder to communicate to your driver what directions you need to take from here to reach your goal.
A map gives you and your team a conceptual foundation for the task you are trying to complete. It’s a concrete tool that you can use to illustrate your reasoning and creates common ground in the the conversation. Otherwise you each have to rely on your individual mental/abstract notions of something, which are always more wishy-washy, and basically guarantees you are going to end up talking past each other half the time.
Not having clear documentation of your company or product’s processes or instructions puts you in the same situation. It just means you have no shared conceptual foundation for what you are trying to do together, and no concrete way to explain it to anyone else effectively. Just like without a map you are likely to make a lot of wrong turns and have to cover the same ground again, without documentation you are forcing your teams to figure out the same information over and over from scratch.
What a waste.
But, but, but…this one time…
Stop. I already know what you’re thinking.
Yeah, yeah, I’ve seen it: Documentation is stupid, and then the whole building burns down. Stapler.
Just hear me out: Documentation, like sprints, code reviews, or meetings, is just a tool. A tool to help you leverage your entire team’s efforts in a certain direction — to help you all accomplish more impact with less total cognitive effort.
It’s a means, not an end in and of itself. And like knives or cars, a culture of documentation can be really useful to achieve the ends it was meant for…and really dangerous when used for anything else.
So yes, there’s a point where having to document TOO much is going to slow you down, reduce your flexibility, and prevent you from solving problems when they need to be solved. But I don’t think any startup has ever reached that point. Ever. In the history of startups.
More likely the pain you’ve experienced in the past has to do with the “having to” part of that sentence. Being forced to document the wrong things at the wrong times for the wrong audience — being forced to do something you know in your gut isn’t effective — that’s is not a culture of enablement. It’s not a means to the end of getting your team on the same page and helping them move faster in the future.
That is just crappy, command-and-control management. Don’t blame documentation for that shit.
Good documentation practices are not static or arbitrary requirements. They are part of the culture of your organization. Just like the rest of your organizational design and culture, what needs to be documented, how and when will change over time.
Documentation is a tool you keep honing as you keep growing. And if you do, documentation makes your team more efficient and more agile, because they can focus on solving new problems, together, instead of rehashing old, undocumented problems over and over again in the wilderness.
When to get started
My rule of thumb is simple: if I have to have explain something more than three times, writing that thing down goes to the top of my list of things to do. At that point it’s clear that making the transfer of this information more scalable can only save me time going forward.
If you extend that to the org level, you’re looking for that point where a decent chunk of the company’s interactions are over repetitive topics, or where a decent chunk of the topics you interact with seem to be hitting this “three times” rule. Let’s say a “decent chunk” is about 20%, because it’s only going to increase exponentially with every person you add to the team and every feature you add to the product. A culture of documentation takes a while to build, so you need to start encouraging and enabling it at the first signs if you want to avoid it tanking your product velocity down the line.
Do not make the mistake of thinking that what it takes to survive is the same as what it takes to thrive.
I’m totally willing to believe that there is some mystical time in an early startup when documentation really ISN’T worth it. Before you reach product market fit maybe you’re changing the product so rapidly and the team is so small that it’s more efficient to just talk about it than write it down.
The cost of conversing about something is always less than the cost of writing it down, so if the information doesn’t need to be shared outside of immediately present people, writing might not be worth it.
But let’s be clear, that’s a tiny, minuscule period of a startup’s life that ends sub 50 employees. I know it feels way more important and crucial than that when you have experienced it…but it’s actually not.
Startups keep trying to take that mythical time and stretch it out WAAAAAAY farther than it has any right to go. A 100 person company should not be following the same rules as when you were working out of your parent’s basement (or your 4-star, VC-funded co-working space. Whatever.). Do not mistake what it takes to survive initially as the same thing as what it takes to thrive.
Literally, if you have the downtime to be reading this post, you probably aren’t in that life or death period of startup birth.
And let’s be honest, if you had known you were going to find market fit, and this product was going to survive, it would have been worth writing things down even then. Everybody that joins the company later is going to wish they had the context from those early conversations to help them do their jobs better. Survival might have necessitated skipping the documentation at the time, but that doesn’t mean there wasn’t any value in the documentation at all.
You know what they say, there’s no time like the present to start writing your shit down!
