How Engineering Managers Are Set Up To Fail

I have heard and often observed how different organisations support their Engineering Managers (EMs). A handful of companies do an excellent job, providing as many resources and support to EMs as much as their Individual Contributors (ICs). Many are… less good. This article will cover three common ways EMs are set up to fail and what you should do instead.

Failure #1: Thrown Into The Deep End

The most common way organisations fail is by throwing newly minted EMs in the deep end. Many first-time EMs transition into the role because they are the most senior or successful ICs. They might have been the most experienced, knowledgeable, or productive IC on the team, and their manager gave them a new title. Unfortunately, being a great IC does not automatically translate into being a great EM.

The transition to an EM is a role change, not a promotion
Source: How Engineering Managers Are Set Up To Fail

The transition to an EM is a role change, not a promotion. A different role requires significantly different skills. Some of the skills ICs master are not relevant to some of the skills required by the EM role. For example, writing well designed and refactored code has no relationship to how well someone can provide effective feedback, resolve disagreements between team members or run effective meetings. Many ICs are successful without using, let alone mastering, the skills needed by an EM. Just as throwing someone into the deep end of a pool doesnโ€™t magically grant swimming skills, throwing a new person into the EM role wonโ€™t give them the necessary skills to succeed. New skills require deliberate practice, opportunities to learn and make mistakes.

To overcome this, set clear expectations about the EM role. Agree on a role description for the EM, highlighting new responsibilities and potentially new skills. It can be helpful to decide what sort of EM you want, as a different type of EM requires more experience with particular skills. Provide an honest appraisal of the existing skills of the new EM and expect some gaps. Identifying those gaps is an opportunity for growth, and you can work together to build a personal development plan to help them close those gaps through training, coaching and feedback.

Failure #2: Provide Zero Support

The second way organisations set up EMs for failure is to assume they do not need any support. Some senior managers (wrongly) think, “This person is now a manager. They’ll work it out.” Although EMs should have more agency than ICs, no person is perfect. New EMs will make many mistakes; this is the process of learning. Even experienced EMs will have gaps, such as navigating new experiences, responsibilities or situations they have never had. Handling mistakes is much easier as an IC. As an IC, you have other team members, often in similar roles, who can jointly solve problems or provide an excellent sounding board or feedback. One example is pair programming, where two developers work together in real-time.

While EMs can involve team members in some situations, there are many where they cannot. Some EMs might hesitate to involve team members because it might distract ICs from more immediate important or urgent work. Some ICs may have no interest or experience with a topic they see “outside” their role, such as improving the recruitment process or identifying the current team bottleneck. Other topics may involve specific team members, which means the situation is too sensitive and inappropriate to discuss with other team members. While EMs can lean on their team for some situations, there will be many they cannot, fueling a sense of loneliness. But it doesn’t have to be this way, and organisations can do more to support their EMs.

To overcome this, build and highlight explicit EMs support structures. Three good options for explicit support include:

  1. Running EM Support Circles;
  2. Fostering an EM Community of Practice; and
  3. Establishing an Exchange Program with an external company

An EM Support Circle is a weekly or fortnightly meeting with a small set of EMs (e.g. 7-8). The goal of an EM support circle is to “Support each other.” Support might mean EMs bring a challenging situation and invite advice or opinions about how others might approach it. Support might mean testing if other EMs can confirm a rumour or seeing similar observations. Support could also be as simple as providing a place to vent. EM Support Circles with high psychological safety can be very effective.

An EM Community of Practice (CoP) is a larger group, much like Spotify’s Guilds, to foster and share knowledge across the whole EM community in a company. A well-run EM CoP organises learning activities like book clubs, training, workshops and talks from internal or external people focused on EM-relevant topics.

Smaller organisations with less than three EMs benefit more from an Exchange Program. An Exchange Program is an agreement between two or more companies that form an EM Support Circle or CoP with EMs from all companies. A key feature of an Exchange Program is the agreement to exchange time at the other company. One EM “shadows” another EM from a different company for a half or whole day. This exchange might occur as frequently as once a month to once every three to six months. Think of an exchange as a good “pair programming session” for EMs. Each exchange allows EMs to trade experiences, approaches and offer mentoring or coaching to each other.

Failure #3: Not Breaking Bad Habits

Do you ever wonder why there are so many bad managers? People don’t intentionally set out to be lousy EM. Instead, most bad EMs are bad because they continue to act as a senior IC, when they need to act differently. Managers of EMs (i.e. Directors+) fail to help new EMs break bad habits. For example, senior software engineers will want tough, challenging problems to solve. If the EM always takes the most challenging technical problem, they also take away opportunities for someone else to solve a problem they have never solved before and strip them of a learning opportunity. Another example is how software engineers learn that DRY (Don’t Repeat Yourself) applied to code is a good principle. When EMs apply the same principle to communicating, they will not be very effective. New EMs must break the habit of reaching for the principle DRY. EMs must learn that it is okay, and often, desirable to CRY (Continually Repeat Yourself) ๐Ÿ˜‰. A different role requires new behaviours and skills and a need to break old habits.

EMs must learn that it is okay, and often, desirable to CRY (Continually Repeat Yourself) ๐Ÿ˜‰
Source: How Engineering Managers Are Set Up To Fail

To overcome this, EMs need feedback that they are drawing on the right behaviours rather than old habits. Providing feedback is your responsibility if you are the EM’s manager (e.g. Director+). Walking a new EM through the role expectation is only the start. You also need to make sure new EMs receive continuous feedback to help them adjust their habits and behaviours.

Team engagement surveys can provide hints at what is working well or less well for a team. Use skip 1-1s to talk directly to ICs for more specific examples. Organise 360-degree feedback sessions for EMs to hear the feedback first-hand but don’t rely exclusively on that process. Make sure that EMs receive regular feedback (ad hoc and at least once per quarter) and make sure they have opportunities to break bad habits.

Help Your EMs Avoid Failure

If you are a Manager of EMs, you have an opportunity to help your EMs thrive. Avoid these three common ways EMs are set up to fail: Throwing them in the deep end, providing zero support and not helping them break bad habits.

3 thoughts on “How Engineering Managers Are Set Up To Fail”

  1. I loved the point about providing the right kind of support – it’s so important! I worked as an EM at places that had all of it and ones that had nearly nothing and it was a stark difference. I like the distinction between the support circle and a community of practice, too – a subtle but important difference.

    Shameless plug: I’ve also written (actually two ๐Ÿ˜…) articles in the past about how new EMs typically fail – they go more into the details of certain behaviors rather than highlighting the systemic issues, so I think they’d fit your article nicely.

    • Hi Csaba,

      Thank you for your comment and sorry to hear that you’ve experienced environments without a lot of support, but great that you can contrast that with more supportive environments.

      Thanks for sharing your links as well. Funnily enough, I have a draft article sitting here soon to be published that covers how EMs fail too. I’m sure there are going to be some similarities, given these are so common.




Leave a Comment