Actionable metrics for engineering leaders.
Processes are essential for effective management. They keep people in sync, making it possible for team members to come together and achieve a shared goal. But they’re also dangerous. Processes can create the illusion that things are running smoothly because they’re moving along according to the shared understanding of how they’re “supposed to” run.
This is the Fallacy of Process — the idea that by adding consistency and predictability to a shared workflow, a given process is inherently valuable.
Too often, process becomes canon. A team develops an effective way of doing something, then returns to that framework indefinitely, long past its expiration date.
As processes grow stale, they become red tape, increasing friction rather than removing it. That friction is more than just a hassle; it can be incredibly expensive — inefficiencies result in lost productivity, and frustrated developers are more likely to seek new roles elsewhere.
Just as a good process can multiply your team’s productivity, a bad, broken, or outdated process can have a compounding effect, costing your department more than any line item on its budget.
On their podcast, Rands and co-host Lyle Troxell, Senior Software Engineer at Netflix, propose the idea that every process lives somewhere on a spectrum between total entropy and complete control. For a process to be valuable, it needs to live somewhere between the two extremes.
They suggest that the problem with process starts with attitude, and they recommend that managers:
- Treat each process like a living, breathing thing. Recognize that just because something works well now doesn’t mean it will in the future.
- Work to understand the “why” of each process — and include it in documentation. If it’s difficult to articulate why something is done a certain way, it may be time for a change.
- Evaluate processes frequently, and improve them when necessary.
Managers at all levels would do well to heed this advice. But it can be difficult to identify sources of friction and honestly evaluate processes when you’re not the one tasked with implementing them. Still, it’s essential — the farther a broken process strays towards one end of the spectrum, the more it’s likely to cost you.
So, as a leader looking to evaluate and optimize your team’s processes, where should you start?
Software development pipeline model courtesy of Alexandra Paredes.
- Create a Mental Model. A mental model can help you get your bearings. Start big — map out how work should flow through your software development pipeline, for instance — and then share that model with your team. Solicit their feedback, and pay careful attention to any points of confusion or disagreement. If your mental model doesn’t align with your team’s assumptions, it may indicate that a process is broken or that your documentation needs to be improved.
- Use Data to Check Your Expectations. Once your mental model reflects your team’s understanding of how things work, you’ll need to confirm that those expectations are in line with reality. Engineering metrics are a powerful way to get that gut-check; objective measurements allow you to test your hypotheses about how things are going. When a metric doesn’t align with your expectations, it’s a sign that you should dig deeper and get more context from your team — you may find a process that’s ready for a refresh.
- Maximize Your Impact. Take your list of ineffective processes, and identify the most problematic ones. Which are the biggest sources of frustration for your team? Which cause the biggest holdups? Which have a cascading effect, causing more blockages down the line? These are your most expensive points of friction and the ones you should focus on fixing first.
- Draw Up A New Plan, And Get Feedback. Talk to your team about your broken processes, and ask how they’d fix them. Even if you think you’ve found an obvious solution, be sure to get feedback — if your team isn’t on board with a new process from its inception, it’s more likely to become a source of friction.
- Repeat. Processes are not static. They need to evolve as the circumstances around them change. Keep looking for ways to optimize your processes, and prevent them from becoming blockers.
Continually evaluating and revamping your processes is the only way to keep them fresh and effective, and to ensure you’re not paying for processes that exist for process’s sake. Of course, there’s a certain paradox inherent in proposing a new process for fixing old, broken processes. Adapt it, change it, and make it work for you. Anything less would just be falling prey to the Fallacy of Process.
Previously published at https://codeclimate.com/blog/the-fallacy-of-process