jml's notebook
Some quick thoughts on process
A lot of people think 'process' is a dirty word. It's a form of bureaucracy, they say. It stifles creativity. It's rigid and limits our ability to adapt to changing circumstances. No one likes it.
I'm a pretty big fan of process.
Let's start by defining what I mean.
A process is a set of steps to be followed by one or more people, triggered by conditions. These steps and conditions are written down, and available to the people who must follow the process.
What's the point of this? Surely if we hire smart people and give them a goal they can pursue it in whatever way they think best.
Lots of reasons.
First, if you really award people autonomy, you must grant that one of the ways they might use their autonomy is to write down some process.
Second, there are a tonne of mundane things about a working environment that don't need to be reinvented and rethought every time. You shouldn't have to poll every person in the company to figure out how to request annual leave, there should just be a process you can follow.
Even for more complex tasks like promoting a person, it really helps to have a process for the more mundane things — who approves? what material must be submitted? when can it happen? who is informed on success / rejection? — so the interested parties can focus on being good enough at their actual jobs to get promoted. In this case, process doesn't deny individual autonomy and judgement, it enables them.
Third, written process is a great enabler of delegation. If you have a howto for running retrospectives, anyone can run retrospectives.
Fourth, written process likewise enables interactions across teams. If you have an established team then probably everyone mostly knows how things are done, or at least enough to muddle through if necessary. But people from other teams, or who are new to your team, won't know what's expected of them or what to expect of you. Managing expectations is kind of a big deal, and anything you can do to make that less onerous is a win.
Process sucks when it rules you. It should only ever be a tool (one of many!) in service of teams defining and achieving goals. How do we avoid this happening? How do we reliably tell when this is happening? I don't know, but it's something I definitely want to think about.
My favourite way to do process is this:
- if you see that there's a thing you are doing regularly, or a set of steps that you refer to by name, write it down
For example, "run a retro", "estimate that story", "announce the release".
At this stage, you just want to write down what you actually do. This document functions as a how-to, to use the Diátaxis documentation system.
Writing down the steps will almost certainly prompt a whole bunch of good ideas about how to improve the process. This is part of the miracle of writing and one of the big reasons to write it down. Make a note of all of these good ideas, but don't try to improve the process yet. We'll get to that bit soon.
This is a lot like abstraction in code. If you see enough repetition, you extract a function and give it a name. If there's a concept that keeps coming up, you make sure there's a class or function or type or whatever that represents it.
- follow the process
Use the doc to actually do the thing. This tests the doc, and provides a bunch of low-hanging fruit for improving in the quality of the doc. If possible, get someone who is not you, or even from outside your team to do this.
Thought of another way, the document isn't done until it's been used once.
- suggest an improvement
What's something we can do to improve the process? Perhaps a tonne of steps could be eliminated? Perhaps it would be useful to add an extra check? Perhaps there's a hand-off that just doesn't need to happen?
- decide how to measure the improvement
For some processes, there are obvious measures. For example, the Four Key Measures from Accelerate are pretty good ones for software.
For other processes, you might just want to take a straw poll of people's feelings before and after.
However you decide to measure, decide before you try the improvement and write it down.
- try the improvement
Set a fixed time window for trying the improvement. Update the doc with the improvement and note that it's experimental.
Try it out for the time window.
- evaluate the improvement
Did it work? What did we learn?
- incorporate or abandon the improvement
If it worked, make it part of the process. If it didn't, chuck it away.
- repeat
Keep doing this, and your ways of working will get gradually better and better. To an extent, these improvements will compound, like pushing a flywheel.
Important note for managers: Everyone on your team should be able to suggest improvements, and the decision about whether to keep an improvement should be made by the metric, not by you. If you are the only one doing this, you severely limit the aggregated intelligence available for improving your organization. Your job is not to suggest concrete improvements, but instead to guard the meta-process above, nurture an environment where everyone feels good about contributing, and to provide clear goals and values so your team knows what 'good' looks like.
This way of doing process is called "continuous improvement" or "kaizen".