Who Knows How This Works?

You're about to take a week off. First proper break in months. Before you go, you sit down to write handover notes for the person covering.

You open a blank document.

And you realise you can’t explain your own job.

So much of what you do every day has never been written down. The order fulfilment has steps you do on autopilot. The supplier you always email on a Tuesday because that’s when they’re most responsive. The quality check you do by eye before anything ships. The content sign-off process that exists entirely in your head.

You know how it works. You just can’t put it on paper in a way that someone else could follow.

So you write a half-finished document, send an email that says “call me if anything’s urgent,” and spend the whole week checking your phone by the pool.

If this sounds familiar, you’re not doing anything wrong. You’re just at a stage of business that almost everyone goes through — where the operations work, but they work because you’re there. The knowledge, the judgment, the relationships, the standards — they live in you, not in a system.

And that’s fine. Until it isn’t.

How it happens

Nobody designs an inefficient business on purpose.

You start by solving the first problem in front of you. Then the next one. Then the next. And each time, the fastest solution is you — your knowledge, your judgment, your hands. You don’t stop to document it because there’s no time. There’s always another order to pack, another supplier to chase, another deadline that’s closer than it should be.

Six months in, the business runs. Twelve months in, it runs well. But everything flows through you — your inbox, your memory, your instinct for what “right” looks like.

You didn’t build a system. You became the system.

And it works — genuinely works — right up until the moment you need to hand something over, bring someone new in, or step away for more than a long weekend.

That’s the moment most people realise the gap. When you’re building something from scratch and moving fast, the documentation always feels like the thing you’ll get to when things calm down.

Things never calm down.

The quiet version of this

This isn’t only a small business scenario. It happens at every size.

In bigger teams, it looks different. One person knows exactly how the sampling process runs — which factory needs artwork in which format, which supplier quotes in euros and which in dollars, which production manager responds to email and which one only picks up the phone.

A good team member will leave handover notes. They’ll send an email before they go that says “here’s where things stand, here’s what needs chasing.” Most people do at least that.

But there’s a difference between a handover email and a system. The email covers the next two weeks. The system covers the next two years.

The handover tells you what’s in progress. It doesn’t tell you how things are done — the process, the standards, the decision logic, the relationships. That knowledge walks out the door with the person, even if they’ve left a perfectly good out-of-office on.

And most of the time, that’s manageable. Things slow down for a week. Someone figures it out. Life goes on.

But occasionally — when a key person is off at a critical moment, or leaves without much notice, or when the business grows faster than the team can transfer knowledge — the gaps get expensive. A sample sign-off that gets missed. A supplier who doesn’t get chased. A quality issue that the previous person would have caught, but nobody else knows to look for.

Those gaps add up.

What “documented” actually means

“Document your processes” sounds like a corporate consultancy buzzword. Something a LinkedIn post tells you to do but nobody explains how.

Let me be specific.

A documented process isn’t a 40-page handbook. It’s not a Notion board with seventeen linked databases. It’s not a project management tool that nobody opens.

It’s the answer to one question: If I disappeared tomorrow, could someone else do this job using only what’s written down?

Not perfectly. Not exactly the way you do it. Well enough that nothing falls through the cracks for two weeks.

That’s the bar.

For most product businesses, the answer is no. The knowledge lives in the wrong place.

Here’s what “documented” looks like in practice:

Supplier information that lives somewhere other than your inbox. Who makes what. What their MOQ is. What their lead time is. Who your contact is. What the payment terms are. When you last ordered. Whether they were any good. This doesn’t need to be fancy. A spreadsheet with one row per supplier and the key details filled in is enough. The point is that someone else can open it and know who to call.

A process for the things that happen every week. How orders get fulfilled. How content gets published. How samples get approved. Not every edge case — just the standard flow. “Order comes in → check stock → pack → ship → update tracker.” That’s a process. It’s four steps. It takes ten minutes to write down. And it means someone else can do it on a Monday morning without asking you twelve questions.

A record of decisions that have already been made. What was approved. What was rejected. What the colour reference is. What the price was agreed at. Where the approved sample lives. Most businesses have a tracker of some sort — the problem is when a decision gets confirmed over email or in a meeting and the tracker doesn't get updated. Six weeks later, nobody's sure whether sample 2 or sample 3 were signed off and someone has to go hunting through an inbox to find out.

Quality standards that exist outside your head. What’s acceptable and what isn’t. Where the tolerance sits. What you’d reject and what you’d accept. If you’re the only person who can look at a product and say “that’s not right” — and you can’t explain what “not right” means to someone else in specific, measurable terms — then your quality control is you. And that doesn’t scale.

None of this requires software. None of it requires a consultant. It requires someone — usually the person who knows the most — to sit down and write it out. Which is the hardest part, because that person is usually the busiest person in the business.

The running train

Implementing systems in a product business that’s already operating is like servicing a train while it’s moving. There are orders to fulfil, deadlines to hit, suppliers waiting for answers. The market doesn’t pause because you’re reorganising your internal processes.

You have to work on the systems while running the business at the same time. And when you’re already stretched, that feels impossible.

Here’s what I’ve learned from doing this across multiple businesses: you don’t have to document everything at once.You start with the thing that would hurt most if it disappeared tomorrow.

The process that only one person knows. The supplier relationship that lives in one person’s inbox. The quality check that happens in one person’s head. The weekly task that nobody else has ever done.

Document that one thing. One page. One process. Then move to the next one.

You’re not building a handbook. You’re building insurance — against illness, against resignation, against needing to take five days off without the whole thing stalling.

The question to ask this week

Look at your business — or your team, or your department — and ask:

If the person who knows the most about how this works wasn’t here next Monday, what would break first?

That’s your starting point.

Not the long-term systems project. Not the full operational handbook you’ll get to someday. The one specific thing that would break first.

Write that process down. One page. This week.

Next time someone takes a week off, or someone new joins, or you finally get that holiday — the business doesn’t stall because the knowledge walked out the door with you.