Six Months of Invisible Operational Work, and The Five-Step Practice I Wish I'd Started From The Start

For around six months, I spent almost two weeks of every month on parcel label generation. Or technically, on the data behind them.

I sat at my laptop and broke our database into upload-sized batches, fed them into a courier portal, manually fixed the rows it spat back because someone, somewhere, had typed a postcode with a stray space or entered their full address twice, and emailed tech support when the portal threw a tantrum. Then I waited. Then I went back in and did it again.

This was not supposed to be my job.

We were spending more on campaign execution in courier costs than we’d like, so I went out and found a better-priced courier partner, negotiated the deal, and brought the integration in-house. The work I was supposed to do ended there - identifying the saving, securing the partner, scoping the integration, documenting it, and handing it to the data team to run.

I expected the handover to take a fortnight at most. Instead, it took around half a year, because every month a new issue showed up - a country that needed extra customs fields, an address format the portal refused to acknowledge, a new weight class we needed that wasn’t yet configured, or package dimensions that the platform rounded differently from how we did, breaking our rate calculations. And every time I thought right, now I can finally write this down, something else was not working, and I'd push the SOP to next week. But this “next week” took a while to come.

The embarrassing part wasn't necessarily the hours I spent on it - they were needed, and it was really important work. The problem was that it was invisible. The label generation could sometimes take 10 minutes and sometimes 2 hours, so it was hard to explain where my time was actually going. If I’d been wrapping the parcels myself, taping boxes, sticking labels on, my desk slowly disappearing under cardboard, people would have noticed the volume of work and how long it took. Instead, I was just clicking buttons on a laptop, trying to get the same outcome. The work would differ each time, but the result was the same.

Modern work is full of this kind of thing. There’s even a term for it, called hidden coordination work. The small, invisible tasks that keep systems running but never make it into anyone's job description. The strange thing about it is that companies tend to even reward people for absorbing this kind of complexity, which means the people holding the system together are usually the ones nobody can see. This is also a reason why people become slow at simple decisions after weeks of juggling such small operational issues - it appears that cognitive overload degrades our judgment over time.

So if you run anything yourself, maybe a team, a side hustle, a one-person studio that's turning into a small operation, you probably know this exact feeling. The little job that you originally planned to be a quick sprint somehow became a big part of your résumé, and the “I'll write it down when things calm down” promise you've made to yourself never arrives.

There's, of course, a way out. It's small, and weekly, maybe a little bit boring, and I’m sure you already know where I’m leading with this. But it works.

The Bit Nobody Tells You About Process

I believe many people in small companies imagine the process to be something stiff and corporate. Probably a 20-page document that nobody reads. They keep it at arm's length because letting the process in feels like letting the joy out, and this isn’t what small companies with motivated, driven people want.

But process, in practice, is really just the answer to a small question a member of the team may have: “How do I do the thing you just asked me to do?”

It only really shows its teeth when you keep the knowledge inside your head, unaccessible to anyone else who needs it.

What made the label process difficult to hand over for me was all the tacit knowledge surrounding it. The mentioned weird little issues, instincts, and judgment calls accumulated over months of dealing with the platform. You know - the bits you don’t realise you know until someone else asks you a question and you answer it in five seconds because your brain has already built an internal map of the problem.

The operators introducing processes are rarely trying to create bureaucracy on purpose. Most of the time, they’re trying to reduce unnecessary decision-making. They want Monday-morning versions of themselves to inherit fewer avoidable problems from Friday-afternoon versions of themselves. They want their brain back for the work that actually needs them specifically. The work they got into this for.

If you keep doing the boring or annoying thing yourself, what you're really telling yourself is “I don't trust anyone else to do this right”, which nicely leads me to the next part of this essay.

The Two Ways Small Teams Get This Wrong

There are two ways we tend to mess this up.

Trap one: "We're too early to systemise."

This is the one I fell into with the labels. Every month, I told myself the process wasn't stable enough to write down yet, because every month, something new went wrong, and how can I document a process that keeps mutating every time I touch it?

Eventually, I realised the instability was the work.

The problem wasn’t necessarily that the process was too messy to document (though it was); it was that the process depended on knowledge that only existed in my head.

In operational terms, this is sometimes called a bus factor problem - the risk created when critical knowledge becomes overly concentrated in a single individual. Founder dependency is probably the most common version of this, but it shows up in small operational systems all the time.

You tell yourself documentation is for boring corporations and that startups should run lean. Or that you'll write SOPs when you have time. But at a startup or a small company, you never have time. And so the same questions get asked, the same mistakes get made, and the same things you keep searching for for hours instead of minutes that could have been saved in one easy-to-access place.

And there is, of course, research on this. A 2010 review of 47 healthcare improvement studies found that the single biggest reason organisations failed at process work wasn’t over-engineering, but the leadership refusing to properly engage with systems work until things felt fully “ready”. Which, in practice, basically means never.

Trap two: "We need an SOP for everything."

This is when you overdo things a little bit. You build a beautiful 5-page document for a five-minute task. Maybe you map workflows you haven't yet decided to keep, or maybe you document things you've done twice and assume they'll be permanent from now on. Three months later, you probably can’t find the doc, and you're doing the thing from memory anyway, while the beautifully crafted process you spent so much time writing sits somewhere, probably in Notion, accumulating a fine layer of digital dust (is this a thing?).

This is the other failure mode of process work. Not under-documenting, but over-engineering too early. In organisational design terms, it’s what happens when structure outpaces reality. The system gets designed faster than the work stabilises.

This is what Robert Nardelli did to Home Depot in the early 2000s, and did it at a biblical scale. He brought in Six Sigma because he believed that the methodology could greatly enhance operational efficiency and profitability, and he applied it so aggressively across the organisation that it negatively impacted the company's culture, employee morale and customer satisfaction. The problem was that Nardelli’s management style didn’t quite translate well to Home Depot’s more entrepreneurial culture and was incompatible with the company’s values, which prioritised customer service and employee engagement. Sounds a bit like a horror story. Nardelli resigned several years later, but even after twenty years, the brand is said to still not have fully recovered.

This is probably why many founders and small companies are so unimpressed with documentation. Nobody wants to relive this version of “process”.

But I don’t think it necessarily teaches us that processes are bad on their own. It teaches us the importance of aligning process improvement methodologies with organisational culture and values, and prioritising employee engagement and satisfaction.

So the question isn’t whether we should have systems and use process improvement methodologies, but what they should look like to serve the people who are using them.

A Balding Welsh Cyclist Walks Into a Velodrome

In 2003, British Cycling was a national embarrassment. They had won exactly one Olympic gold in 95 years. No British rider had ever won the Tour de France in 110 years of trying. The top European bike manufacturers refused to sell to them in case their bikes looked bad by association. Imagine being so spectacularly unsuccessful that your equipment supplier ghosts you.

Then they hired Sir Dave Brailsford to fix that. Brailsford suggested an interesting idea - to improve everything by 1%, but one thing at a time. Think bike seats redesigned for marginal extra comfort, alcohol rubbed on tyres for slightly better grip, using riders’ favourite pillows in every hotel, so they'd sleep well on race weeks. There was even a surgeon flown in to teach the team the correct way to wash their hands so they wouldn't catch colds before competitions.

But that’s not all… they also painted the inside of their team trucks bright white. You may ask why, and that’s a very fair question - it was because dust on a chain apparently costs milliseconds, which, once accumulated, costs medals. So their solution was to make the dust visible by putting it on a white wall where they couldn’t avoid noticing it.

Now I’m sure all of this sounds a little extreme, but three years later, Bradley Wiggins won the Tour de France. Between 2007 and 2017, the British Cycling team racked up 178 world championships and 66 Olympic golds.

They basically went from “the supplier won't return our calls” to “the most successful run in modern cycling history” in about a decade.

These tiny changes don’t sound so silly anymore, do they?

But this is not the most interesting thing about this story, actually. Wiggins himself later called the whole marginal-gains philosophy “a load of rubbish.” He said it was the fundamentals that mattered - you get on the bike, do the work, and you're either good at it, or you're not. A strange thing to say after all this.

He does, of course, have a point. The 1% practice is useless without something to compound. If your product is bad, for example, no amount of SOP polish will save you. The compounding only works if your foundation is already doing its job. In organisational terms, this is where process thinking breaks down: when it becomes a substitute for fundamentals rather than a support for them.

So before you reach for any of this, check whether the thing you want to systemise is actually worth systemising. Is this process serving the company, or is it serving your anxiety? (Although sometimes anxiety is a perfectly good reason to write something down. A documented process is cheaper than a sleepless night.)

The “Recipe”

If you have a think and decide that certain things are indeed worth systemising, then here’s a practice that will help you do this effectively. You just need to repeat it weekly.

1. Map one process the way you actually do it, not the way you wish you did it.

Be honest with yourself and write what actually happens. Better yet, film it, talk through it, and ask AI to summarise it. And that should include the bits where you forget your password and have to reset it twice, and the bit where you copy-paste something from another email. You can use tools like Scribe or Tango to auto-capture your clicks as a step-by-step doc. Or just a simple Loom, if you’d rather walk someone through it on video.

2. The problems are the SOP.

This is the thing I wish I had understood earlier. The reason I kept postponing documentation was that the process kept misbehaving and being imperfect. But in practice, the issues I kept encountering were the most valuable content the SOP could possibly contain.

The version of the document that helps someone is not necessarily always the clean path. It's the messy path plus the catalogue of weird things that go wrong and exactly what to do about them.

If you wait for the process to stabilise before you write it down, you'll wait forever. You’re allowed to write an SOP of an imperfect process as long as it’s easy to follow.

My final document was probably 5 pages long - far from ideal, but most of it described potential issues and the reasons behind them. And the most important bit: if the reader encounters a new issue that’s not mentioned in the doc, there are contact details for the tech team so they can reach out directly and get it solved.

3. Find one thing to fix, eliminate, or automate.

Ask: is this step actually necessary? Could it be automated? Could AI handle it now in a way it couldn't last year? Could it be done at a different time of day so it stops eating into my deep work?

If you can eliminate an action, eliminate it. If you can’t, see if you can automate it. If you can’t automate it, outsource it. And if you can’t do any of the previous three, stick to the discipline.

The goal is not to do everything faster but to get it done in fewer, simpler steps.

4. Update the “recipe”.

Treat your SOP like a “recipe” written for a tired, distracted, slightly hungover (?) future version of you on a morning when you just can’t be bothered. Think short steps, plain language, maybe an embedded video where words won't carry it.

Tools like Whale and SweetProcess let you sit a recorded clip next to a checklist, often with the option to require each step to be ticked before the next one unlocks. Make it hard to do it wrong and pleasant to do it right.

5. Do it again next week, on the same day.

Same time, same calendar block, one process at a time. Some weeks, you'll cut a 20-minute task to four. Some weeks, you'll find a step that should have died a month ago. Some weeks, you'll just tidy up the “recipe” because now you know it can be done a little bit better.

Over a year, you may not have a perfect company, but you may have a company that’s recognisably less complicated than it was a year ago. And you'll have your late Friday evenings back, which is pretty much the key metric I personally care about.

Here’s Why I’m Writing About This Now

Companies are different now. Small teams do what 10-person teams did ten years ago, often with the same single pair of hands. AI gives you superpowers, sure, but only if you can describe what you do clearly enough to delegate it.

If your process lives only inside your head, neither AI nor another person can help you. Nobody can read your mind (for better or worse). It can’t do the thing the way you do the thing if the thing hasn’t been articulated properly.

And that’s the real irony right here. People spend years becoming indispensable, only to discover they’ve accidentally made themselves a bottleneck. And I think this is partly why delegation feels emotionally difficult, even when you know logically that it just makes sense. Letting go of work is uncomfortable when your identity has become tied to being the person who knows how to do the things you have been doing for a long time.

But I’m sure that you don’t want to always do the things you’re doing right now. There must be some boring stuff. Or stuff you do because you have no one else to give it to fully. And in these cases, having your process written in a clean little “recipe” is how you win. You can hand half of it to an intelligent AI model, another half to an intelligent colleague, and walk away to do the thing you want to do more.

In other words, the mentioned 1% exercise is really just a practice that makes the AI hype deliver in the way you want it to, because it’s very hard to automate what you haven’t written down in an easy-to-follow way.

How The Story Ends

Let’s forget about efficiency for a little bit. I know it’s important, but it’s not the full picture. Or at least it shouldn’t be.

The goal of SOPs and systems should be to make more space for the work that needs you specifically. You know those messy, interesting, human bits of running a company - the parts nobody else can do for you? The things that remind you why you are here, doing what you’re doing?

The boring weekly process review is the price you pay for an afternoon spent on something that you actually care about. Maybe a conversation, a new idea, or a long walk that turns into a strategy in some mysterious way. Isn’t this what you want?

As I mentioned earlier, I did eventually write the labels SOP. I think it took me around an hour initially, and then a few additional iterations over a few days until I felt ready to share it. I explained everything, embedded screenshots, highlighted the best practices, and explained how to navigate certain issues and when it was time to reach out to tech support for help. I had a quick session with a couple of members of the team to show it in real time so they could ask questions if anything was unclear, and then handed it over.

But I have to be honest. I was worried about letting this process go. I knew how much the platform acted out, and that even the tiniest mistakes could mean significant overspending from selecting the wrong dimensions or weights in the system.

This is the part of operational work that doesn’t always show up in documentation. Even when something is written down clearly, there’s still often a gap between what is documented and what it feels like to let someone else actually do it.

The first time I outsourced the process, when I went on holiday, I messaged my colleague to ask how she was getting on. She said she was fine, of course, but she had an issue she couldn’t figure out how to solve. I helped her out - it took me one minute. When I came back, I updated the doc with the extra note so the next person would know what to do.

I wish I could finish this by saying that ever since then I’ve sat at my desk with a cup of coffee, chilling in peace, knowing that someone else is doing the work, but that’s not the case.

I left the company very soon after I completed the doc and passed the process to someone else. The truth is that maybe I wouldn’t have even completed the SOP if I hadn’t already been considering leaving the company.

But this matters very little because the result is the same - someone else is handling the process, and they are doing it well.