There is a quiet moment in many engineering careers. You are asked to cover a colleague’s duties for a week, and you open the notes they left behind. Sometimes the notes are generous and precise. Sometimes they are a single line. And sometimes there are no notes at all, only a message saying “call me if anything happens”, sent from a phone that will be switched off. How a team stores its operational knowledge decides which of these moments you live through. This piece compares three common ways of holding that knowledge and argues that the third, a tested runbook, deserves a place in every team’s routine.

Think of the comparison as three small stories about the same task: restoring a web service after a bad release.

Option one: the knowledge lives in a person

The first team relies on Kenji. He has been there for years, and he restores the service in about ten minutes. Watching him is like watching a calligrapher: every motion is economical and every choice is quietly informed by experience. He knows to check the queue before touching the database, he knows the old cache needs clearing, and he knows the odd reason why one particular server must be restarted last.

The strengths of this arrangement are real. Kenji is fast. Nobody has spent time writing documents. Newcomers learn by sitting beside him, absorbing the unspoken reasons as well as the actions, and they often become excellent engineers through that apprenticeship.

The weakness is also real, and it is the weakness of any single point of failure. When Kenji is ill, on holiday or promoted into a different role, the team discovers how little of his knowledge it actually shares. Apprenticeship is slow, depends on proximity and quietly excludes people who work different hours or from a different office.

Option two: the knowledge lives in scattered notes

The second team has learned from a near miss and told everyone to write things down. Over a year, a wiki fills with pages: diagrams, setup guides, copied chat threads, meeting notes and a few commands in code blocks. When something breaks, an engineer searches the wiki and finds three pages that partly overlap, two of which disagree.

The advantage over the first option is that knowledge is no longer locked inside one person. Anyone can read it. The drawback is that notes written to record what happened are not the same as instructions written to be followed. They tend to be long, descriptive and out of date, and they leave key decisions unstated. During an outage, nobody has the patience to read a narrative to extract five actions.

This is the most common state of affairs, and it is an honest attempt. But it often creates a false sense of safety: the team believes it has documentation and discovers during a real failure that the documentation cannot be followed.

Option three: the knowledge lives in a tested runbook

The third team treats instructions as a different genre. For each recurring task, they keep a short page that starts with the purpose, lists what is needed, gives numbered steps with the expected result of each, explains how to confirm success, and says exactly when to stop and ask for help. Crucially, each page has been followed at least once by someone who did not write it.

When the service breaks, the engineer on call opens the page and starts at step one. It takes a little longer than Kenji would, perhaps twenty minutes instead of ten, but it happens at any hour, with any trained person, and without a phone call. And when the page falls short, the engineer corrects it immediately, so the next person has a better version.

A side-by-side look

• Speed when the expert is present: option one is fastest; options two and three are slightly slower.
• Speed when the expert is absent: option three is dependable; option two is unpredictable; option one stalls.
• Effort to create: option one costs nothing today and a great deal later; option three needs a few hours per task up front.
• Onboarding: option one depends on apprenticeship; option three lets newcomers practise safely alone and ask better questions afterwards.
• Risk of silent decay: option two decays quietly; option three has a “last tested” date that makes decay visible.
• Cultural effect: option one rewards heroism; option three rewards teamwork.

This is not either-or

It would be a mistake to read the comparison as a verdict against experts. The best teams keep all three layers. They keep the Kenjis, whose judgement cannot be written down, they keep a wiki for background and design context, and they keep runbooks for the actions that must be repeated correctly. Each layer does what the others cannot.

What changes is the expert’s role. Instead of being the only person who can act, they become the person who reviews runbooks, notices when a page is wrong and handles the strange cases that fall outside the page. Many veterans find this a relief. Their expertise is multiplied rather than guarded, and their evenings are no longer interrupted by calls.

The human side of the change

Adopting runbooks is partly a technical task and partly a change in habits. Some engineers worry that writing everything down makes them replaceable. In practice the opposite is more common: people who document their work are trusted with larger responsibilities because the team knows the work will not collapse in their absence. The wider question of how teams adjust their ways of working is explored in this practical guide to managing cultural change around DevOps, and the advice there applies directly: introduce the habit gently, start with willing volunteers and let early successes persuade the sceptics.

Looking ahead, discussions about where DevOps is heading repeatedly return to reliability and shared responsibility. Runbooks are a humble, concrete expression of both.

How to move from option one or two to option three

1. List the five tasks that would hurt most if their usual person vanished.
2. For each, watch the expert perform it and write down every action.
3. Turn the notes into numbered steps, each beginning with a verb and ending with an expected result.
4. Add the verification step and the stop-and-ask rule.
5. Hand the page to a teammate new to that duty and watch silently; edit wherever they pause.
6. Record the date of that test on the page and name an owner.
7. Link the pages from the places people work: the on-call channel, the ticket template and the handover note.

A glance at neighbouring practice

The same comparison could be drawn in any field with recurring technical chores. Data teams, for example, face the very same choice between a pipeline guru, a heap of notes and a reliable procedure. A short passage on TheDataOps.org, a blog about the road from DevOps habits to steady data operations, shows how readily the idea travels between disciplines.

Choosing for your own team

If you are unsure where your team stands, try a simple test. Pick any recurring task and ask: if the usual person were unreachable tomorrow morning, could a capable colleague complete it correctly using only what is written down? If yes, you are probably close to option three. If the honest answer is “they would call Kenji”, you know where to begin.

The three options are not a ranking of people. They are a ranking of how safely knowledge travels. Apprenticeship passes wisdom slowly. Notes pass context imperfectly. A tested runbook passes the action itself, reliably, to whoever needs it next. When the next unexpected absence arrives, as it always does, that is the one you will be glad you chose.

Start with one task this week. Sit beside the person who knows it, write what you see, test it on a newcomer and put a date at the bottom. You will have made the team a little more resilient, and you will have given the experts a well-earned chance to switch off their phones.