Common Mistakes of New Engineering 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.

I initially did lots of research on how to do one-on-ones, but it was only after getting experience talking to people that I finally felt comfortable. I started getting some nice feedback from my lines, so I wrote some thoughts about how I like to do one-on-ones:

[link redacted]

I think good one-on-ones are very important to keep people happy and productive. I'd recommend any new engineering managers to spend time learning how to do them.

Managers should get paid more than engineers.

In my experience the "mistakes" mentioned in the article are mostly a motivation problem. The assumption is that a successful engineering manager is one that makes their team thrive whereas in reality the companies only reward individual success. Same goes for developers, best developers only get junior->senior promotions while the ones that join the most meetings and do strategical thinking goes towards engineering management and leadership.

1. Still doing much technical work

If the technical work tackles an important bottleneck or solves an immediate internal problem for the company, this will be seen as incredibly valuable (even more so compared to the eng. manager were still a developer) as opposed to delegating it.

2. Not giving (enough) holistic feedback

In my experience, managers never evaluated based on how helpful they are to their teams. They only need to avoid negative feedback, which is not necessarily aligned with being honest and direct to their reports.

3. Doing all the project management

There's an urgent problem. Eng manager dives in, quickly fetches developers from teams and micro-project-manages them until the resolution and moves on. This is recognised as a success.

4. Not sharing enough information with the team

Sharing is good for the team members, not necessarily relevant or hurtful for the managers' success.

5. Not doing one-on-one coaching

Same as above, managers help their reports out of good will if they do but if they are evaluated on their help with delivery and not the health of their team, they do not have the motivation.

I've come to realize that the promise of a 50/50 split between technical work and management after getting promoted to a data science technical lead manager is not something that is feasible within my org. Unfortunately, I'm at an organization in which the only way up is for ICs to move to management. So I'm leaving to another company that has much more runway for IC career progression.

I've got a great relationship with my current employer, so I've mentioned this career progression issue to them in my exit interview and it's something that middle management is tracking, but getting corporate leadership on board to change their thinking is difficult since our revenue is driven by billable work on a man hour basis. This creates an incentive for people to build teams of direct reports under them and grow a business line/contract to increase revenue in order to show value and accelerate career growth.

Until the company can get more service contracts where they're selling software/licenses/support instead of butts in seats, I don't see this paradigm changing any time soon.

Very interesting how business models drive things like this. Obvious in hindsight, but still interesting to think about in terms of incentives driving org structure.

I think those 2 words should not be in one title. Recipe for hot mess. Choose One and stick to it. I am not sure what kind of mentality to mix both. There are not compatible positions. Cost of context switching is not cheap.