Having a process doesn’t mean you get good or consistent results

A topic that keeps coming back to me is pondering about simplification of processes. What is a simple process and what is a complicated or complex process? In which constraints does it make sense to have more or less details? Just because it looks simple doesn’t mean it is simple. And just because it looks complex doesn’t mean it is complex.

I’ll start again with a wood working example or two. Let’s look at the process to build a box. A rough picture of the result is provided.

The process instruction could be:

• Take four pieces of wood of size X by Y
• Joint the corners
• Insert bottom

Or the process instruction could look like this:

• prepare your stock by milling it to 15mm thickness
• cut 4 pieces of size X by Y each, grain direction is important
  • if possible cut them from one long piece, so that you have continuous grain
  • prepare stock for the bottom by milling it to 6mm thickness
  • in the 4 pieces cut a groove on the table saw or router table with 6mm width, 10mm from the bottom edge
  • and the list goes on and on

In the end of both processes you will get a box, don’t you?

Well, the boxes might look rather differently. Or they look exactly the same.

Now what when you have to make 10 boxes? People following instruction no. 1 will come up with a more or less implicit process. People following instruction no. 2 will just continue to do so. Will the process for all look the same after box 10? Maybe. Probably not.

Another example from TV. If you know the show Great British Bake Off on British television, you might know that the second round is the “Technical Challenge”. And the recipes and ingredients provided range from measured with detailed recipes about measurements, order of steps, temperature and length to bake. All the way to more than enough from each ingredient and the instruction: Make a Genoise sponge.

The result will be a Genoise sponge, right? If someone has baked dozens of Genoise sponges in the past, they know what to do. If someone roughly knows the recipe, they might land close enough. And if someone has no clue what a Genoise even is, you might be lucky to get something edible.

The consistency of the result is all about guardrails, experience and expectations in the process. If you have a picture of the box and detailed instructions or just the vague idea of building a box, the results will defer.

A simple looking process doesn’t mean it’s easy to follow. It means you need experience to fill the gaps that are not prescribed. Is that experience always the same? I doubt it. On the other hand, a complex looking process might be easy to follow and requires less experience. Does that mean anyone can follow it? Not necessarily. There might still be knowledge, skill and practice involved.

Now look at your processes at work. How detailed are the instructions and expectations in there? I have seen e.g. bug reporting processes that are extremely detailed. Questions to answer with examples, information to provide, guidelines for evaluating impact and severity.

And I have seen processes where nothing was written down. A bug ticket type was available in the work management tool – no not Jira, back then, and the implicit expectation to log bugs when they are found. The difference in quality of the bug tickets is accordingly. The more details are provided, even the rookiest rookie was able to fill out a bug ticket with as many information as possible. In the other system, the quality ranged from “X doesn’t work” to full reproduction steps, attached database dumps, log files, etc.

In the workshop that I still regret to not have lead differently – “Quality Eats Process for Breakfast” – I wanted to guide my participants to the insight, that the quality of your process decides about the quality of the product. And when it comes to the ultimate evaluation of quality – the user’s or customer’s evaluation – it is hard to pre-bake that into the process, if you don’t have enough information. What is it that my customer values in the product? How can I take care that this is included in the result?

In my favorite example to explain to me how to make coffee – I’m not a coffee drinker – I usually get a rough list of steps how to prepare a cup of coffee. I don’t drink coffee, but sometimes I want to make a cup of coffee for someone else. Most times, with the given steps I would have produced something that reminds of coffee – a brown-ish, hot-steaming liquid. If it tastes good or not, I don’t know. After chatting with one of my best friends, a coffee lover, I learned about different types of beans, coarseness of grind for different styles of coffee, different water temperatures and pressures. The amount of coffee powder to use for one cup was defined, the size of the cup, and so on. Can I make a good coffee with these instructions. Yes, I can make a coffee and with repeatable results. And the factor “good” is evaluated by my friend. If other coffee drinkers come to the same conclusion, I don’t know.

Now think e.g. of your software development process. How detailed are certain steps defined? Do you need consistent results across people and teams? What measures are in place to get consistent and good quality results? How much training and experience is necessary to follow your process? Do you have constraints in your context that need either explicit shared knowledge between everyone involved or detailed process steps? Where is the Goldilocks zone to provide enough detail to get consistent results and enough freedom to rely on the experience and solutions by the individuals to deliver what is asked of them?

The more vague the instructions are the wider the result space will be. The more detailed the instructions are the smaller the result space will be.

My advice here is to experiment in your context. Processes can be improved like software. Improve them bit by bit. Add something, remove something. But don’t forget to tell people about the changes!

And it also depends on how narrow your result space needs to be. If the results vary too much, add more guide rails.

I’m now going into my workshop to turn a pepper mill. The instructions I have are only the exact diameters and depth for the holes and the distances between certain points. e.g. the length of the lower element of the mill. That’s the parameters set by my pepper mill instruction manual that is available from the same source where I get the mill inserts. When following these instructions, I’m sure that the result will be a piece of wood that the inserts will fit in. In the end it will be a pepper mill. But it’s up to my experience, choice of design, availability of wood, to come up with something useful and nice.
In the past I also have bought a pepper mill kit with detailed instructions. Provided was the wood, the inserts, and a 20 page set of instructions to produce the exact same mill as printed on the title.

What is simpler? The sketch with hole depths and diameters or the detailed step by step instruction?