Engineering Management in the Age of Agents
Why I'm very optimistic about Engineering Managers
Turn your scattered knowledge into instant answers with Unblocked.
The history of your system, why it was built a certain way, how it evolved, and the trade-offs made, are often scattered across GitHub, Slack, Confluence, Jira, and other tools. Unblocked finds the missing context behind your code, so you get instant answers without wasting hours digging.
Thanks Unblocked for sponsoring today’s article!
I’m super optimistic about Engineering Managers.
Let’s assume coding agents will truly reach the level of a mid-level engineer in a couple of years. Not just for new and basic apps, but truly - understanding multiple repos, not making a mess, creating maintainable code, and so on.
Even if that’ll happen - I’m in the camp that believes that there will still be someone technical to manage those agents, create guidelines, and deal with incidents when they happen (and they will).
The reality is that writing code has never been the toughest part of our jobs:
The outcome of the software engineering org is not just ‘working code’. It’s solving a problem for the customers.
And that is something we were never taught in our college degrees:
A doctor once told me the biggest thing they don’t teach in medical school is the difference between medicine and being a doctor:
Medicine is a biological science, while being a doctor is often a social skill of managing expectations, understanding the insurance system, communicating effectively, and so on
(quote from “Same as Ever: A Guide to What Never Changes”)
It’s the same in the software world.
Most software engineers are trained in “computer science,” but being a great engineer is often a skill of understanding the business side, managing the expectations of people, and yes, also defining the right technical solution.
During my time as an Engineering Manager, I got so much better in each of the three:
1. Understanding the business side
EMs are middlemen. We are responsible for bridging the gap between the technical and the business side.
We explain delays.
We communicate incidents.
We learn about what marketing and sales care about.
We participate in conversations with customers.
We help create the roadmaps.
To do that properly, we have no choice but to understand the business better. How do we make money? What do customers care about? How is our product marketed?
Those conversations happen way before any coding is involved.
2. Explaining what you need
I’ve mentored 4 interns straight out of college.
At first, you usually start with small and super-specific tasks. You give them a lot of context about the systems, and slowly, they learn their way around and progress to more complex and less defined work.
In every single case, I remember instances where I meant for them to do one thing, but the result was a bit different. If you had the opportunity to mentor a completely fresh engineer, you know what I mean.
Even when you manage mid-level and senior engineers, quite often you have to define the technical solutions, or at least help define them properly.
What are the risks we are willing to take?
What will we be measuring?
What scale are we preparing for?
How will we monitor it?
What edge cases should we support?
This experience is very valuable when you work with LLM coding tools.
3. Dealing with people
Engineers often hate to deal with ‘people problems’. An annoying PM, a UX designer who doesn’t listen, or even a teammate they can’t tolerate.
The engineers who initiate a 1:1 meeting with someone they worked with to share candid feedback and to try to figure things out are a minority (at least in my experience). Most of them just ignore it (worst case), or ask their manager to deal with it (slightly better case).
We don’t have this luxury. Every EM remembers some tough conversations they had, and hard feedback they just had to give. We’ve dealt with difficult stakeholders, pushy PMs, and stubborn engineers.
In the ‘agentic’ world, people skills will become even more important. AI agents won’t figure out every company problem for you - companies will always consist of people working together. And nailing that part, meaning being someone who can manage difficult relationships, and that people will enjoy working with, is a huge advantage.
Final words
I know it’s not an easy time to be an EM, as I shared in ‘Team got cut. Scope didn’t.’
Still, I believe it’s also a very exciting time for us. The unique combinations of skills you have might be exactly what companies will be looking for pretty soon.
My only advice for you - make sure you have time to build things. If you take all the skills you learned as an EM, and combine them with up-to-date coding skills, you will be in hot demand.
Discover weekly
Failure modes for engineering team leads and how to avoid them by Lior Neu-ner. 5 super common failures of engineering managers.
How Social Media Shortens Your Life by Gurwinder. A MUST-READ. A bit longer, but really worth your time.
How to be an empathetic manager (without becoming a therapist) by Wes Kao. Empathetic leaders often do a lot of invisible emotional labor - how can you deal with it better.
The guide to getting a job with cold email by Ben Lang. A very useful one to save when you’ll be looking for a job.
This is excellent I have been senior EM, VP and even CTO. Most of the times quite hands off coding. Sometimes dive into POC or solution design. But recently I have been orchestrating loads of code again thanks to LLMs.
Most people agree. What we don't agree on is, how much fewer engineering managers companies will need.