Engineering Leadership in Action
A framework for Engineering Management
In a recent post, I talked about the idea of how Engineering Managers (EMs) should act as leaders in their teams. They should intentionally work on the systems (or processes) that affect their teams to achieve better results for the team and their members.
Software engineering is a complex discipline, and teams delivering software are affected by multiple processes. How does one decide where to put their focus?
As a leader, you are usually bombarded with multiple initiatives, projects being delivered, data being collected, and people having opinions. Navigating all of that and finding productive outcomes for the group is certainly the main challenge of the role.
Stepping back for a better view
Whenever there is a problem with focus, a good move is to step back and try to look at the forest instead of the trees. One model I find useful for engineering managers (or anyone working with teams) is looking at your work from three different lenses, Social, Technical, and Commercial (from here), and aim to succeed in all of them.
From the Social perspective, are people fulfilled with their work in this team? From a technical perspective, is the work delivered technically sound or fit for its purpose? And from a Commercial perspective, is the team delivering enough value to their customer/market?
While these are not specific to software engineering, it’s possible to adapt them easily for our purpose:
- Product (Commercial): A team needs to deliver well on its objectives, or the company ones, in whichever way they are measured internally. Ultimately, this is why the team has been created.
- People (Social): A team needs to provide an environment where its members like to work and find the space to grow their careers. And it needs to provide these opportunities for all its members.
- Engineering (Technical): Lastly, a team needs to build technology at the quality it needs to succeed in the long term. This doesn’t mean perfect software, but it means software that is fit for purpose to the company’s needs and will allow for continuous evolution.
As an EM, you should be responsible for finding this balance and keeping it all working together. While there are times when the team can consciously flex into one area over another (pushing to deliver a project, for example), ultimately, the team will need to work well in these three categories to achieve long-term success.
A practical view for Engineering Managers
In practice, I’ve found it useful to align work in engineering leadership against two main goals:
If you compare the areas above with these two goals, the obvious missing piece is the technical aspect. However, I’ve found that in software engineering, if the work you deliver is not of enough quality or not interesting enough, your team will end up suffering in one of the other areas: its results or its members’ satisfaction.
To summarize, as an EM, you can look at the goals above and assess whether your team is doing well against them or where there are challenges. With that in mind, it is easier to focus your attention on the processes around that specific area and see how it affects your team.
While each situation is different, here are some examples that I’ve seen in the past while working with product engineering teams.
- When the team struggles with completing work because items take “too long,” it’s useful to understand how the team visualizes and organizes work. As I’ve mentioned many times, the team standup is an important part of it.
- If there are often problems with work quality, it’s useful to understand how requirements are defined and how quality assurance is done.
- If particular engineers are struggling, it is useful to understand how work is distributed amongst the team and what systems for collaboration and learning exist.
- If engineers feel disconnected from the work, it is important to understand how projects are defined, from idea to production, and how much engineering can participate.
Ultimately, this list can go on forever. What is important to understand is that there is always a solution within the system.
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.
