The processes you haven't written down
are running your company

The first operations team we embedded with had fifty-seven documented processes. We counted. They had a wiki, an SOP folder, a pair of Confluence spaces and a very tidy Notion workspace. The documentation was, by any reasonable measure, excellent.

It was also almost entirely irrelevant to how the work actually got done.

On the third week, we asked the team lead to walk us through how the company onboarded a new enterprise client. She pulled up the runbook, a nine-page document last updated four months earlier, and started reading. Halfway down page two she stopped, laughed, and said “nobody actually does it this way.” What she did instead took us another six weeks to piece together. It involved a Slack thread with three specific people, a spreadsheet kept on one laptop, and the habit of forwarding a particular email to a particular address before anything else happened.

None of it was written down. All of it was load-bearing.

01 · The phantom layerWhat we mean by “unwritten”

Every company we studied ran on two sets of processes. The written set: policies, SOPs, runbooks, onboarding docs, the things you would show a consultant. And the unwritten set: the habits, heuristics, side channels and personal routines that actually decide whether work gets done. We started calling this second set the phantom layer.

The phantom layer is not a bug. It is how people adapt to reality, to the way a system works today rather than how it was supposed to work last year. Most of it is quietly excellent. Some of it is genuinely dangerous. All of it walks out the door when the person who invented it leaves.

We ran that diagnostic at a logistics firm in Bristol after the COO insisted their dispatch process was “watertight, honestly, we wrote it up last year.” Five dispatchers, five answers. Two of them involved a WhatsApp group the COO did not know existed. One ended with the sentence “and then I ring Dave, because Dave always knows.” Dave had been there nineteen years. Nobody had asked Dave what he knew.

“The best people in any operations team are the ones who have internalised enough of the phantom layer that they stop seeing it. Which is also why, when they leave, nobody can describe what they did.”

— Field notes, Company B, Week 14

Across four companies and roughly two hundred people interviewed, we found the same four signals that a process had slipped into the phantom layer.

• It is named after a person or a day, not a function. “The Maria email.” “The Friday thing.” “The audit folder dance.” If a process is referred to by who does it or when it happens rather than what it does, it does not have a home.
• Exactly one person knows how it really works. Everyone defers to them, quietly, even when the documented owner on the org chart is someone else entirely. They are rarely senior. They are often the person who answers the phone.
• It survives tool migrations untouched. The company moved from one system to another and this particular workflow carried on unchanged, because it was never really in the tool to begin with. It lived in habits and headers and a shared drive folder called “misc.”
• Nobody can explain why step three happens. It just does. Removing it feels risky. Nobody remembers what it is guarding against. In two of the four companies we worked with, step three was guarding against a bug that had been fixed years ago in a system that no longer existed.

Each signal on its own is easy to dismiss. Together they describe roughly a third of the operational work at every company we looked at. In one case, a Leeds-based insurer we spent four months with, we counted the unwritten steps in a single claims-handling workflow and reached thirty-one. The written SOP for the same workflow had nine. Nobody had lied. Nobody had been sloppy. The SOP had simply been written in 2021, and the work had moved on without it, as work always does.

The thing that made us take it seriously was not the gap itself. It was that the gap was invisible from any vantage point other than sitting next to the person doing the work. Looked at from a dashboard, the process was healthy. Looked at from the wiki, it was documented. Looked at from the org chart, it had an owner. Looked at from the chair of the person actually doing it on a Tuesday afternoon, it was a twenty-minute manual scramble held together by muscle memory and a stickied note on the side of a monitor.

02 · The audit that went sidewaysWhat happens when nobody notices

Company C was twelve weeks out from their annual SOC 2 audit when we started working with them. On paper they were ready. The wiki was up to date, the policies had been re-signed, the quarterly access review had been completed and filed. The COO walked us through the evidence pack with justified confidence.

In practice, the person who actually ran the quarterly access review had left six months earlier. Nobody had quite replaced her. The review still happened, in a fashion. Two different people did parts of it. Neither was sure who owned which bit. The sign-off trail was held together by a Google Doc and goodwill.

We noticed it because we asked to see the most recent review live, rather than reading the output. The screen share opened on a spreadsheet that lived, inexplicably, on a laptop belonging to a customer-success manager named Rita. Rita had inherited the spreadsheet from Jordan. Jordan had been the original owner of the review. Jordan had left in October. When we asked Rita how she knew what to do with the spreadsheet, she shrugged and said Jordan had walked her through it once, on Zoom, for about twenty minutes, three days before his last day.

The audit did not fail. It went through, on time, with three finding-level issues. Two of them were about the phantom layer, not the documented one. Closing them took three further weeks of work that nobody had budgeted for.

The lesson was not that the audit nearly collapsed. It did not. The lesson was quieter. The real risk of a phantom process is rarely that it breaks dramatically; it is that it keeps not-quite-working, and the cost is absorbed by five or six people who hold it together through sheer goodwill. You do not see it in a dashboard. You see it in the eyes of the person who has been staying late on Thursdays for three months to catch up on something nobody asked them to do.

That is the quiet failure mode. It does not show up until the goodwill runs out, or the person does.

We have seen both. At one of the other companies in the study, a finance analyst we had flagged as carrying an unreasonable amount of phantom work handed in her notice the week after a reorganisation. Three processes she had quietly owned came unglued inside a month. One of them, a weekly reconciliation between two billing systems, was not noticed for six weeks, by which point the divergence was several hundred thousand pounds. Nothing had been stolen. Nothing had gone truly wrong. Two numbers had simply stopped agreeing, and the human who had kept them in step was no longer there to do it.

The recovery was straightforward, if dull. The lesson was harder. The finance team had known, at some level, that the analyst was holding the reconciliation together. They had simply not known it was a reconciliation. They had thought it was a spreadsheet.

· · ·

03 · The pen is not the pointHow to write things down without making it worse

The obvious response, when you first notice the phantom layer, is to try to drag it into the light. Write it all down. Document everything. Run a big six-week mapping exercise, print the results, put them on a wiki, declare victory.

This almost never works. We watched it fail three times before we started paying attention to why.

There are three recognisable failure modes, and most documentation projects slip into at least one of them.

• The museum. Correct on the day it was written. Immediately out of date. Admired by whoever commissioned it. Used by nobody. Every company we worked with had at least one museum, usually stored somewhere with a name like “Operational Excellence” or “The Playbook.”
• The monument. A single, heroic document nobody can read through, let alone find their way around. Often a forty-page PDF, often produced by a consultant, often printed, occasionally laminated. Beautifully indexed. Completely inert.
• The aspirational summary. What one person thinks should happen, not what does. Written in confident prose, usually by someone who has not done the work in years. Invariably contradicted by the people who run the process, but only in private.

What works looks less like a project and more like a habit. It does not start with a whiteboard session. It starts with a Tuesday.

Watch a Tuesday

Do not begin with a workshop. Begin by sitting next to a mid-tenure person, ideally someone who has been in the seat long enough to have developed workarounds but not so long that they have stopped noticing them. Shadow them for a day. Say almost nothing. Watch where they click, who they message, which tab they switch to when the first system is slow.

The goal is not to capture the ideal version of the process. It is to capture the actual one. If the real version involves pasting a customer ID into a chat with a specific colleague and waiting ninety seconds for a reply, the map says so. If it involves exporting to CSV because the reporting tool lies on the last day of the month, the map says so. You are not describing what the process should be. You are describing what it is.

This sounds easy. It is not. The instinct to tidy is very strong. Resist it.

Capture, don’t compose

Write what you saw, not what you wish you had seen. Raw is fine. Ugly is fine. A bulleted list of twelve messy steps, three of them annotated “ask Priya why,” is more useful than a polished four-step diagram that is quietly wrong.

Polishing is a separate, later act. It happens once the messy version has survived contact with the people who actually do the work. If you polish first, you lock in the errors. If you capture first, you surface them. The order matters more than most teams appreciate.

One small tactic: have the person being shadowed read the raw notes back to you the next morning. They will correct between six and ten things. Those corrections are the map. The original notes were only a scaffold.

A second tactic, which sounds pedantic and is not: capture the artefacts, not just the actions. If the process produces a file, keep a copy of the file at each stage. If it produces an email, keep the email. If it produces a Slack message, keep the Slack message. The artefacts are the only bit of the phantom layer that cannot lie. People misremember what they did. Files do not.

Make the map the thing people use

This is the point most documentation projects miss, and the point on which the whole exercise turns. Documentation survives when doing the work requires opening it. If the map sits in a folder nobody visits, it will be out of date within a month, regardless of how good it was on the day you wrote it. If the map is what people click to start the work, it stays current because it has to.

Concretely, in three of the four companies we worked with, the thing that made the phantom layer stop regrowing was moving the process into a tool where the steps themselves were the documentation. Not a wiki that described the work. The work. A runnable flow with checkboxes, owners, evidence fields, the lot. Open it, tick the boxes, and the artefact is generated as a side effect. If a step is wrong, you notice immediately, because it stops you doing the next thing. Documentation that punishes you for ignoring it stays true. Documentation that you can ignore, you do.

04 · Six months inWhat it looks like when it works

Company A is the one we have worked with longest. Fourteen months, as of this month. When we started, they had a diligent COO, a sprawling wiki, and a quiet anxiety about three specific people taking extended leave at the same time. None of the three were senior. All of them were load-bearing in ways the org chart did not reflect.

Today, roughly eighteen of their core processes live as running flows rather than as documents about flows. The wiki still exists. It is smaller, and almost all of what remains is reference material: policies, rationale, the “why” behind things. The “how” lives in the flows themselves, because that is where the work happens.

Two of the three people we worried about have since left the company, for ordinary reasons, at ordinary notice periods. Things kept working. Their replacements were productive inside a fortnight, which is unusual in their industry. The COO later told us, in a tone somewhere between relief and mild disbelief, that the handovers had been the calmest she had ever run.

None of this is magic, and it would be dishonest to pretend otherwise. It is twelve months of steady, unglamorous work. The first three months at Company A produced almost nothing visible. We mapped two processes, badly, and had to redo one of them. The real shift happened somewhere around month five, when the ops team stopped thinking of the flows as documentation and started thinking of them as the work itself. That was the quiet turning point. Before it, every conversation was about writing things down. After it, every conversation was about doing things, and the writing happened on its own. They are not “done,” because processes are not projects, and anyone who tells you otherwise is selling something. Next quarter another function will outgrow its flow and somebody will have to sit next to them on a Tuesday again. That is fine. That is the job.

The conversation has changed, though. They do not talk about documenting things any more. They talk about running them, and the documentation happens as a side effect of running them well.

“We used to have a shelf full of runbooks nobody read. Now we have a handful of flows everyone uses. There is a lot less shelf.”

— Operations lead, Company A, March 2026

The shelf, it turns out, was the problem. The shelf implied the work of knowing was separate from the work of doing. Once that separation collapses, a lot of other things get easier. Audits. Handovers. Training. Holiday cover. None of them became trivial. All of them became tractable.

· · ·

Your company has a phantom layer. It has one right now, as you read this. The question is not whether the unwritten processes exist; they do, and they are doing a great deal of quiet, useful work that nobody is paying attention to. The question is whether you can see the phantom layer clearly enough to decide, deliberately, which parts of it to honour, which parts to formalise, and which parts to retire.

None of this is an indictment of anyone. The people who built your phantom layer are, by and large, the people who kept your company upright while it grew faster than its documentation could. They are not the problem. They are the reason you still have a company. The task is not to scold them or replace them; it is to make what they know visible enough that it does not leave with them.

That is a choice worth making on purpose. Most companies make it by accident, usually on the Tuesday somebody hands in their notice. The next essay in this series, Ownership is not a job title, looks at the quiet mechanics of ownership: how processes get handed from one person to another, why the thing most teams call a handover is not really one, and what to do about it before the next person leaves.