Leading as an Engineering Manager

How you can help your reports by working on your team

“How much and how should an Engineering Manager (EM) shape, act, and lead their team?”

In a previous post, I have already discussed some of the mechanics of being an EM, but another aspect worth discussing is the EM as an effective team leader. And what happens when they are not.

This is not surprising since being an active leader is not discussed much and is still unclear in the industry. In fact, the technology industry has pushed against EMs as leaders, with a strong push against micromanagement.

Don’t get me wrong, micromanagement is a real problem. However, I often see issues at the other end of the spectrum: lack of leadership and excessive delegation to empower engineers.

The management spectrum. By focusing on not acting too much, managers usually act too little.

It is a challenging topic to discuss because empowering people is one of the ever-positive actions that will always have support. It is the people management’s equivalent of investing in more quality. Everyone is (and should) always be supporting more quality. Or more empowerment.

However, in practice, the actions that are taken for empowerment can end up hurting engineers and their teams. While there are many aspects of it, here are a few common examples I’ve seen repeatedly:

• Engineers who struggle to complete work are performance managed because the team has no effective collaboration and learning process.
• Engineers struggle when left to manage and organize a complex project with multiple stakeholders, many of them outside of the normal reach for their role.
• Engineers who struggle to adhere to a manager’s schedule to manage their project cannot find focus time to deliver software.
• Teams that struggle with unclear goals and misleading requirements since it is all being planned and organized by someone that has no experience in project management. And is given no help in learning it.

Looking at the system

When working in an operational process like software delivery, we can rely on systems thinking to help us navigate through it.

In this case, it’s worth remembering that there is always a system. The only choice that can be made is whether to be intentional about it or let team members be free to work however they want.

And the problem with not acting on it with intention is the type of process that ends up being created. While a formal system is visible and can be adjusted, an informal system can lead to inefficiency and power-based influence.

System types (from Systems Leadership)

By trying to avoid a counter-productive restrictive process, EMs create teams working with non-authorized processes. This is where one needs to “work the system” to get things done or one where the authority is unclear. For example, you can see this in practice in teams where work is opaque, and it’s unclear how it is progressing. Or where each project is delivered differently, making it hard for team members to participate.

This can become a vicious cycle as unproductive systems lead to failed efforts, loss of trust, and more oversight and micromanagement. And that will add pressure on engineers. The empowerment effort creates more restrictions on team members and can lead to significant performance issues if the cycle is not broken.

The vicious cycle of leaderless teams. By trying to provide freedom we end up creating restrictive environments.

A different approach to achieving the empowerment we are looking for, where engineers find space to do their work effectively and grow while doing it, is for EMs to be more active in their role as team leaders, actively shaping a system that allows for people to thrive.

While being overly focused on freedom will lead to pressure, focusing on an effective team will lead to a process that allows team members to have the freedom they need to be successful.

This is clearly not a simple task. All teams and situations are different. Managing a more experienced team is different than a less experienced one. Companies are different. Sales engineering teams are different than product-focused ones.

However, some high-level steps will work for any software engineering team:

• Observe and understand the systems around your team. What is the process from concept to production? How are projects and requirements defined? How is code produced and tested? The more you understand how the work works as a manager, the more capacity you will have to remove its bottlenecks.
• Stabilize your main team processes and make work visible. Align on what are the main high-level processes with your team members, document them, and keep the team in check about running them reliably. Make the work visible on your board, and constantly review how it’s progressing.
• Keep pushing for improvement and iteration. Work with your team to review and analyze how it is working. Experiment with improvements to reduce time cycle time.

There are many techniques and approaches to solve specific team issues, but being intentional about understanding how your team works together and focusing on improving it will always lead to the best environment.

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.