What does it mean to be technical, and how it helps Engineering Managers
A common topic in engineering leadership is the need for technical Engineering Managers (EMs). Do they need to code or not? What should their technical contribution be?
While contexts vary, and there are no right and wrong answers to this topic, my experience in product software development is that technical EMs will have an advantage. However, what it means to be technical will depend on the situation. In other words, EMs should ideally have software engineering experience* if the work they are managing is software engineering.
Why are technical contributions and knowledge significant, and how does it impact a software team? To understand that, we need to look at the broader picture.
* Software engineering experience doesn’t necessarily mean coming from a traditional software engineering background. One of the advantages of software development is that anyone can learn it.
The Software Delivery Challenge
To look at what skills a manager needs, we should look at what their team is trying to achieve. After all, the manager is there to lead the team towards results. Software teams aim to transform ideas into working software, solving problems for the team’s customers. While they are usually cross-functional, EMs work across this spectrum, being accountable for the execution of software delivery but also influencing all aspects of its cycle.
The EM should work towards two main goals within this context. They will work toward making the team productive, delivering the expected results, and creating a stable environment that allows engineers to perform and grow in their careers.
What activities will they be involved in to achieve these goals? Too many, but here are some common examples of where they will manage upwards, sideways, and downwards.
Upwards, the EM will be involved and likely responsible for driving their team’s strategy. They will collaborate with company and engineering leadership to establish high-level roadmaps and the team’s technical strategy.
At their level, EMs will collaborate with Product Managers and Designers to establish team plans, and with their peers and engineers in other teams. That collaboration will often be around project delivery, with teams needing support to achieve their goals.
Downwards, EMs will work with their reports. That will be for day-to-day execution, project planning, code reviews, operational support, and possibly coding. And also when defining longer-term goals for individuals, helping them grow their careers.
The Non-Technical Way
Most of the activities above are high-level, and one could argue that being technical is not essential for them. After all, most of the improvements are on the system. If a manager can coordinate the team well, why does being technical matter?
The answer is that the system is technical, and while coordination is possible without deep understanding, knowing the work, which is software engineering, will likely lead to better results. Let’s look at some examples.
Roadmap and Project Planning — One common activity for EMs is to help with project and roadmap planning. This planning could be as part of goal setting, as in which projects we will deliver next quarter, or in scoping the complexity of work and estimating how long a solution would take to be delivered.
While engineers should be responsible for estimating work, having a better technical understanding of the team’s technical ownership allows an EM to both provide quick ballpark estimates and help validate engineers’ assumptions when estimating.
For example, in a past situation, one of my teams was asked to estimate a project so we could consider if it was worth implementing it or not. One engineer took the task and came back with an estimate significantly different from what I would have guessed. That was the prompt to start a conversation where we discovered that some of their assumptions were wrong. A non-technical EM could have accepted the face value estimate, passing it along and leading to a wrong business decision.
Technical Strategy — Another important activity for software teams is to be able to define a technical strategy. Without it, a team can easily fall into a feature factory pattern, continuously delivering product features without considering technical improvements to reduce technical debt or improve the team’s capacity to deliver effectively.
This is another area where engineers should be involved and lead the thinking on the path forward. However, approaching it entirely from a bottom-up perspective will lead to suboptimal results. Firstly, a team has many engineers. Without a leading voice, the strategy can become a patchwork of ideas that don’t align or complement each other. In addition to that, technical strategies don’t exist in isolation, and having a broader view of organizational and product goals will help to create a plan that aligns with longer-term goals.
A non-technical EM will have limited insight into the architectural challenges and decisions discussed within the team and company and the technical improvement opportunities that complement the team’s product thinking.
Operational Support — A software engineering team usually has operational responsibilities, supporting their product in production and its infrastructure at some level. This support likely means software engineers will participate in an on-call rotation and attend to operational issues and incidents, debugging them and collaborating on their resolution. A non-technical EM won’t be able to participate and contribute to these activities.
It will be hard for a non-technical manager to understand and have practical insight into that work. Without that, EMs struggle to improve it, with the risk of that becoming a blindspot for them. As anyone who has supported software in production can likely tell you, there is no other way to experience resolving an incident than actually resolving an incident. It also makes it difficult for managers to support engineers effectively during critical situation, which are high-stress and where support can be crucial.
Besides, on-call rotations and incident management are likely the most annoying activities an engineer has to be involved in. Being available 24/7 and responding to calls at inconvenient hours is not a great part of the job. Having an EM that doesn’t participate in them at any level can erode trust with the team’s engineers. It’s not the best leadership pattern to ask the people you manage to do something you are unwilling to do.
Coaching and Team Support — A fundamental part of being an EM is providing coaching and growth paths for the engineers in their reporting line. That can take shape in different forms. They can provide feedback on technical work, both code and design documents. They can also support an engineer’s work within an environment with diverging ideas and opinions. Lastly, they can provide a technical growth path for engineers to achieve the next career level.
A non-technical EM will have a limited perspective and capacity to help in all these situations. While there are possible alternatives, like a mentoring setup with another engineer, those will have to include a third person in the effort, likely leading to less direct and effective results.
For example, in a past team, I had an engineer provide feedback to me about another person, claiming that their Pull Request (PR) reviews were not adding value and making their work harder. In that case, I asked for examples of PR reviews and, after looking into them, considering they were appropriate, helped guide the engineer on how to react to them. If I couldn’t do that assessment myself, I would have to ask a third party for it, turning it into a more complex situation, possibly navigating four people with different opinions.
In all these situations, EMs don’t have to be the technical experts within the team, and they should delegate them to engineers. However, having technical context and an in-depth understanding of the technology owned by the team will lead to more effective decisions.
What is Technical Enough?
If being technical is necessary, how technical is technical enough? Should EMs be delivering code regularly?
That certainly depends on the situation. The main goal for the EM is to enable an effective team, which is the same within a technical context. Regularly writing code might be the best alternative, depending on the team, although it’s certainly not the most common case in my experience.
A good rule of thumb is the team size. In small teams, it is more often the case where the manager can contribute regularly and still be an effective team leader. This assistance can happen with them playing a tech lead role or even playing a contributor role.
However, when teams grow, the EM leverage usually switches from delivery to enabling delivery towards higher-level activities. With more reports, it is also harder for EMs to have focus time, often becoming a blocker if they try to keep contributing.
In summary, while EMs should maintain the technical context to provide support in different situations, they should always ask themselves where is the highest leverage activity they can do. And that is often not delivering code.
Being technical is not everything, but it is a part of it
While this article focuses on the technical aspects of the EM role, it is hopefully still clear that having technical context is not enough for a manager. Leading an engineering team is a multi-faceted role trying to make the team effective while creating a stable environment for its members.
But being technical is advantageous in multiple situations, and EMs should invest in making it another tool in their toolbox.
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.
To Write or Not to Write (Code)? was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.