What I gave up to become an engineering manager

> I realized that although my one foot was in the new role, my other foot was still in the previous one. I needed to stop doing the old things to make room for the new stuff!

This is exactly why it seems to odd to me that many companies see management as a logical "next" step in someone's career. It is a completely different path and requires very different skills. At least, the way many companies have set up their company structure.

Tangentially related: I've been struggling with the decision to go for the technical track or the management track in my current org. I'm lucky to work in a company that has a technical ladder (though one can certainly argue that everything above staff isn't really realistically achievable). Certainly has my preference.

But being in Western Europe, most companies don't have this, and with the current state of the industry, with somewhat regular lay-offs, if I have to change jobs and want to stay an IC, I'll basically have reached the plateau of where I can get career-wise. The only way to get past that barrier is becoming an EM.

I hate to even have the thought, because, purely on principle, it's the worst reason to become an EM. But career-planning wise, I'd be crazy not to.

Anyway, your post is another argument in the column to stay on the technical track a bit more, we'll see what life brings :).

Of the given list, any innovative and competent staff developer should already have given up (1) and lost (2). Similarly for (3) if you're creating new designs and patterns of working it can be an uphill battle to get it socialized and accepted, even if/when it turns out to be just the thing that's needed.

  5. Building Things
  4. Focus Time
  3. Fast Feedback
  2. Conflict Avoidance
  1. Short-Sightedness

The other thing about (5) is that many managers think/feel like they 'built' something when their team did. Of course they were also part of the team, but some would say "Back when I was in ... I built..." rather than "my team built...". Taking it to the top a CEO may say they built such and such, but really they built the company that built it. So they created the conditions and directions/motivations but didn't make all the decisions along the way etc. This varies greatly though, some CEOs are super-technical and can get in the weeds on occasion and make a good call.

I'll leave one more point that many managers give up (but shouldn't):

  6. Keeping up with currently used and relevant upcoming tech
     to communicate effectively and make good decisions + plans

Middle management (eng. managers) is by far the worst role in software engineering. I either want to keep working and make my way through the IC ladder or jump directly from senior/staff engineer to be a manager of managers.

Re: 5. building things: The only thing that keeps me sane since moving into a leadership role is that the what I love about building, namely watching things that didn't exist-- begin to exist, still happens. I guess I'm more of a farmer now than a carpenter, but I'm still seeing my environment change in a way that I contributed to and take pride in. That includes not only watching our product evolve, but also watching our team grow.

If it's any consolation, this jump between contributor to manager exists in other industries.

I have a friend who is a senior ground worker (managing a team that digs up roads with a JCB/backhoe to put in eg gas mains) and he'd been asked to "go off the tools" to work in head office and was debating the pros and cons.

Even inside of Google, Amazon and others it's a huge mistake to not go into management if you want to maximize your power and compensation at the company. Don't fall for the trap of "parallel careers" even the highest level technical person can't hold a candle to the power or compensation of a VP or SVP.

Roles like Principle engineer or distinguished engineer and such are just a sucker's share of the bag and make me question, why isn't this dude an SVP or VP? Why did they have to carve out a special role for him? He's probably a good engineer and good at his job, but hard to work with? Maybe he has dirt on the CTO? Those are the questions that go through my head.

Most important thing not mentioned: got a bigger salary.

If you didn't get that, you were skinned.

The best manager I had never gave up on building things and getting deeply technical: he just spent half of his time asking around people if everything is good, and whenever he saw that somebody is stuck, sat down together and helped debugging the problem (and maybe helped finding people getting it unstuck).

About meetings: he put some ,,meeting''s in the calendar entry, becuase PMs loved taking his time unnecessarily (he was still available for meetings, just not all the time).

As a high level example Elon Musk talks a lot about his managing style at Starbase in his interviews with Everyday Astronout, and it looks similar: he always goes to the place which is most critical for the product and looks at the technical issues.

> 1. Short-Sightedness

> As an IC, my focus was on immediate tasks and technical details. I thought in terms of sprints and short-term goals, which are more predictable and easier to estimate.

> I wasn’t ready to think about the uncertainties around long-term plans, roadmaps, and quarterly goals.

Promoting to management people who haven't demonstrated skills at long-term planning, roadmap design, and goal setting? What the hell. Though that would explain a lot about the state of things, wouldn't it.

Here I am having to plan multi-year roadmaps, execute them, and consider quarterly progress as a lowly senior IC. If you're only thinking about and working on sprint-sized goals, what are you actually getting promoted for past junior level?

Congrats and I hope you will make a positive difference for your team. Non-technical managers of technical teams are the bane of my professional life so it is good to see "one of us" on the other side of the fence.

Good piece. I've done mostly IC work but have had a stint as tech lead, where a lot of this applies even if people management wasn't directly part of my role.

One thing I'm curious about as well is more on the zero-to-one side of becoming an EM: If you're a "junior" manager, it seems there's quite a dearth of jobs out there. Everyone wants someone with 2+ years of experience. It's the same old entry-level-with-experience hiring conundrum, just happening again in your career.

Anyone have advice in that regard?

Managing people is such a wildly different skillset compared to engineering that it still puzzles me the former is the assumed "next step" for an engineer. Managing engineers is a facilitating job and should be viewed (and paid) as such. Companies valuing a principle engineer lower than the person managing the day to day of that engineer is a crazy bit of corporate legacy.

You can definitely be a hands-on manager who builds things, though that's often what's called a team lead instead.

Why did you move to management if you wanted to carryon coding?

2 different personality types, mindsets.

Becoming a better coder while also getting manager pay instead of moving to management is a thing ya know