The faintest ink is better than the strongest memory.
– Chinese proverb.
The value of good documentation grows as organisations become increasingly technical and distributed. Without it we are prone to mistakes and can lose time explaining things and training people. This puts potential brakes on efficiency, output and growth.
However, not all documentation is good documentation.
If it won't provide potential value in future, maybe you shouldn't write it. Take meeting notes for example: there is a balance between scribing every word of the conversation for future reference, and scrawling a few vague words that won't mean anything when read back. For most settings, meeting notes can be structured according to a simple template, covering key items like agenda, actions and attendees – there are loads of these free online.
That elusive balance, between over- and under-documenting, might be solved with an agile approach...
The much-lauded Agile Manifesto encourages "working software over comprehensive documentation"... yet good agile teams are obsessively good at documenting their work. This is not a contradiction. The documentation process itself can be optimised along a more "agile" path by habitually aiming to keep documentation minimal, intentional and created continuously by the people with their hands dirty in the build.
<aside> 👓 Read: → Why agile teams should care about documentation, by TechBeacon. → Documentation in Agile: How Much and When to Write It?, by InfoQ.
</aside>
<aside> 🤝 Related: The Agile & Lean section of the playbook covers those frameworks in more general terms.
</aside>
As some pioneers go through their working lives, they develop the habit of writing down what they do, how they do it and what they are learning along the way. They don't just write it for themselves, they structure their documentation in a form that others could understand and pick up where you they off. In a rather dark sense, it's reminiscent the old phrase, "if I got hit by a bus tomorrow... [would someone be able to replace me?]" Even if you keep it private for the time being, everyone should consider writing their own Bus Book as they work, learn and grow.
A handbook-first organization is home to team members who benefit from having a single source of truth to lean on. This type of organization is able to operate with almost supernatural efficiency. An organization that does not put concerted effort into documenting has no choice but to watch its team members ask and re-ask for [the] same bits of data in perpetuity, creating a torturous loop of interruptions, meetings, and suboptimal knowledge transfers.
– From GitLab's Guide to All-Remote, by GitLab.
Teams performing complex functions with members that specialise in different parts of the process are mired by the difficulty of efficiently handing work from one role to the next. With increasingly technical roles entering mainstream work, this problem could be growing. But it is also countered by a trend towards tools and processes that minimise handover pains. This trend could be pointing towards a place in which the boundaries between each team member's work become so blurred we will no longer see meaning in the word handover.
We see this development playing out in modern digital product teams. Here, the old paradigm goes: