Engineering Managers (EMs) don’t intentionally set out to fail. Instead, they are often set up for failure. But even if they are set up for success, there are some common ways new Engineering Managers fail. This article will cover these and what to do instead.
Failure Mode: Continuing To View Their Role Mainly as a Maker
EMs typically transition into their role from an Individual Contributor (IC) or “maker” role. The most common way EM fail is not making a shift from a maker to a multiplier mindset. This mindset shift is also essential for technical leaders without management responsibility, such as Tech Leads or Staff+ Engineers. When an EM continues to see their role mainly as a maker, there are many expected consequences:
- The EM takes on the most complex work, leaving the more straightforward work to others. Others eventually get bored with “simple” work and quit.
- The EM neglects their other responsibilities, which means critical issues do not get addressed that should be.
- The EM takes on too much. They try to produce as much work as they did as a maker and complete all their new responsibilities all at the same time. Taking on two full-time roles is the perfect recipe for burnout.
To address this failure mode, recognise you need to shift your mindset from maker to multiplier. In the ideal world, your manager (i.e. a Director) should explain and reinforce this required mindset shift as you transition into the EM role. In reality, you also have to recognise and make this shift in mindset by yourself.
Failure Mode: Assuming Everyone Knows What You Do
Unfortunately, there is no industry-wide definition of what an EM does. Although we have EM archetypes, each team, organisation, and situation will differ. A part of any leadership role includes clarifying boundaries and expectations. When an EM does not establish shared expectations, they are likely to disappoint someone else in the organisation. For example, some team members might look towards the EM as the person who will teach and guide technical decisions, while a Director might expect the EM to focus their time on hiring, growing people and helping the team get stuff done. These two different examples would be the difference between a Tech Lead EM and a Team Lead EM or Delivery EM.
To address this failure mode, write a role description. The role description might be one output of a Roles and Responsibilities (aka RACI) discussion with other co-leaders such as a Product Manager or Tech Lead. Once you have captured your role description, give examples of how you might fulfil your responsibilities. For example, suppose you have written down the responsibility for “Growing team members”. In that case, you might list activities such as “Running weekly 1-1s with team members,” “Organising quarterly personal development goal setting/review sessions,” and “Facilitating fortnightly feedback sessions between team members.”
When you have captured a good list representing 80% of what you think you should do, use this to explain your role and get feedback from people you interact with regularly.
Failure Mode: Taking Extreme Views
When EMs come from a software engineering background, they can fall into the trap of taking extreme views; always looking for a single answer such as yes/no or right/wrong. This habit is understandable for software engineers because they are used to operating in a binary world. For example, they are used to a test going green or red, a build that is working or not working, or a service that is up or down. Unfortunately, this habit is not very helpful as you transition into an EM role. In the world of people and a dynamically changing environment, there is rarely a right answer. Instead, this means finding a good enough answer that balances different opinions and preferences based on your available information.
A timely example is if a team should work in the office (i.e. in-person) or remotely. Without knowing more about the people and the circumstances, choosing one or the other extreme would be a poor decision. Some people in your team might prefer significant face-to-face contact. Others in your team might be more comfortable with remote work as they have already built good remote working habits. Like with most decisions, a good answer lies somewhere in between.
To address this failure mode, build situational awareness and use the OODA (Observe, Orient, Decide, Act) loop.
- Observe – In the remote working example, gather information to learn more about the environment. Notice what is working and not working from your point of view. Listen to what each person values, recognising it will differ from person to person.
- Orient – No environment is ever perfect, so you need to decide the characteristics of a good solution. In the early phases of a team (storming/norming), you might want to create more opportunities for people to build personal relationships. In a later phase of the team, you might want to create more opportunities for people to have high-bandwidth and rapid feedback.
- Decide – Based on what is most important to your team, find a solution that addresses many of the observations you made and optimises for these. A decision is often a combination of different outcomes, and with in-person vs fully remote, many teams settle for some hybrid. A hybrid model for your situation might look like one or two days a week in-person, with the rest remote. A hybrid model for a different situation might mean mostly remote but meeting face-to-face at least once every fortnight or month.
- Act – Work out several small actions that move you towards the goal you made in the last phase.
An essential part of the OODA loop is making this iterative. As you take one of the small actions you generated, you’ll want to observe if it’s moving you towards your desired goal (or not!)
Failure Mode: Feeling the Need To “Shield” the Team
Some people view the role of an EM as shielding the team. For some, this stems from the need to “protect” team members from management. They may have a negative association with higher-level management. The desire to shield the team from upper management often translates into defensive behaviour. External teams or external people might interpret defensive behaviour as aggression, and the EM quickly finds themselves isolated or receiving feedback like “hard to work with.” Sometimes, this desire to shield stems from a more reasonable reason, such as minimising distractions from day-to-day work. While the team may be able to better focus on their work, they may be surprised about broader themes such as the sudden announcement of a merger or acquisition, a reorganisation, or a shifting product strategy. If you hide too much information, your team members will accuse you of poor communication or lacking transparency.
To address this failure mode, find a good way to share information that minimises disruptions. Ask individuals what type of information they would like to know. The end result might mean including a small paragraph in a weekly team update email or a whole team meeting about broader business themes once a month. Another key to success is to stop viewing upper management or other managers as aggressors or competition. Avoid the perception of “Us” (your day-to-day team) and “Them” (i.e. upper management). I find it helpful to remind yourself as an EM, you are on the same team as other managers, but it is a different team, one whose shared goal is broader than your day-to-day team. Instead of automatically “pushing back” as the first response, seek to understand others’ needs first. Then see if you can uncover ways that balance and satisfy everyone’s needs.
Failure Mode: Optimising the Parts Instead of the Whole
I remember speaking to a new EM, and they asked the question, “How do I make sure everyone is as busy as possible?” Although this question was well-intentioned, it is also the wrong question. Many ICs are proud of how much work they take on. These ICs might be proud of how many tickets they complete or the amount of code they write, all of which are measures of activity but not outcomes. When an IC transitions to the EM role, it’s natural to focus on optimising for activities (i.e. busyness) rather than outcomes (i.e. value added).
Unfortunately, in software, being efficient is rarely the same as being effective.
A system that incentivises individuals for busyness will diminish teamwork. Team members receive very late feedback because they are occupied with their work first, and the inevitable result is significant rework.
To address this failure mode, recognise that building software is a team activity. As an EM, you want to build a system that optimises the flow of value through the team, rather than trying to make each part work as efficiently as possible. Theory of Constraints teaches us to build a model of your value stream and focus efforts on identifying and improving the current bottleneck. As the old saying goes, “An hour lost at the bottleneck is an hour lost for the entire system.” Learn about systems thinking and the theory of constraints to optimise the whole rather than the parts.
Being a Successful Engineering Manager
The path to a successful Engineering Manager is not easy. Sometimes you are set up to fail. Even with good conditions, you can still fail if you fall for the traps covered in this article. Remember to transition from a maker to multiplier mindset, build shared expectations about your role with others, and learn to be comfortable with a more nuanced approach that isn’t 100% “right” or 100% “wrong.” Remind yourself that your team is full of adults that do not need “protecting”; part of your role is making sure they are connected in with the broader organisation, have the right context and that you see yourself as part of two teams (not just your own, but a broader management team). Finally, draw on concepts from systems thinking and Theory of Constraints to optimise for the whole and not just the parts. When you recognise that “What got you here, won’t get you there” you’re on your way to being a great Engineering Manager 🥳.
- Enjoy this article? Sign up for Level Up, a free curated newsletter for leaders in tech.
- Want to level up as an Engineering Manager? Join the online Engineering Manager Essentials course or sign up for self-paced courses at http://techlead.academy
