Following processes won't make you a robot

Following processes won't make you a robot

Every time I go to teams and start talking about process mapping and standard operating procedures (SOP) I notice an undeniable amount of unease like it just got a few degrees colder.

What people hear isn’t “we’re here to understand your work and make it smoother.”
What they really hear is: “We’re here to judge, strip the creativity, maybe even replace you with a machine.”

I very much understand where the sentiment comes from, but that is very much not the idea behind a standard operating procedures and process mapping. It’s actually quite the opposite.

What are SOP’s?

Think of an SOP as a cooking recipe. Not the kind you tear off the back of a meal kit, something closer to Kenji López-Alt’s style, he kind that tells you why every step matters with decent thought out details.

A good SOP covers the outcome we want, the steps to get there, the roles involved, and the expected result. Ideally, it also tracks updates and changes, so the process evolves alongside the organization.

In many industries like healthcare, security, manufacturing, … you don’t get a choice. Regulators require SOPs, and audits enforce them. That’s the compliance side.

Beyond compliance, mapping work across teams creates a kind of contract. Everyone knows what’s being done, how it changes hands, and what “done” really looks like. You create a shared understanding of not only your work, but also the work that comes before and after.

When new people start, you can use the SOP as part of their onboarding1. This makes onboarding people so much easier and makes sure that there are no big hiccups in quality when roles change.

Stability Enables Creativity.

If I describe it like that SOPs sound like they box people in, giving the company all the control and leaving workers with nothing but routine. But that’s not the deal.

Let’s look at it differently, back to the recipe example:

Every Tuesday for years, you’ve made the same pot of chilli. By feel, no recipe needed. Then one day, you order chilli at a restaurant, and it blows yours out of the water. So you want to improve your version.

To do that, you require consistency. By standardizing the process: measuring ingredients, tracking steps. You create a repeatable baseline. And from there, experimentation becomes meaningful. Add espresso, swap peppers, try something new, and you can tell exactly what effect it had.

What we’ve described above is a form of Kaizen taking a process and, just by doing it, improving it very slightly to get a better result.

That is exactly what we want to achieve with work like this. We want to take a look at the work that’s currently being done, document it, and make sure the other work aligns to it by lowering the amount of overhead.

Focusing on the creative part.

And what about the day to day then? It’s nice that you can improve the flow, but you’re not going to improve the flow every day, what about the current job?

An SOP is not intended to map out the process 100%. It’s only intended to outline the base work. If part of your job is to go out and find the best vendors for retail, the SOP will not tell you what should be in your mails or how you do your market research.

It will just tell you to contact the vendors after you’ve done the market research. Maybe it can automate or streamline the boring parts of your job so you can focus on the interesting stuff.

If your job is fully standardized in a fully repeatable process that takes no creativity, problem-solving, or communication, then it might indeed be fully automated.

I personally haven’t seen a lot of those roles in a modern organization. In those cases I’ve always seen people being offered alternative roles (with re-training) that rely more on their problem-solving skills. You could argue that would be an upgrade.

SOPs as Memory of Innovation

If you keep a change log of your SOP’s, you also get snapshots of your organization over time, you’re building a time machine.

This is a very intriguing concept if you think about it. This can help explain, over the years, why some ways of working are in place2.

It can even help organizations reach back to procedures of the past. Say that there is a housing crash that reminds everyone of the one we had in 2001. Well let’s look what we did in 2001 to counteract these issues and what effect they had.

You probably wouldn’t reinstate those exact processes. But by having that history documented, you gain insights that can inform today’s decisions. SOPs, in this way, preserve lessons that might otherwise be forgotten.

SOP’s as a way to cement your role

I use my mapped out processes to go to the rest of the organization to tell them what I can help them with. They function as an internal marketing tool for my department.

They also give me leverage. When I ask another team for data in a certain format, I don’t sound picky, I can point to the process and say, “Here’s the full process, and we use this format”.

I understand that there is a negative sentiment regarding process mapping and SOP, especially with the rise of LLM’s. 3. But I think it’s a reputation issue that focuses on the wrong perspective of the task.

They are mainly in place to automate the boring parts, so there is more focus on the important parts. And in regulated industries, they’re not optional anyway.

If you play your cards right, you can benefit greatly from documenting and reviewing them. They can make your job more interesting and give you extra eyeballs and tools in the future.


  1. Don’t just point them to the document and have them figure it out, guide them through it ↩︎

  2. This counters Chesterton’s fence: https://frederickvanbrabant.com/blog/2025-07-11-chestertons-fence-and-paralysing-your-organization/ ↩︎

  3. You can’t train an LLM on the SOP. They are not detailed enough and the real valuable/ problem-solving parts are not covered. ↩︎

Related Posts

Enterprise architecture needs to get better at architecture strategy

Enterprise architecture needs to get better at architecture strategy

I’ve been reading a lot of strategy books these last weeks 1 (also two James Bond books, but that is probably not related to this post), and I’ve been trying to tie it to my everyday work of enterprise architecture.

Read More
Atomic commits: Telling stories with Git

Atomic commits: Telling stories with Git

I always find it amazing to see how different people create pull requests. Some people like to put every file they’ve touched into one big commit.

Read More
Communication for team leaders - Trust

Communication for team leaders - Trust

The second part of a three-part"Communication for Team Leaders". This one is about trust, letting go and delegating. I think it’s the hardest one for new managers.

Read More