Right-Size Is Not One-Size: How Process Can Be A Recipe For Failure

Most recipes are highly optimised. They are the quickest way to achieve the outcome specified. They use the smallest number of ingredients and quantity of each. And the fewest steps.

Which makes sense because when you’re cooking, any waste is obvious. You can see how much of each ingredient doesn’t get used. You instinctively know that beating the mixture for 8 hours would be seriously excessive. And if someone came and told you that you had to down tools every ten minutes for a quick meeting about progress, you would politely — but probably quite firmly — tell them to go away. You’ve got an apple pie to bake after all.

A good recipe helps you to achieve the outcome that you are looking for without any wasted time, effort, or resources. Our work processes should do the same thing — except waste is harder to spot in a work context. Or at least, it is more taken for granted.

Process! Meetings, documentation, the hoops required by your Change Advisory Board (CAB) before a release. Uploading your work tasks into Jira and categorising them. Authenticating and re-authenticating, and then two-factor authentication to get into your work systems.

Here’s the cold truth: process kills progress. Every approval, document, checkpoint, and meeting takes you away from delivery. In the real world, that means missed opportunities and lower throughput. When you are doing things that don’t help you to get to the outcome you want, then you’re burning time and energy that could be spent actually generating value from the system. Excess process is opportunity cost. Or a kind of efficiency tax.

That is not to say, you shouldn’t have process; but rather, you should have the right amount of it. You should incur cost where that makes sense in your situation. You should match the rigour to the risks and the stakes involved … 

Now, for most of us, cooking is an amateur activity. We cook in the privacy of our own home, and the worst things that can happen are injuries, a bad review from our partners, or — in the absolute worst case — food poisoning.

Even with those fairly low risks, we have introduced a bunch of processes to avoid them. We use recipes, follow the procedures, try to minimise wasted ingredients, pay attention so we don’t burn the dish, and take steps to keep our hands and utensils clean throughout.

The process helps keep us — and those eating our dishes — safe.

Safe in a work context is way more complicated, and there is a plethora of risks you might face, including:

• Technical and security risks such as production defects, service interruptions, or data breaches.
• Business risks such as wasted time and effort, missed opportunities, lost revenue, team burnout, or stakeholder dissatisfaction.
• Regulatory risks, compliance issues, or legal exposure.
• And in some contexts such as healthcare, actual lives might be at stake.

The entire purpose of our work process — of our work recipe — is to reduce those risks to an acceptable level.

Instead of checking the oven to make sure the dish isn’t getting too hot, you do QA activities before pushing to production. Instead of carefully double boiling your eggs, you have a design approval step before build. Instead of washing dishes as you go, you have a daily check-in with your team to make sure you’re all on the same page.

But risk isn’t objective. It is contextual. Two companies, even companies producing very similar product, might have wildly different approaches to risk management. Where one has a start-up move fast and break things vibe, the other could be driven by values of sustainability and caution. So, their attempt to manage that risk will be wildly different and may result in profoundly different processes. Which is only right: our rigour should match the risk and the stakes at play.

Yes, we so often need process to enable coordination and to manage risk, but it needs to be fit for purpose. Good process is your guardrails: guardrails that enable you to run as fast as possible, without incurring more risk than is acceptable.

There’s a common misconception among people who work with process that process is a net positive, or at worst, a net neutral. For them, process is seen as how things are managed and how issues are solved. Have a problem? Well, a small tweak to a process should address that, right?

Essentially, just add a few more steps to the recipe. Job done. More is always better.

Well, no it isn’t. All process has a cost.

I once worked with an amazing designer who — when writing copy for anything — would always say every word has to earn it’s place. She would advocate that every single word in the text had to be able to justify it’s own existence. And if it wasn’t contributing sufficiently, then it would be ruthlessly culled from the pack.

As someone who rather likes using many words, it was challenging at times, but I quickly became convinced that the outputs were objectively a lot better than my usually far more verbose attempts. They were easier to read, landed better, had punch.

Since then, the design concept that everything needs to justify itself has bled out into other areas of my life. Aapplying it to process is where it really shines. Every additional step, each checkpoint, each meeting should have to justify itself.

Each step needs to be improving the whole. Each step needs to reduce risk. Each step needs to enable the team to run faster, or at the very least safer. If it doesn’t, then why are we doing it?

Asking why? is at the heart of getting the level of process right. Why this step? Why these people? Why this format? Why can’t this meeting be an email? And most importantly — why are we doing this at all?

Getting process right requires us to be clear about what we’re actually trying to achieve. It isn’t just that each part of a recipe must be necessary, but also that all the steps need to contribute to achieving the outcome.

Even if you have the same ingredients, you might be trying to achieve very different outcomes. Both scrambled eggs and a cheese soufflé are mostly eggs, but you probably don’t need to refer to a cookbook if you’re just whipping up some scrambled eggs for your Saturday morning brunch. Truth is, you probably have very little formal process and just roll with the kind of cheese you have in the fridge, approximately how hungry you are, and if you have access to herbs.

And it will probably be delicious.

But if you’re aiming for soufflé, then you need more rigour. Ingredients are carefully measured to avoid weighing down the batter, and the attention given to prep is probably tripled.

Mostly the same ingredients, but a very different recipe, a very different process, and a distinctly different outcome.

This is where scrum has run into trouble. They are so enamoured with their special process, so convinced that their approach is universal, that they claim that their process works in every situation. Well it doesn’t, and the backlash we’re seeing now is very real — and arguably deserved.

The same recipe might work for multiple cooks, but it won’t work for multiple dishes. No matter how carefully you follow a Pavlova recipe, it won’t produce a Beef Wellington. And no matter how diligently you follow a process designed for high-risk healthcare systems, it is probably a massive overkill for building a startup’s MVP.

Cooking is mostly science, but there is still some art to it. You have to know when to tweak the proportions, when to add a dash of this or that, or when it needs a bit more in the oven. It’s the difference between good  …  and great.

We should take the same approach to process.

That’s because more process doesn’t automatically mean a better outcome, and best practice process might be utterly wrong for your context. It might even be complete overkill. And it might be silently wasting a ton of effort.

Which is why you should right-size your rigour.