Engineering Leadership Tactics: Building Alignment

How to find buy-in as an Engineering Manager?

Change is part of the day-to-day work of an Engineering Manager (EM). It could be because an EM is trying to improve their team’s delivery results or quality. Or they could be trying to make improvements that affect the broader organization.

I have previously discussed implementing change at a high level previously. I would like to go more in-depth into some tactics that I have used in the past. How to get alignment at different levels?

Some starting thoughts

While there are many tactics to influence change in your team and organization, there are two premises that will be true in any situation.

Metrics are your friend

Independent of what an EM is trying to act on, if they have metrics demonstrating the current situation and can use them to track the result of their improvements, it will significantly help the effort. Quantifying the problem and impact of their work will make it easier to get buy-in and understand if the improvement is achieving the expected results.

Obtaining metrics is easier said than done. However, while it is hard to find precise measurements for process improvement, it is usually possible to find estimates that are good enough to use as a north star. Between source control, team chats, a ticketing system, and surveys, most of the work of a software team can be quantified when needed.

Process documentation helps with stability

When looking at Lean Production Systems, one of the common misconceptions is that process definition leads to rigidity. The assumption is that if a process is written down, it will be less flexible and harder to change. Interestingly, the thinking behind documented processes in Lean is to allow for continuous improvement. The idea is that a team cannot improve a process unless it is stable. Otherwise, how could the improvement be verified?

In general, I see teams staying away from documenting processes in software and relying on tribal knowledge to maintain the team’s operation. Without going too much into the pros and cons of that approach, it will be beneficial for a team to have the targeted area documented and stable when trying to improve a system. That will make it easier to demonstrate the change that has been made and keep the new state after the improvement is made.

The Tactics

With the thoughts above in mind, there are a few different approaches I’ve used in the past for different situations. Let’s look at them.

Driving change with the team: Improvement Kata

The Improvement Kata is a simple tool on a visual board to track improvements and collaborate with others on them. While one can apply the tool in different situations, I want to discuss using it to align a team around improvements.

An improvement kata is the most useful when looking at an effort of continuous improvements where the problems are visible and mainly clear to everyone involved. For example, if the team is aligned on quality as an issue and making an effort to improve it.

In that case, a simple process is to regularly meet and align on experiments to be tried, measure their result, and then iterate or pivot from there. This process helps everyone participate in the effort and keeps the team focused on a few changes at a time, leading to better results.

When using an improvement kata:

• Create a regular place where the team analyzes the board. It could be as part of retrospectives or a regular meeting with everyone involved.
• Assign owners to improvements and take items off the board if they become stale. It will be better to admit that something is not moving forward and be consistent about actively working on what is on the board.

Creating alignment with the team: Driving consensus

How about situations where the consensus does not exist yet? The EM (or anyone else) may see an unacknowledged issue or have an idea for a solution that the team is not bought in yet.

In these situations, I have found it helpful to drive the conversation individually before exposing it to a larger group. That has allowed me to understand many perspectives and adapt the solution to them, ensuring everyone felt heard.

There is a word in Japanese, Nemawashi, which is the process of laying the foundation for a proposed change. The Wikipedia article discusses avoiding embarrassment as the goal of using it. For me, it has been most helpful to avoid pushback in proposed changes.

When driving consensus within the team:

• Wait for problems to occur since that can help you catalyze the intention to fix them.
• Be patient. Sometimes finding alignment won’t be possible, and waiting is better than trying to force a change.

Proposing broader changes: Using Documents

While talking to people individually can be very useful, sometimes there are too many people to talk to. This is the case when someone tries to suggest broader or longer-term changes. Besides the number of people to discuss an idea with, in more extended efforts, it is hard to keep the proposal consistent throughout multiple informal conversations across many months.

This is where documents become an excellent tool for the job. Having a proposal written down will help get broad feedback and alignment on the perceived problem and the solution. Having the thinking documented also allows the proposal to evolve with time, keeping track of the decision-making along the way.

There are multiple options in terms of the format. My default is to create documents based on the A3 Thinking format, which is excellent for explaining the whole context for improvement. It is also interesting to track the state of proposals throughout time, and an RFC process can be valuable there.

When using documents to propose changes:

• Focus on keeping the momentum going. That means eliciting feedback, iterating on the document, and proposing actions as the effort progresses. It is easy for everyone to forget proposals when they are in a document that is not top of mind for them.
• Be clear and verify when you believe you have enough alignment to move forward. It is easy for people to be misaligned, leading to frustration among people that didn’t feel listened to.

The most important part

The tactics above can provide a path forward to many types of improvement. However, it is essential to remember a few principles to keep in mind when applying any of them.

• Proposing changes and getting consensus is not the goal. The goal is to improve the system. While these tactics will help you get the change started, the hard part is to get it done, measure its result and keep the new system in place throughout time. Nothing will limit your capacity to implement change more than a track record of starting and not finishing many initiatives.
• There has to be a stable environment to allow for changes to be implemented and persist. In other words, if a team tries to improve too many things simultaneously, even if they get them done, it will be impossible to understand the result. This is the unfortunately too familiar scenario of teams that have great retrospectives, come up with multiple ideas for improvement, but fail to conclude any of them.

As in any work, it is essential to limit the work in progress when improving systems and focus on finishing before starting. It will undoubtedly lead to better results.

If you have found this content interesting, this post is part of a series on Leading Software Teams with Systems Thinking. More broadly, I write about leading effective software engineering teams. Follow me if you are interested in the area.