6 Harmful Misconceptions About Being An Engineering Manager
I want to talk you out of becoming an engineering manager.
The role is extremely challenging, but this is not the problem. The problem is people’s beliefs about the role, even while in it. These misunderstandings lead to frustration and difficulties, burnout, inefficiencies, and worse.
I’ve seen this many times before, and I’d like to help you avoid it. Although my perspective is one of many, the misconceptions below are universal. After learning them, you can decide if you truly want to tackle the challenge of becoming an engineering manager. Regardless of your decision, you’ll at least know more about the role and its responsibilities.
This begins with one of the most harmful misconceptions about engineering managers.
1. It’s a technical role
When considering or transitioning to engineering management, this is one of the most common misconceptions engineers struggle with. Even worse, it creates or magnifies other misconceptions, such as believing it’ll be easy to transition to the role.
Understanding this misconception requires looking at work from two different perspectives.
The Engineer’s Perspective
First, let’s review the steps you’d take while working on a feature:
- You complete and deploy the feature
- A QA team reviews it and finds bugs
- You fix the bugs
- The feature rolls out to end users
- You move on to the next iteration based on feedback
In all of these steps, you spend most of your time alone working with code. You communicate when needed, but your major responsibilities are figuring out what needs completing and then implementing it.
And all of those responsibilities are technical. But what about when you’re an engineering manager?
The Engineering Manager’s Perspective
Your steps in this case are the following:
- Assign the feature to that engineer because you know it would motivate them, and they’d be a good fit for it
- Track their progress to aid in removing roadblocks and making the process efficient
- Communicate with them about that progress and any issues they’re having
- Discuss their progress and issues with the project manager
- Learn about the bugs in the engineer’s work after QA review
- Filter out the bugs that aren’t the engineer’s fault
- Document the ones that are, build patterns from these and their other work, and help other teams minimize the bug rate
- Discuss the bug rate and patterns with the engineer to help them improve
- Continue tracking their progress after
By now, you’re probably seeing the difference — if not, take a long look at that list and ask yourself:
How much of your work as an engineering manager was technical?
Yes, it is beneficial, even ideal, to understand the technical aspects of your engineer’s work. You will need at least some of this understanding to identify patterns and develop appropriate guidance. But you’re not coding, you’re not fixing bugs, and you shouldn’t be (more on this in misconception six). Those are your engineer’s responsibilities.
Yours are handling deadlines, communication, tracking, and coaching, among other non-technical duties.
In short, transitioning to engineering management doesn’t just add to your responsibilities — it changes them completely.
This fact leads me to the next misconception.
2. The transition is easy
Although this misconception doesn’t always stem from the last one, it usually does. Because many people think engineering management is a technical role, they think they know how to do it or that they’ll pick it up quickly. As a result, the transition becomes even more difficult.
Unfortunately, the problems don’t end there. The work also makes you feel uncomfortable — worse, it makes you feel unsafe. A good way to think of this is with an analogy.
It’s like learning how to drive
You see hundreds, maybe thousands, of examples of people driving every day. Your parents drove you as a kid, and you’ve seen it in movies and on TV. So, you think there’s nothing to it. You think you’ll be fine when you drive.
But then it’s your turn.
Suddenly, you’re the one who has to:
- Control all the levers, knobs, and buttons
- Merge with traffic
- Manage your speed
- Learn the road signs and lights
- Maneuver through construction areas
- Pay attention to all the cars driving around you
You’re always doing all of this all at once. Usually, you’re doing all of this very quickly with little time to take a breath. You’ve tried to prepare, but you’re only thinking one thing when you sit in the driver’s seat:
It’s all on you now.
No one is driving for you anymore — you are the responsible one. Not only is this terrifying, but for some, this feeling doesn’t go away for months or even years! And remember, you’re not just driving yourself when you’re an engineering manager — that’s more similar to an engineer’s job.
When you’re an engineering manager, you’re driving yourself and overseeing your team, tracking them, coaching them, communicating it to others, and so on. Because you’re doing all of this simultaneously, you also have to prioritize what’s most important at any given moment, organize yourself, and, again, still find time to breathe.
You can always go back
What makes this even more stressful for many people is they think they can’t go back, but they can.
You can always go back to an individual contributor role.
Yes, it can be embarrassing and not an easy conversation with your boss (although not always). But if you’ve given the role everything you have and you’re not successful, or it’s affecting your personal life or mental health, then schedule that conversation.
A good boss will understand, and you can always phrase it in terms of how it’ll make the company more efficient. More importantly, getting the engineering management job means you’re valuable to the company, and they want to keep you in some capacity, so you don’t have much to worry about.
Regardless of how they or your colleagues respond, you have nothing to be ashamed of. You should be proud you tried and were strong enough to admit it wasn’t a job you enjoyed or were a good fit for.
Many could learn from you.
3. You don’t have to serve anyone anymore
I mentioned engineering management has its benefits. These include rewards like praising your team for a good job and seeing them grow. Unfortunately, many people also think becoming an engineering manager means they’ve “made it,” so to speak.
To understand this, think of a famous person such as a musician, author, or actor. They spend much of their early years working hard for little recognition and pay, and their audience is small.
But then they get their breakthrough moment. Suddenly, they have assistants, publicists, and managers. Those people take care of much of what they had to do before. And they don’t have to listen as much to others because now they get to tell people what to do.
This is how many view transitioning into an engineering management role.
The problem is this view makes your job harder and you less effective in doing it.
Why it’s essential to serve as a manager
I firmly believe we’re all servants of one another.
This is not a “servant” in the sense of someone giving a person orders and expecting them to follow them. Rather, this is in the sense of helping, supporting, listening to, and assisting one another. An engineering manager must act this way.
Engineering managers must support their team as much as their team serves them.
You may disagree with this, even after I’ve finished explaining. That is your right to do so, and it’s not the only successful way of thinking. But it is the one I’ve seen work more than any other.
Bossy managers get short-term results
Pretend you’re an engineering manager again. You get results by giving orders and those orders being followed. Failure to do so results in punishment.
Now, one of your engineers — let’s call him Mike — is struggling to turn in work on time. You schedule an immediate call with Mike and tell him he needs to fix this immediately, or there will be consequences. He starts getting his work in on time.
Okay, so why wouldn’t you do that? Why is being a supportive manager better?
Supportive managers get long-term results
We’ll use the same scenario: Mike is not hitting his deadlines.
In this case, you’ve already gotten to know him by the time this happens. Of course, this is challenging because many engineers, including Mike, are introverted and want to be left alone, but you’ve done what you can to build a relationship with him.
As a result, you know he needs a gentle touch. You reach out, schedule a call, and start talking with him. You can see this is uncomfortable for Mike — he knows he’s missed his deadlines, and it’s written all over his face.
Maybe you start by asking him how his day is going or talking to him about how great his work was on a previous project. Your goal is not to waste time but to make Mike feel comfortable. You know some engineers respond to a more direct approach, but you know he needs to ease into this conversation.
Once Mike’s face relaxes, and he’s talking, maybe even smiling or laughing a little, you say something like, “Has something changed? Normally, you get work in on time, but I noticed that hasn’t been the case lately. Is something going on?”
What’s important here is you’re talking with Mike, not at him. You’re asking if something is causing the delay other than him just being a “bad employee.” Also, you’re showing him you’ve been paying attention to the work he does complete on time.
Unfortunately, your effort is not guaranteed to result in a productive conversation, but it’s better than blaming or threatening him with punishment. And there is always the chance he will open up.
For example, maybe he explains the task was more difficult than he thought and he’s been struggling to figure it out. His explanation leads you to ask why he hasn’t asked for help, to which Mike explains he thought he shouldn’t. Maybe he wants to move into a lead position or even higher one day, and he’s gotten the impression asking for help shows signs of weakness and makes people think he’s not a leader.
Maybe the conversation never goes in this direction, but does it ever get there without you supporting him?
No.
Now, you have a chance to talk to Mike about your experiences with feeling this way and what you did to improve. You tell him he does need to get his work in on time and say you’re going to assign someone to help him so he can complete it faster. Mike may not like this, but he may also recognize it’s necessary, and with how supportive you’ve been, he’s willing to cooperate with you on this more than if you hadn’t been.
This is the true key to being a supportive manager. If you show your engineers you have their back, they’ll have yours. You’ll build better relationships and get better results from them.
But there is a potential drawback to this way of doing things.
Doesn’t this put you in a position to be taken advantage of?
I think it’s amazing when people try to do this because they’re showing you their true colors — a bonus to being a supportive manager because you learn even more about them. You can spend time working with such a team member on these issues or focus your energy on the ones who aren’t trying to take advantage of you.
You can also avoid this by not letting it happen in the first place. Do your work as a supportive manager with this possibility in mind, learn from your mistakes, prepare for when people try to do it, and you’ll be just fine.
4. You’ll be another useless manager
As an engineering manager, your work is invisible. Additionally, the better you get at handling your responsibilities, the more efficient you become with them.
All of this leads people in and not in the role to think engineering managers (all managers) don’t do anything. The opposite is true, but let’s start with why your work is invisible. For that, we have to return to the initial misconception’s example.
Your work is invisible but has a massive impact
As a reminder, in the example from the first misconception, you were monitoring an engineer’s work on a feature and bug fixes. You can clearly see the result of their work in both cases, but no one can see the result of you monitoring them.
You did create a report of their bug rate and trends, you coached them about this, and maybe you recorded your meeting with them. But none of your work is visible in the end product itself. And all of the work you did to help the employee get back on track? Also invisible.
But while your work may not be as visible as your team’s, your effect on their success is measured in that success.
This is why it’s essential to be a supportive manager. At the end of all the work, your team determines your success, and you determine theirs. This doesn’t make you any more important than them or them any more important than you — it just means you have as much effect on the end result as they do.
Think about it like this:
- What if you never took the time to learn about that engineer falling behind on their work?
- What if you never coached them?
- What if you never thought about who would be the best fit for a particular task?
- What if you didn’t create that report to monitor bug trends?
What would happen? Some ICs can get back on track with minimal oversight and assistance, but many struggle to. Having said assistance improves and quickens their chances of doing so.
The reason you’re doing less is because you did more
Efficiency is not poor performance.
Yet, when we see someone working more efficiently than someone else, we often mistake what we see as not putting in as much effort or not having as much passion. But as you get better at fulfilling your duties as an engineering manager, you’ll improve and streamline your process.
For example, initially, you might take calls for every last little detail your engineers want to discuss. Over time, you’ll realize most issues don’t need a call and can be taken care of asynchronously (such as through Slack).
Does that make you worse than an engineering manager who still always takes calls? No. It makes you more efficient. Sometimes, that means doing a lot of work upfront, so you’re not doing as much later. For example, you can and should build tools and templates for your team to automate and standardize the work.
Additionally, having streamlined so much of what you do allows you to focus on the parts that need your attention or to deal with sudden shifts in strategy or emergencies without falling behind as much on your other tasks.
These are the signs of an effective engineering manager. Be proud when you start showing them.
5. You need to be the best on your team
Fear drives many of these misconceptions or worsens them. This is no truer than for this one. Far too many engineering managers are afraid of their teams when it should be the opposite, an idea driven by the worry that if they aren’t the best, someone will replace them.
But you’re more at risk of losing your job if you’re scared of your team’s abilities than if you’re excited by them.
You want them to be the best, and you want to be the worst.
Why you want to be the worst
Fearful engineering managers hire less skilled engineers and fail to develop them as much as they should (and could). In extreme cases, those managers may even create an environment that drives those engineers to transfer or leave, seek to transfer those engineers themselves, rate their performances poorly, or be much harsher on them overall.
Engineering managers with this mindset also fall victim to thinking they need to do everything themselves (more on that in the section below). But this is just not good in any way.
Remember, your team’s success determines your own. So, the only way to be successful is to make them successful — doing anything else hurts your results, reflects negatively on your performance, and potentially leads to that replacement many fear so much.
But does this really mean you have to be the worst? It does, but worst doesn’t have to mean bad. It just means you’re not an engineer anymore, and you shouldn’t try to be.
You want your team coding better than you ever did. You want them communicating and collaborating better. You want them to start showing the skills of senior engineers and leads (and, yes, even engineering managers). And you want to help them develop those skills.
Remember, you are not training your replacements — you are training your team and future colleagues. Potentially, you’re even training people you’ll oversee in their new roles someday when you, too, benefit from promotion. One of the best ways to guarantee that is to show the people who work over you just what kinds of results you can achieve in products and people.
6. You have to do everything yourself
This is a very easy and tempting misconception to fall into, in part because this one can start with good intentions.
The destructive cycle of doing your team’s work for them
Imagine you’re a new engineering manager. As with misconception one, you’re tracking your engineer’s progress and bug issues. You notice they’re struggling, and you know how to solve their issues. You’re also swamped with work, and you’re already overwhelmed with the transition, so you don’t have much time to coach them on these issues.
But you do have time to fix them yourself, saving you time, and helping them out. Plus, you can always talk to them about what you did later.
So, you make the fix! The engineer, the project manager, your boss, and you are happy.
Here is where the problems start, though. The first is you really do want to speak with the engineer about the fixes you made so they can learn and improve for the future, but you have so much work to do that the talk never happens.
The second is that the engineer starts making mistakes again. They might be the same or different mistakes, but they didn’t learn anything from before, so they’re struggling to fix them without help.
They may not ask you for that help directly, but you’re in the same situation as before. You were one of those engineers who learned how to figure things out on your own, so you know how to do this. And you want to coach them to help them do the same, but you just don’t have time again, and it would be a really quick fix…
This cycle will repeat itself endlessly, worsening each time. It will seem manageable, even noble, to do what you’re doing, but it is neither. In fact, it is very, very damaging for reasons such as:
- Your bosses never becoming aware the engineer is struggling in this way
- Being overloaded with even more work
- Falling behind on other duties
- Burning out
- The engineer becoming more and more dependent on you
- Their career suffering because they won’t have developed the skills necessary to progress
- Other engineers wondering why you aren’t giving the same assistance
- The engineer getting upset with you if you do start coaching them
It seems like a lot for such a small thing driven by good intentions, but this is what can happen and why this misconception is so dangerous. What’s worse, you’ll be tempted to fall back into the cycle whenever someone new joins your team.
But you have to keep toughing it out — it does get easier with time. You’ll develop training guides and packages, you’ll see the long-term results of coaching, and you can assign your senior engineers and leads to help.
It all leads to less work and a more successful team.
Do you still want to be an engineering manager?
Then, I applaud you. You are truly courageous for being willing to make this leap. So, what do you do now?
First, take a breath. There’s no rush. Let what you’ve learned sink in, and reflect on it. When you’re ready, I’ll share how you can prepare to become such a manager.
I look forward to you putting those steps into action.
Do you not want to be an engineering manager anymore?
Then, know that I still applaud you. Too many people think they know what they want, only to realize they don’t. But you do, and it takes courage to say no to an opportunity that isn’t right for you. So, what do you do now?
First, also take a breath — there’s no rush with this, either. This industry is full of opportunities, so keep exploring your options.
I look forward to what you decide.
Make the right choice for you
Six misconceptions about the engineering manager role are:
- It’s a technical role
- The transition is easy
- You don’t have to serve anyone
- You’re no longer valuable
- You need to be the best on your team
- You have to do everything yourself
The opposite is true in every case. Engineering management:
- Is a role requiring you to focus on people, not code
- Is a very, very difficult transition due to the above element and others
- Requires supporting your team as much as they support you — this relationship nets you better, long-term results
- Means doing invisible but very valuable work since it’ll determine your team’s success, which also determines yours
- Better when you’re the worst on your team since a superior team means superior results
- Needs you to delegate to and coach your team so you can focus on other work
Knowing and following these elements of engineering management makes you happier and more efficient, productive, and valuable. It also means not having to deal with the frustrations and difficulties these misconceptions bring with them.
You’ll have one of two reactions to the above. One is that you’ll decide you still want to be an engineering manager. The other is that you’ll decide you don’t want to be one.
Both are good choices, and you’re an amazing person either way. The important part is you’re informed so you can make the best choice for you, your career, and your life.
Nothing would make me happier.
