We stopped writing SOPs and started drawing maps

Jamie Osei has run operations at the same ninety-person design studio for four years. She inherited a documentation system built around Word documents, a shared drive with folders inside folders, and an onboarding checklist that nobody had updated since the company’s previous rebrand. What she has now is something she describes as a map. We spoke to her about why the shift happened, what it actually changed, and what she would tell someone starting from scratch today. Jamie and the studio are a composite; identifying details have been altered.

Q: How long had the SOPs been a problem?

Longer than I realised at the time, honestly. When I joined, the documentation looked fine on the surface. There were proper documents with version numbers. The naming conventions were sensible. It felt like a company that had its act together.

The cracks showed up over about six months. I kept noticing that the documents and the actual work were telling different stories. Someone would follow the onboarding SOP to the letter and still spend their first two weeks asking the same questions repeatedly, because the SOP described a version of onboarding that assumed tools and workflows we had moved away from eighteen months earlier. The document was accurate to a past we no longer lived in.

Q: What was the turning point?

We hired three people in the same month, which was unusual for us. All three went through onboarding using the existing SOP. Two of them were fine; one had a miserable experience. When I sat down with her afterwards to understand what went wrong, the answer was that she had followed the SOP exactly, trusted it completely, and ended up in a tangle because steps seven through eleven assumed a project management tool we had migrated away from. The SOP mentioned the old tool by name. She had no way to know it was outdated.

That was the moment I realised the problem was structural. It was not about updating one document; it was about the whole model of having static documents that describe living processes. A document is a photograph. Processes are things that move.

Q: So what replaced them?

Maps. I use the word deliberately, because a map is different from a description. A map shows you the territory. It shows you the paths, the decision points, the places where two routes diverge. It shows you where things connect to other things. A document tells you what should happen. A map shows you what does happen and where you are in it right now.

In practice, this meant moving our core processes into a flow-based tool where each step was a live node rather than a line of text in a document. When a step changed, the map changed, and everyone running the process saw the updated version the next time they opened it. There was no versioning problem, because there was no document to version. The map was the process. If the map was wrong, you noticed immediately because it stopped working.

“A map shows you where the holes are. A document pretends there aren’t any.”

Q: What changed in onboarding?

Everything, and faster than I expected. The old onboarding took three weeks on average. Not three weeks of intensive work; three weeks before a new hire felt confident enough to work independently without checking with someone else first. The first week was structured. After that it was mostly drift: following up on things, waiting for access, figuring out who to ask about what.

We rebuilt onboarding as a map over about six weeks. Each step was explicit: here is what you do, here is where you do it, here is who you contact if this step blocks you. The map had owners at each node. If a step was outdated, the person responsible for that node fixed it. Nobody could quietly ignore a broken step because the broken step stopped the next person from progressing.

The first cohort through the new onboarding finished in five days. Not five days of the same onboarding compressed; five days of a fundamentally different experience where the new hire knew exactly where they were at every moment, what was expected of them, and what happened next. The second cohort was the same. That consistency was new. Before, two people joining in the same month could have completely different experiences depending on who happened to be available to help them.

Q: What surprised you?

The questions stopped. I mean that literally. I have a direct-message inbox that, before the maps, was full of questions from new hires and junior team members. “Where do I find this?” “Who do I ask about that?” “Is this the right process or is there a newer version?” Those questions dried up inside a month of launching the maps.

At first I thought something had gone wrong, that people were confused but not saying so. So I asked. The answer was the opposite: people were not asking because they did not need to. The map told them. The map was specific enough, current enough, and structured clearly enough that the question they would have sent to me was already answered by the time they thought to ask it. That felt like a fundamental shift in what the operations function was for. Less answering, more building.

Q: What would you tell someone starting this from scratch?

Start with one process, not a system. The temptation is to map everything at once, to do a big inventory and a big rebuild and have it all done by quarter end. That almost always collapses into a project nobody finishes. Pick the process that causes you the most repetitive pain: the one where you answer the same questions most often, the one that breaks every time someone new tries to run it, the one you are most embarrassed to show to a new client. Map that one, properly, and run it until it is reliable.

The second thing: involve the people who actually do the work, not just the people who manage it. Managers know what the process is supposed to do. The people running it know what it actually does, which corners they cut, which steps produce nothing useful, which steps are load-bearing in ways nobody documented. Their version is the territory. Your document was always just a map of someone’s intentions.

· · ·

There is a particular kind of operational confidence that comes from knowing your processes are current, specific, and being used. Jamie describes it plainly: four years in, she does not worry about what happens when someone is off sick or leaves. The map runs. The work runs. The knowledge lives in the process itself rather than in the head of whoever happens to have been there longest. That is the real return on the investment, and it is one that a shelf full of Word documents could never have offered.