The death and revival of the hands-on Engineering Manager

Meticulous, a startup that records real user sessions to automatically build UI test suites, has launched a solution that generates tests in under 5 minutes per pull request, addressing the flakiness problem exacerbated by coding agents. Gabriel Benmergui, writing in the Manager.dev newsletter, argues that the debate over whether engineering managers should remain hands-on is over, asserting that 100% managers have no place in software engineering today because they must experience the new AI-driven development process to make informed decisions. Benmergui's previous post on the topic reached 2.5 million people on LinkedIn, with about 80% of comments from managers who believed the shift to non-coding was by design.

In every product I've worked on, UI tests were always flaky. You can either live with it - spend time maintaining them, do manual testing on every PR - or delete them and accept lower quality. With coding agents, this problem became much worse. Someone finally solved this Meticulous https://www.meticulous.ai/?utm source=managerdotdev.beehiiv.com&utm medium=newsletter&utm campaign=04-08 records real user sessions and automatically builds your test suite from them. On every PR, in under 5 minutes, you see exactly what broke. 30-40 seconds of review to know if you're good to ship the unique way they achieved it is surprisingly complex and genius, definitely worth a . https://www.meticulous.ai/how-it-works?utm source=managerdotdev.beehiiv.com&utm medium=newsletter&utm campaign=04-08 read There were always 2 types of engineering managers: managers - very hands-on, they take tasks in every sprint, know the codebase well, and can help the team fix hard bugs. Engineering 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 https://newsletter.manager.dev/newsletter/the-slow-death-of-the-hands-on-engineering , focusing on what I did as a director to break that cycle. The accompanying LinkedIn post https://www.linkedin.com/feed/update/urn:li:activity:7274475937142898688/ https://www.linkedin.com/feed/update/urn:li:activity:7274475937142898688/ 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 https://www.manager.dev/newsletter/the-engineering-manager-s-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 https://suzansfieldnotes.substack.com/p/five-kinds-of-org-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 https://www.manager.dev/newsletter/3-things-top-1-teams-do-differently , how to make sure you still understand the agents’ output https://www.manager.dev/newsletter/the-i-don-t-know-claude-wrote-this-pandemic 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 Envelope EMs vs Letter EMs https://theengineeringmanager.substack.com/p/less-envelopes-more-letters . 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. The Best Prioritization Is No Prioritization https://blog.staysaasy.com/p/the-best-prioritization-is-no-prioritization . A unique solution to one of our main problems as engineering leaders. The Antithesis Principle https://shreyasdoshi.substack.com/p/the-antithesis-principle . Another superb article by Shreyas Doshi.