Influencing as an Engineering Manager
How to make change happen
I’ve been discussing how to use systems thinking in software engineering management, and so far, I have talked mostly about understanding your team and the systems within it.
But once the manager does that, the real challenge begins. How does one make improvements happen? How do you act on your team’s system to improve things?
Leading as an Engineering Manager
As a reminder, driving change as an engineering manager (EM) doesn’t mean that the manager is the only source of improvement for a team. A healthy group will have regular feedback loops, such as retrospectives, conversations, and surveys, highlighting the issues and possible ways to improve things.
However, the EM has the vantage point and authority that engineers don’t. So they should try to listen to all these inputs and create a more productive system for the team.
Another common misunderstanding is that creating a productive system will lead to a restrictive process. The rules within a team should enable individuals to perform well and be fulfilled, not go against them.
Making Improvements Happen
It is essential to understand that while EMs have authority as a leader, they should avoid using it as much as possible. This is because while people usually don’t resist change, they resist being changed. In other words, nobody likes to be pushed around.
People don t resist change; they resist being changed (Peter Senge)
With that in mind, here are some strategies I have used to make change happen while keeping team members involved and aligned.
Observe and understand
So you make sure you are going in the right direction, the first action is to observe. Too often, leaders make decisions without a first-hand perspective, leading to misunderstandings and mistakes. If you believe the team has a problem they can improve upon, verify it yourself before acting on it.
An EM can observe in multiple ways. First, go to meetings and listen to the discussions. Pair with your engineers and understand their work experience. Obtain data from how your team is operating.
Once you see it with your eyes, you can judge it much better.
Obtain different perspectives
The EM is not the only person with an interesting perspective on how things are going. Therefore, they should use all opportunities they have to obtain different points of view and get feedback on possible changes. These could be retrospectives, team meetings, surveys, or 1–1 meetings.
Regarding 1–1s, one of the (multiple) reasons I recommend having them weekly with all engineers in a team is that they allow the EM to get everyone’s thoughts within a week. That short feedback loop gives them great insight into what the group is thinking.
In practice, a typical pattern I have used successfully is to get feedback on any improvement ideas individually first, just proposing them to the team once I believe there is enough support from the individuals.
Wait for the problem to actually happen
It is harder to get support for changes unless everyone agrees there is a problem. And while the EM might understand how the team can improve in a particular area, it doesn’t mean that others perceive it the same way.
A practical technique I have used as a consultant when I had no authority is to wait for a problem to happen before proposing a solution. An example was a team where I believed there was low technical collaboration, which impacted how fast we delivered our project. So while I had improvement ideas, I kept them to myself until an engineer brought a clear example of that problem to a team retrospective. I then suggested that the team try pairing as a new technique, which everyone agreed to, given it addressed a genuine concern. So we did it, and that change persisted as we saw the improvements it brought.
Track it
Lastly, a team will become much better at continuous improvement if it can track and review the changes they make. The more a team owns the improvement process, the more they will be open to participating.
In other words, in a meta-comment, creating a productive system for improvement will make it more visible and allow people to participate and keep it on track, as in any other area.
A common practice I have adopted is using an Improvement Kata-based method, where teams track the problem they are trying to solve, the change (or experiment), and the expected result, reviewing them as they are implemented. It is a lightweight method to provide visibility and accountability for the process.
Putting it all together
As a manager, you should own the problem of improving your team to be both productive and an excellent place for people to work in. However, you should do that collaboratively, making the process visible, obtaining perspectives, and using your position to drive change that the team aligns with. You will all be better after it.
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.
