5 Engineering Management Misconceptions I Wish I Knew Earlier

I misunderstood the management responsibilities so I was not able to work with my manager effectively

When I started my career, I had a lot of assumptions about management roles. Most of them turned out to be wrong. For example, I assumed management was only about delegation. They just assign tasks and have nothing else to do. (OK, don't judge. I know how wrong that is now 🤦‍♂️)

I figured out some things out overtime as a software engineer, but most didn’t become clear until I became a manager. I wish I'd known these misconceptions earlier. It would've made my work with my manager much more effective.

I hope these clarifications can help those who have the same doubts.

1. “Becoming an Engineering Manager is a promotion.”

Well, that depends.

Based on the engineering ladder, there are two career paths:

• The IC (Individual Contributor) path

• The management path

It looks like the following:

If you become a manager for the first time, you're likely transitioning from a senior developer position. Some organizations have an Engineering Manager (level 3) position, and some don’t.

In that case, if you move from Senior Developer (level 3) to Engineering Manager (level 3), it is not a promotion. It is a career path switch. And it usually does not come with any benefit or salary increase.

However, if your organization allows a Senior Developer (Level 3) to move to Engineering Manager (level 4), it is indeed a promotion.

2. “Management Roles Have a Higher Salary.”

Salary levels depend on the engineering ladder. The higher you are on the ladder, the higher your salary. It depends on how much impact one can achieve. For example, a Senior Staff Engineer would generally have a higher salary than an Engineering Manager.

On the contrary, the difference between developers and managers is only their path. You can find relevant information on websites like levels.fyi.

If money is the only concern, I would suggest staying on whichever path that motivates you the most. Your passion will drive you to move further on that path.

3. “Managers don't need technical skills.”

Technical skills still matter, but in a different way. Managers don't usually code, but they need to be clear about the technical architecture and direction.

The main benefit of having good technical skills is to help identifying bottlenecks when supporting the team. In rare situations, this also helps with preventing ill-intentioned members from procrastination and framing others.

For example, if a senior developer suggests a system separation, an EM with good technical skills can immediately identify possible issues and blockers before they form a plan. This makes it a lot more efficient than creating an actual proposal and involving the entire team for discussions.

On the contrary, managers without good technical skills would waste more time seeking help from engineers. Also, it would be more challenging for them to have meaningful discussions with senior developers.

4. “Management is an escape from coding.”

Grass is always greener on the other side.

This is a graph of what an engineering team’s responsibility is like:

Let's make this comparison:

• The major responsibility of a software engineer is to focus on technical work.

• On the contrary, an EM needs to handle all three areas for the team: people, project, and tech management. That is more complicated than focusing on solely technical work.

As a result, getting away from coding does not mean the job is easier.

If someone feels stuck coding and wants to get away with it, I would not suggest the management path. It is guaranteed to have more pressure from day 1.

5. “Members should know what Engineering Managers are doing but they don’t.”

There are many reasons that we don't know what our managers are doing. One obvious reason is confidentiality. For example, sensitive information, personal information, etc.

The second reason is for reducing cognitive load. Since developers and managers have different areas to cover, they will be separated. Just like different developers are working in different teams, it does not make sense for one developer to know what's going on in a different team.

And the separation is intentional. It protects developers from overloading their cognitive load. Every individual has limited cognitive load and energy to process information every day. We have to be selective about what we process. For example, it does not help with developers’ daily work if managers keep sharing with the team how many interviews they do every day.

Final Words

Many of the assumptions about management I had early in my career turned out to be myths, and understanding the reality helped me adjust my expectations.

Whether you’re thinking about making the switch or just want to work more effectively with your manager, recognizing these misconceptions is a good start.

Have you had any misconception that is not listed here? I’m happy to hear about them :)

---

Thank you for reading the post!

❤️ Click the like button if you like this article.

🔁 Share this post to help others find it.

Resources

Access structured 👣 learning paths if you’d like to move forward in your software engineer career more systematically.

Guest Post Opportunities

If you are interested in writing for Tokyo Tech Lead, check this guideline post and let’s build something together!

Contact

You can find me on LinkedIn or Substack.

If you want more content like this, consider subscribing to my newsletter.

See you in the next post!