When One Person Knows How Everything Runs

There's a person on your team — you know exactly who — who is the only one who can deploy. Who set up the servers. Who knows why that one thing has to be restarted in that one order. When they're on holiday, nothing goes out. When they resign, you'll feel it in your stomach before you feel it in your calendar.

Nobody planned this. It's the default outcome of building software with a small team, and it happens to good companies run by careful people. This post is about why it happens, what it's actually costing you (including a cost that isn't obvious), and how it gets fixed — which is not by asking that person to write documentation.

Why it happens to everyone

Early on, somebody has to get the thing running. One person sets up the hosting, wires the deployment, picks the tools, and makes a hundred small decisions in an afternoon. It works. There's no reason to write any of it down, because the person who made those decisions is right there and answers in ten seconds.

Then the company grows around that afternoon. Every new decision gets made by the same person, because they're the one with the context — which creates more context, which makes them more necessary. The knowledge doesn't concentrate because anyone hoarded it. It concentrates because they were fastest, every single time, and being fastest was the right call every single time.

That's the trap: the local decision is always correct and the cumulative result is a company with a single point of failure walking around in it.

The four costs

The person is trapped, and they know it. This is the cost owners see last and the one that most often ends badly. Being the only person who can do something sounds like job security; in practice it means you can't take a real holiday, you get interrupted during focused work, you're on call by default with no arrangement saying so, and you can't move onto more interesting work because nobody can take the old work from you. Good engineers in this position rarely complain. They just leave, and the resignation reads as sudden to everyone except them.

The team is slower than it looks. Everything queues behind one calendar. A finished feature waits for a safe evening. A one-line fix waits for a person in a meeting. Two other developers can't help with the deploy, so they context-switch to something else and lose an afternoon. Your throughput isn't set by how fast your team builds; it's set by the availability of one bottleneck.

The risk has no ceiling. Bus factor is the blunt name for it. If the knowledge is unwritten, then a resignation, a serious illness, or a bad falling-out doesn't cost you a hire — it costs you the ability to safely change your own software, for however long it takes someone new to reverse-engineer an undocumented system. That's the same job we do in a rescue, and it's not fast: taking over an undocumented codebase is weeks of careful archaeology, not an onboarding week.

The one nobody mentions: it shows up in diligence. If you ever raise money, sell the business, or sign an enterprise client with a security questionnaire, "how everything runs is in one person's head, undocumented" is a finding. It gets priced in. Buyers and investors treat key-person risk as a discount, and enterprise procurement treats an undocumented, unrepeatable deployment process as a reason to hesitate. Companies discover this at exactly the wrong moment, because that's the first time anyone from outside actually looks.

Why "write documentation" never works

Every team in this situation has, at some point, put "write documentation" on a list. It doesn't happen. Not from laziness — from three structural reasons:

1. It's always less urgent than the next real thing. Documentation competes with customer work, forever, and loses every week. It never becomes urgent until the week it's needed, and by then the person is gone.
2. The expert is the worst person to write it. Not because they can't write — because they can no longer see the steps. Knowledge that has become instinct is invisible to its owner, so the document skips exactly the bits that would trip up a newcomer.
3. It rots the moment it's written. A page describing a system drifts from the system within weeks, and a document that's wrong in unknown places is worse than none — it makes a newcomer confidently break something.

So teams write a heroic wiki page during a quiet week, feel better, and are back where they started by the next quarter. The task was never wrong. Treating it as a task was.

What actually fixes it

The fix is to stop relying on anyone's memory or discipline, and make the knowledge a byproduct of how work already happens.

Automate the path, and the automation becomes the documentation. If deploying is a script or a pipeline rather than a sequence of remembered steps, then the steps are now written down in the only place that can't silently drift — the thing that actually performs them. This is the highest-leverage move available, and it's why "we should document the deploy" and "we should automate the deploy" are the same project with different payoffs. Automate it and you get the document free, permanently accurate.

Make the environments reproducible rather than pet-like. Servers that were configured by hand, once, years ago, hold knowledge nobody can retrieve. Servers described in a file can be rebuilt by anyone reading the file.

Run a real handover drill. This is the cheapest thing on the list and almost nobody does it. Pick a Tuesday. The expert doesn't touch the keyboard and doesn't type in the chat — they may only answer questions out loud. Somebody else does the deploy. Every question asked is a gap, and the list of questions is your documentation backlog, written by the right person (the one who doesn't know), in priority order (the order it blocked them). In our experience two hours of that produces better documentation than a week of solo writing.

Rotate the boring jobs deliberately. Whoever deploys least should deploy next, while the expert is still there to catch it. Knowledge transfers by doing, with a safety net, and not by reading.

Write things down at the moment they're discovered. The five minutes after an incident is the only time the knowledge is both fresh and obviously valuable. A short honest note then beats a wiki-writing initiative later.

The test

You don't need an outside opinion to know where you stand. Ask one question: if that person were unreachable for two weeks starting tomorrow, what would we be unable to do?

If the answer is "nothing much, releases would just be slower" — you're fine, keep going. If the answer includes "we couldn't safely release anything," you have a live risk that grows quietly every month, and the growth is compounding: every new undocumented decision makes the eventual handover longer.

The honest caveat about buying your way out

Outsourcing the function is one of the ways teams solve this — it's part of what we sell, so we'll be careful here. Buying Managed DevOps from anyone, us included, solves this only if the provider documents everything as they go. A managed setup that lives in the provider's head is not a fix. It's the same single point of failure, now outside your company, where you have less visibility and less leverage than when it was your own engineer.

So ask any provider the question directly: how would we take this back in-house, and what exactly would you hand us? Expect a written answer. That question and eleven others are in the questions to ask before you hire a DevOps partner — and it's the one we'd ask first.

If you want an outside read on where the knowledge is concentrated, that's part of what our free DevOps review maps: how a change reaches your customers today, every manual step, and every point where one specific person is required. It's written down, it's free, and it's yours to keep — including if you hand it straight to the person in question and fix it yourselves. Honestly, that's a good outcome. The document is the point.

The goal was never to reduce anyone's importance. It's to make sure their importance is about judgement, not about being the only one who remembers the order of the steps.