skip to content
Leadership Garden Logo Leadership Garden
The 5 Common Mistakes Of New Engineering Managers

The 5 Common Mistakes Of New Engineering Managers

/ 14 min read

Starting in a new role as a fresh engineering manager is not easy. Suddenly you need very different skills, feedback loops seem insanely long and the sense of accomplishment and success starts fading as a result.

Earlier I wrote about 4 key ways even experienced engineering managers fail. This time I’m specifically elaborating what usual mistakes folks who were recently still individual contributors and just became engineering managers make.

Still doing much technical work

EMs shouldn't do much tecnical work! This is the number one of all the usual mistakes of new engineering managers. Sometimes even the career ladder is set up in a way that encourages this, there’s the concept of the ‘tech lead manager’ which is supposed to be 50% programming and 50% people management – in my experience it doesn’t work well in the long run, I’ll elaborate why below. You might still be writing some code if you’re managing a very small team and that’s temporarily OK. It is critical though that you step back on technical decisions to make room for the team members to own things and grow and enable the team to scale.

There are multiple reasons for doing programming or architectural design as an engineering manager is a bad idea:

  1. It’ll hinder the much-needed growth in your new skills. Not having enough time to invest in your newly found leadership skills is a grave error. Even if the math seems OK there’s going to be the cost of context switching. You should be spending all the time when you’re not executing in your new role to learn about your new role.
  2. You simply won’t have enough time to do both well. Well, usually you won’t do either well.
  3. You won’t give enough room to your direct reports to grow and own things.
  4. You’ll be blocking your team by having projects depend on you (especially if you own architectural design).
  5. You won’t be able to scale the team this way – with you being a single point of failure and not having anyone to delegate to.

These are the major reasons new engineering managers do this:

  1. They are misaligned with expectations and think they still need to do programming or architectural design.
  2. They are not yet confident in their new role and they fall back to what they know they’ll feel productive and useful in.
  3. They don’t (think they) have senior enough engineers on their team to make technical decisions or they don’t trust them.
  4. There’s just too much to do in the team and they want to jump in and help. If you keep focusing on your personal contributions, such as writing code, architectural design, and day-to-day decision-making, you will constrain your team to only what you can fit into your own schedule. This is not the way to scale your team. If it’s usually your code that gets them over the finish line, you’re missing the point. You aren’t providing growth and scaling for the team, you’re providing some extra value as an engineer. If it’s another engineer that your team needs then hire one!

How to fix it

Well, first, figure out your real reason(s) for still doing significant tech work in your team. Be honest with yourself.

If the root cause is that you want to feel more successful and you regularly fall back to programming or architectural design then just trust me and take a leap of faith. You have a new role now with different responsibilities. Focusing on your team’s health and growth will pay much higher dividends than still being half an engineer.

If this is about missing capacity or skills in your team then you need to make a plan, sell it and execute on it. Depending on the situation you might need to work on expectation management with your team’s stakeholders, giving them a more realistic timeline, and/or start planning out the future of your team – meaning headcount AND skillsets, too. It’s OK to be the person driving the high-level technical decisions for a while, but you should have a plan in place about how you’ll grow or hire your successor in that role.

I wrote a bit about it back in 2017 – Engineering Managers, Stop Coding!

Not giving (enough) holistic feedback

Give holistic feedback Most new managers are comfortable giving technical feedback since that’s what they’ve been doing for years. Many are uncomfortable giving other kinds of feedback, though. They don’t challenge their team members on other non-technical growth areas like collaboration, communication style, or ownership. This usually results in the impression that being a manager is the way to have technical authority over a group, which makes individual contributors wonder what the technical career track is even for.

Another issue with giving only tech-related feedback is that the growth of your direct reports is hindered by this on all levels. Technical skills are important but there are other aspects that are equally crucial – a group of engineers, however amazing they might be, won’t ever work as a real team if their communication skills are not there, for example. Your job now, as an engineering manager, is to keep a holistic watch over your team.

How to fix it

Identify what’s hard for you to give non-technical feedback. Is it just a lack of awareness or does it feel weird to talk about those areas?

Take the time to understand the technical and non-technical skills that your company looks for in engineers on all levels. A useful trick here is to map it out to your experience and career, that way you’ll be able to empathize with your direct reports and give insights or even examples.

One of the many ways to give feedback is to give it in the context of career progression. Use this framing to set goals on both tech and non-tech aspects for your team. Even just regularly thinking about it will force you to pay attention to more than just the technical delivery, and make it easier to talk about non-technical areas for improvement as needed for future promotion or meeting the expectation on their current level.

If you’re looking for an easy-to-follow and effective feedback framework I got you covered: Thoughts on giving feedback

Doing all the project management

Delegate project management Interestingly this is what probably most engineering managers would love to delegate – but often we feel we can’t. There’s just too much at stake – stakeholder communication, making sure the project is running smoothly. It’s just too risky AND it’d just take the engineers’ focus away from what they do best – programming, right?

Actually, if you have a very small team, as a manager, you might just be the right person to do most of the project management. It might even be part of your job description you being accountable for this.

That said, as your team grows and so do its members, your individual contributors also need to learn how to run projects themselves. The more senior they get on the technical track, the more they will be expected to understand not only how to solve tough technical problems, but also how to break down the solution into milestones and coordinate others working on them.

How to fix it

The “fix” for this is to understand your ICs career paths and realize you regularly need to delegate project management to help them grow. You can start with them shadowing you, then you can work together, dividing the duty but eventually they need to run projects by themselves, you acting more like a coach or consultant to them in this.

Not sharing enough information with the team

Give your team context Being an engineering manager suddenly you’re now in a position where people will naturally pass more information on to you. This might happen because you’re in more planning meetings with e.g. the product team, or management meetings with your manager or other peers, or simply you become the interface of your team to other teams. Whatever the reason is, now you’ve got a lot more details about what is going on around your team. This information is both useful and critical for you to lead your team well, so use it wisely! What you need to do is distil this information and then communicate it to your team in a way that helps them understand their work in context.

When you fail to give your team the context for the work and just pass on tasks and work items to them, you’re basically communicating that their role is simply to execute whatever ‘the boss’ says. They are doers and you are the decider. This is not only highly demotivating to most folks but also kills all seeds of ownership and further initiative in your team. You’ll also lose valuable feedback from them. As seen in the previous points, this would also block your engineer’s growth above a certain level.

Now, you might think that by not involving them in certain discussions and keeping information from them you’re actually helping them focus. There’s a fine balance here, of course.

How to fix it

Don’t exclude your team members from meetings where they could get the necessary context to actually be able to feel ownership of the projects. Don’t be afraid to even completely delegate representing the team on meetings to them!

Your challenge as a manager is to find the right balance of providing information to the team and inviting them along to get, own and shape that information, while also not overwhelming them with meetings. The good news is that if you have an active and productive relationship with your team you’ll get timely feedback on this and you can course correct. Make asking if they want to tag along with you the default.

Not doing one-on-one coaching

Give your team context Conducting good one on one sessions is one of the most frustrating skills new engineering leads need to learn. It’s frustrating for many because this is one of the areas of leadership where you don’t have a step-by-step guide and it takes a fairly long time to form a good one on one relationship with each peer.

That said if you’re avoiding 1:1 sessions or you’re simply rushing through them you’re making a grave mistake. These sessions are essential to building rapport with your team members. The lack of good relationship with them is harmful in many ways:

  • They will feel neglected and not cared for
  • Their growth will be hindered
  • You might be the last to know if there’s trouble and it might be too late to act then
  • You’ll miss out of useful information which would come from your team

I see two usual mistakes around one-on-one sessions: one is simply not having them or having them only sporadically because the new manager thinks they are not important. This goes hand in hand with having the manager’s focus in the wrong places – if you’re still knee-deep in programming you won’t even think about such context switches. The other mistake I see is turning these sessions into a status report about the ongoing project(s). Sometimes this is even initiated by the direct report, not knowing a better way to fill the time of the 1:1.

How to fix it

Learn about how good one-on-one sessions look like! Think about the good and bad experiences you’ve had with your managers in this area. 1:1 sessions are great to build trust, share information, give and get feedback (both on your performances and ideas), career coaching your direct reports and ensuring alignment.

You can read more about how to do one-on-one sessions here: The basics of one on one sessions

Closing words

As a manager, your output is not measured by your individual work. Rather, your output is measured by the work of your team and the people that you influence. The work you choose to do, and the work you choose to neglect or delegate, will lead to amplified outcomes in both positive and negative directions.

Make sure that you aren’t trying to be a senior engineer who has direct reports. Your job now is about generating leverage by developing your team. This means delegating the technical work to them while helping them identify other skills they need to successfully grow as an engineer and as a team. If you do this, you’ll have a happy and motivated group of amazing senior individual contributors to work with and a nice career in management. When you turn your focus to the work you can do to improve the team’s output by training them to do technical work, project management, giving them the context they need to make decisions themselves and own projects, ensuring that they work well as a team, you create multiplicative value. When they become more productive and less reliant on you, you will also have more time to identify bigger challenges and scale your team (or the number of teams).

UPDATE 2021 Mar 19

This article had some success for 2 days on Hacker News. Lots of interesting comments (caveat: some disagree with parts of the article), let me quote a few:

I would like to add my perspective as an IC who is reporting to a technically-focused manager. I feel frustrated that my manager does not spend even 10% of the time they spend coding on coaching/guiding/giving feedback to me. I feel that part is more important aspect of being a manager compared to churning out code. I understand the need to keep on top of the codebase, especially when coding is something you really like. But if you don’t spend enough time on the growth of your reports (amongst other responsibilities of a manager), why bother becoming a manager?

A lot of technical leads who become managers assume they’re doing a good enough job on the management side and that they have to master every technical detail, when the truth is they’re only convincing themselves that their split allegiances, attention, and priorities aren’t a problem of trying to work two jobs.

An engineering manager who was technical, listens to their staff, and delegates can still be respectable and has the time and focus to help the team in a greater capacity with non-technical things proactively rather than reactively.

An engineering manager who can setup an HA database is as useful as a fireman who can play chess. It’s all well-and-good, but it doesn’t add value to the management of the team if someone else has that duty. Technical leads yes, but not managers.

I’ve been an engineering manager for a couple of years. I’m still expected to do 50% engineering and 50% people management. As the article describes, it is a struggle to do both well. I don’t see this responsibility split changing in my current role. I do often wonder what it would be like to be 100% people focused, and whether or not I would miss engineering too much.

When my role first changed, I was very intimidated by doing one-on-ones. I never felt satisfied with the one-on-ones/catch-ups I had with the managers throughout my career, and I wanted to make sure I was doing a good job with that aspect of my role.

In about 90% of companies I’ve seen they expect you to do all the manager things and be an engineer too. It’s not so much a mistake individuals make as that it’s an explicit expectation that you’ll be wearing multiple hats.

Folks generally get bombarded to manager because there’s no career ladder and this is what people think they have to do next to be able to continue to grow. And once you become a manager it doesn’t suddenly create a head count to backfill the “loss” of an engineer so there is continued pressure on you to do both.

Once career ladders start to get better defined this starts to change too, and as the size of the company increases manager and IC responsibilities end up being different people. But companies seem to only figure this out at the 500-1000+ employee threshold.