The death and revival of the hands-on Engineering Manager

There were always 2 types of engineering managers:

1. Engineering managers - very hands-on, they take tasks in every sprint, know the codebase well, and can help the team fix hard bugs.

2. Engineering managers - attending meetings all day, working on coordination, on processes, etc. Zero coding time, full-time managers.

The sad truth is that almost all of us start from type 1, and slowly become type 2:

I’ve been through that transition twice.

When you are first promoted, you are close to the code. You were responsible for big parts of the codebase, and it’s easy to stay a part of the sprint. For the first couple of years, you code 30-70% of your time, with a slow decrease as your team grows.

Then comes a sprint where you just have too many things. Tons of meetings, a new project you are leading, the usual stuff. So for the first time, you decide not to take on any coding task. One sprint becomes 2, then 5, then 10. Suddenly a year went by, and you barely opened your IDE. Now it’s not a question of having no time - it’s a habit you have lost.

2 years ago, I covered that in the slow death of the hands-on engineering manager, focusing on what I did as a director to break that cycle. The accompanying LinkedIn post went viral, reaching 2.5 million people.

But ~80% of the comments came from managers who said it’s by design:

I believed they were wrong, but it was an interesting debate. There were 2 camps, and both made sense.

That debate is OVER. There is no question about it. There is no place today for 100% managers in the software engineering world.

And it’s NOT because of the rising expectations from executives, or about being able to do “so much more with AI”. It’s simply a must for us to make the right decisions.

Let me explain.

Most professions change very slowly.

For example, newsletter editors. You had print, and you transitioned to web, with new things like SEO, Facebook, Twitter, CMS, etc. As the person overseeing reporters, you were able to slowly catch up with the shift as it happened.

But in some cases, it's abrupt.

Like teachers who became school principals, and then COVID hit. For years you could evaluate your teachers because you knew what great teaching looked like. Then overnight, teaching moved to Zoom. Your teachers are managing digital “classrooms”, students with camera turned off, distractions everywhere, frustrated parents - a completely different version of teaching. If you try to create guidelines and mentor your teachers without trying to do it yourself first, you’ll probably make a mess out of it.

We are now at a similar place in software engineering. If we want to really understand our ‘new’ profession, we have to experience it ourselves. And that understanding is crucial for our careers.

Of course, getting that understanding will be very costly.

You’ll need to pay a painful price

Each of us has a fixed attention budget. We just CAN’T do everything:

• Making sure the delivery and quality are at the right bar

• Being there for our people

• Supporting our customers and existing features

• Setting the technical direction

• Thinking about the team’s future

• AND being deep in hands-on tasks

It’s just impossible. Yes, even with AI - you can be much more efficient, but you can’t do everything. Something has to go. So usually, the first thing that goes is our attention to the people. Especially as in parallel to hands-on expectations, we are also managing bigger and bigger teams.

Just 3 weeks ago, I made a decision that I already regret.

I reduced the cadence of the 1:1s with my engineers, canceling a lot of them, to free myself up for more hands-on work. Last week, I already felt the negative effect. People were more frustrated, and I was not sure why. I felt we were very quickly gathering Relational debt.

And still, I feel it’s a sensible decision for now, both for our careers and our orgs. There are so many challenges that you can only truly understand if you experience them yourself - PR overload (by engineers and non-engineers), how to parallelize, how to make sure you still understand the agents’ output even when it’s tempting not to.

Coding with LLMs yourself will also help you avoid falling for the hype.

The antidote to the AI-bullshit

All AI-related hype comes from engineering leaders who are detached from the day-to-day. They vibe coded something, and “saw the light”. They started ‘org transformations’, layoffs, and token-maxing leaderboards.

I feel lucky to be in a place where there is none of that. Our CTO (~150-eng org) recently took a couple of weeks to build a real and complex production feature, end-to-end, to experience the current state of the models and our codebase. Nobody measures our tokens, we didn’t have layoffs, and we (first-line engineering managers) have a lot of freedom in how we help our teams adapt.

I feel we can have a sensible conversation about what works and what doesn’t, because he doesn’t rely on second-hand inputs. If all your knowledge comes from tweets and LinkedIn posts, you’ll make bad decisions and alienate your engineers.

Final words

You thought your coding days were gone forever. Well, you got an extra life!

Start small. A very simple bug fix or UI change. Just make sure you have the development environment and needed tools set up.

Then, free yourself up for a couple of weeks (you know you can do it), and take a REAL production feature end-to-end. Just once. I promise you, you’ll learn more about what your engineers are going through than in hundreds of meetings.

My favorite reads of the week

1. Envelope EMs vs Letter EMs. Jason Fried describes two types of builders: envelope entrepreneurs, who focus on fundraising, strategy, and operations, and letter entrepreneurs, who obsess over the product and the craft itself. He argues that many founders gradually become distracted by the envelope and lose sight of the letter.
   James Stanier applies this to EMs: some primarily coordinate and manage process, while others stay deeply engaged with the work and add value through product and technical judgment.

2. The Best Prioritization Is No Prioritization. A unique solution to one of our main problems as engineering leaders.

3. The Antithesis Principle. Another superb article by Shreyas Doshi.