In the last post I introduced the idea of process debt - the invisible accumulation of workarounds, legacy steps, and temporary fixes that quietly become permanent. Digitising a process full of debt does not clear the debt, it just makes it faster and more expensive. That all sounds great, but when facing the daily business-as-usual realities and constraints that we all have to deal with, what can you actually do about it?
Most process improvement starts by looking at the process. You map out what currently happens and then you try to make it better. However, that is the wrong starting point. Starting with what you are currently doing is a trap.
The right question is not "what is the process?". It is "what is this process supposed to achieve?". Not the steps. The outcome.
This is the same logic Jon McNeill describes in The Algorithm: question every requirement, delete ruthlessly, and only optimise what genuinely needs to survive. Here is how I actually apply that, in three stages rather than one. And to make it something tangible, I'll use the example of a restaurant making pizza - we all have a general idea of how this process might look, and also I'm hungry at the time of writing.
Stage one: define the outcome, properly.
A restaurant is making pizza. First of all, the outcome is not "a pizza". The outcome is "a pizza that meets this restaurant's specific promise to the customer" - the right toppings, the right base, hot, on time, consistent with the last one they had. That distinction matters, because "a pizza" can be produced a bunch of different ways with mixed results, but "this restaurant's pizza, every time" cannot. If you get the outcome definition wrong or leave it vague, then everything you build after this point inherits this uncertainty. We'll get onto management of uncertainty in future posts.
Stage two: map the essential path, top down.
Now work out what is actually required to get there. For the pizza, working backwards: serve it, bake it, prepare it, take the order.
Those are the core steps. Underneath it sits a second layer of supporting processes that the core steps depend on but do not mention - sourcing the ingredients, following a recipe consistently, having the necessary equipment available, staff having the right training. None of this is debt. It is the genuine structure the outcome requires. The point of mapping it top down, from outcome to requirement, is that you end up with a picture of what should be happening before you go anywhere near what is happening - which is the only way to tell the difference between the two once you compare them.
Stage three: now map what actually happens, and go looking for workarounds and inefficiencies.
Maybe the kitchen has quietly started setting a timer on a phone every single bake, because the oven timer shows the time but does not actually notify anyone. Maybe the kitchen has to do a manual stock take of the pantry every shift and run down to the shops, because an inventory system that should know what's in stock and what needs ordering does not exist. Neither of those steps appears in the essential path from stage two. Both of them are real, both of them are costing time, and both of them exist because something upstream is broken - a missing notification, a missing system - and somebody built a patch around it rather than fixing the actual gap. The patch is not the process. It is a scar.
Not everything that looks like friction is debt.
This is the bit people get wrong when they go looking for things to cut. A kitchen team stopping mid-shift to clean down a station is not a workaround. It is a genuine constraint - food hygiene law does not care that it would be faster to deal with the mess at the end of service. Even if you cut it for the extra efficiency, you'd find it would inevitably be added back in unless you want to be shut down by the hygiene board. The test is the same one from stage one: does this step exist because the outcome genuinely requires it (in the case 'yes' to avoid an inspection fail), or because nobody has gone back and questioned it since the day it appeared?
Now what?
So we've identified our extra steps. For each we need to ask "why does this step exist". For some of the extras they are unavoidable for regulatory reasons. These can go in our pile of "necessary evils". Some are "temporary evils", like the phone timer we talked about above - if the timer on the oven get's fixed, we won't need someone using their phone, however it is something that will need to continue for the time being until that repair happens. Some are "easy fixes" - the running to the shops last minute could really be avoided by getting more organised around stock management. However, remembering all of this can be difficult, and in a few months time these steps might have become "we've always don it this way". We will come back to the idea of a Workaround and Inefficiency Register in a future post.
You do not need to map your entire business to start this. Pick the one process that causes the most friction - the one people complain about most often, the one with the most workarounds bolted onto it - and run it through the three stages. Outcome first. Essential path second. Reality, and the gap, last.
Process debt does not clear itself. But it clears faster than most people think, once you stop trying to improve a process and start by questioning whether it should exist at all.
If any of this sounds like a process you are currently sitting on top of, let's talk through what stripping it back might actually look like.