4 years ago I became an engineering manager.
When I started, I thought processes were the solution to everything. One problem? Design the right process - it won't happen again. Bad work? One process will fix it.
Well, you can guess, it didn't work.
For a process to be effective, it requires constant monitoring. People need to understand it, adopt it, and follow it. It is never perfect. You will always be fine-tuning it. And it is expensive - in time, in energy, in attention.
Also, beware of overreacting. If every problem leads to a new process, soon you're buried under a mountain of them. Instead of helping, they slow you down and it becomes hard to keep track of all of them.
Today, I have a different view on process and how to use it. Before explaining I'd like to ask the question: but what is actually a process?
What is a process?
Let's look at a concrete example.
Imagine a 100-person company with one HR manager. Employees want to take vacation, so they call him, email him, drop by his desk... He's drowning in requests. Context-switching constantly. Struggling to track anything.
So he creates a form: "This is a form that I need you to fill out if you want to request time off." That is great, it centralizes all requests, he can transfer them to a data structure or a software! He designed a process.
For me, this is a process: a goal, a method, someone who applies the method and someone who benefits from the goal. For the above example:
Goal: Save HR's time
Method: Fill the form
Who applies it: The employees
Who benefits: The HR manager
But here's the kick: the people who apply the process are not always the ones who benefit from it. The employees pay the cost - less flexibility, more effort - while the HR manager benefits from it.
This asymmetry can make some processes disliked. You could say one pays the price, the other gains it, so this is a fertile situation to create frustration. Yet the alternative - the previous mess for the HR manager — is also unacceptable.
Here is another example.
In a small software startup, bugs are leaking into production. The developers decide that every change must be reviewed. They actually "invented" code review.
Goal: Fewer bugs
Method: Have the code written by someone reviewed by someone else
Who applies it: the developer team
Who benefits: the developer team
Same group, different mindset. They see the pain of bugs, so they value the process. They're more likely to adopt it because they feel the benefits directly.
One thing to be aware of is that most of the processes have a cost, the one paid by applying the method.
It could be time. Money. Complexity. Less flexibility.
Can be small, can be big, but it’s almost always there.
In the first example with the HR form, the cost is paid by employees:
- if they are not sure how to fill the form, they cannot rely on the HR manager help (or they must reach for it) unlike before: less user-friendly
- the form has a set structure that could not accommodate some cases: less flexibility
When designing a process, you must weigh the cost versus benefit. And when applying a process, that equation still matters.
Spectrum of process mindset
In a company, one could find a range of attitudes regarding processes:
On one end, people who dislike processes: they see mostly the cost and quite often are the ones applying the method (hence paying the cost) but not benefitting from the goal. Sometimes this is because the process is poorly designed, so these people have valid reasons to dislike it. But there is also people who, no matter the process, simply do not want to do something that feels slow or pointless.
On the other end, people who follow every rule, every time. They value the outcomes - less bugs, fewer mistakes - and in order to maximizing the chances of achieving it, they do not want to risk skipping steps.
I find myself in the middle.
My approach to processes
When I see a process that I have to apply I always try to remember the goal, the method, who applies it and who benefits it. It then helps me answer the question "should I apply it or not?". And asking myself, "If I don't apply the process, are we still achieving the goal?" usually gives me the answer.
If yes, I may choose to skip the process - and save the cost.
If not, I follow it - and pay the cost aware of the benefits.
If I reuse the second example with the startup: the developer team has now decided that every Pull Request must be reviewed by two other people.
Then someone fixes a typo in the README and submits a PR for it.
Do you really need two reviewers? Probably not: the goal of the process is to catch bugs and code issues - but here, there is no code. No risk. You can skip the method and still hit the goal.
But now imagine the PR modifies a config file that affects payment processing. The change looks simple: one line... But skipping review here could be risky.
In this case, applying the process is worth it as the cost is justified by the potential impact.
Going beyond the process
I remember reading a book about SCRUM and learning about the Shuhari.
Quote from the Wikipedia page:
"It is known that, when we learn or train in something, we pass through the stages of shu, ha, and ri. These stages are explained as follows. In shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forebears created. We remain faithful to these forms with no deviation. Next, in the stage of ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process the forms may be broken and discarded. Finally, in ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires, unhindered while not overstepping laws."
The book was using the Shuhari to explain why it is important to stick tightly to the SCRUM book when a team starts applying it because experiencing it is important to understand what it brings, what it changes, what it costs. And only after they realize what SCRUM brings to the table should a team start deviating from it and define its own process.
I think we can apply Shuhari to processes. Not familiar with a situation or a topic? Stick to the process: it was designed by people who understood the situation better than you, you should be safe applying it. But once you've understood the stakes - the goal, the method, who applies it, and who benefits - then you can deviate... and choose to apply the process fully, partially or not at all.
Top comments (0)