Avoiding Bureaucracy in Software Teams
How to make process improvement effective
Process improvement is one of the main tools for Engineering Managers (EM) to manage their team. Delivering commercial software involves overlapping multiple systems, and acting on them effectively improves the team’s environment and results.
However, processes can also easily hinder effectiveness. Too much focus on it can restrict the team and its members, and poorly applied techniques can also have negative results. There is no better way to understand that than looking at the current industry perception of the Agile movement. What was a change to focus on iteration and flexibility became a synonym for rigid and ineffective structures.
That brings a dilemma to managers. If process improvement and standardization are tools that can benefit teams, how can they be applied without creating restrictive environments? To discuss that, let’s first look at the two sides of this coin.
Process Improvement as a Tool
Nothing is more challenging (and ineffective) than improving an unstable system. If there isn’t a repeated process to improve, trying to respond to problems becomes a game of whack-a-mole. That’s because the only way to act on a team without changing the system is by influencing the team members.
For example, a team might experience a severe production incident. They go through a postmortem and identify that the code change that led to it didn’t have enough reviews. In an individual-centric environment, the manager would talk to the person who made that change to agree on an improvement plan. Then, the manager would observe to ensure their employee follows the guidance. If this sounds like micromanagement, it’s because it is. All this effort will only improve the changes delivered by one person.
If the same situation occurs in a more stable environment, the EM has a better leverage point because the team has a structure that defines how they review changes. They could update the review guidelines to include better procedures, or if that is already done, they could discuss how the team is following the guidelines again. If they do it successfully, all the engineers will review changes better. By acting on the system, they can improve the whole team, not only a specific individual.
In the second case, the problem is solved, and everyone is happy. But are they?
Process Standards as a Tax
Fast forward one year, and the testing guidelines are still in place and being strictly followed. The team has a few new members who see them as usual. At the same time, they have significantly simplified their code, making the extra review procedures less needed or relevant. However, they continue executing it since it is “working.”
In this case, the introduced process changes went from being necessary to being a burden. While they are not harming the team’s quality, there is a cost to executing them. That is because any process will also be a tax. It costs to implement and is only worthwhile if there is a return on the investment.
But removing processes is much harder than introducing them. As time passes, people start seeing all processes as their usual way to work and don’t question them as much. And because the change happened so long ago, nobody remembers why it was introduced. How can you make sure the problem won’t come back if you don’t know what the problem was in the first place?
And this is the conundrum that teams face. How do we introduce standards without risking accumulating them and creating a rigid environment?
Centering on the Problem
If I had a hammer to hit every process improvement nail, it would always center on the problem, not the solution.
While people start their improvement thinking around a problem they perceive, they usually frame their proposals around a solution. In a basic example, a manager can perceive a challenge with code reviews and introduce a new code review template without specifying the problem they are trying to solve. While it might be clear to them, it won’t be for the rest of the team. When doing that, they are climbing the ladder of inference and sharing only the last step they took instead of the whole journey, depriving others of the entire context.
Because of that, any improvement proposal should center around the problem it is trying to solve. Instead of “Introducing a new code review template,” it should focus on “Reducing the code complexity of PRs.”
Focusing on the problem enables a series of benefits that will be valuable in the long run, such as:
- Everyone understands why: by making the reasoning clear to everyone involved, they can make better decisions when they inevitably must adapt the process to new circumstances.
- There is less resistance: with people understanding and agreeing on an existing problem, it is much easier to discuss solutions and their trade-offs.
- It opens space for alternatives: discussing a problem allows others to propose solutions, creating a space for more empowerment and conversation.
- It allows for autonomy: centering process changes on a problem will enable specific individuals to diverge from it when needed while still keeping the benefits of the change.
Besides the above, the main benefit of centering change initiatives around problems is that it allows us to trigger exit paths and improvements when appropriate. In the above example, a process centered and measured on not having incidents would enable the team to trigger another discussion when they stop having incidents or think about new solutions if the first one didn’t have the expected result.
The Lean way
If this sounds familiar, it’s because work standardization is the base for continuous improvement in Lean Production Systems. You can only improve a system if you have a standard for it. You can only keep evolving it if you believe your standards are constantly changing. And you can only continuously iterate if you focus on the problem — the system’s bottlenecks.
“Focus on one problem at a time and try to accomplish continuous improvement no matter how small it may be. This is how you can collect useful clues as to what standard work should be.” Taiichi Ohno — The Toyota Mindset
Being Problem Focused Pays Off
Process change is a manager's primary tool to influence a software team. Keep them focused on the team’s goal and bottlenecks; improvements will naturally follow.
If you have found this content interesting, this post is part of a Leading Software Teams with Systems Thinking series. More broadly, I write about leading effective software engineering teams. Follow me if you are interested.
