There’s a reckoning coming for a specific type of software engineering manager. Not the good ones. The ones who turned themselves into human Jira routers. The ones whose primary skill is translating documents into tickets and running standups. Those jobs? Gone. Faster than you think.
I’ve been in this industry long enough to have seen every hype cycle. Java was going to change everything. The web. SOA. Agile. Cloud. Mobile. I coded my first program on a TRS-80 with 4K of RAM. I know what hype looks like.
This is not hype. The train is already passing the Wagon. Cars are next.
The train didn't wait for the horse to be ready.
The Glorified Babysitter Problem
A friend shared this piece from Practical Engineering Management recently. There’s one section in it that stopped me cold:
If you run a feature factory, AI will easily replace you. It’s the perfect worker for a factory line.
Good managers ensure the team knows why they are building, not just what. They shift their teams from software engineering to product engineering.
And this:
We don’t need fewer engineering managers. We need fewer glorified babysitters.
Yeah. That.
I’ve worked for and with a lot of engineering leaders over a long career. At the big companies especially, there’s a whole category of manager whose job is essentially: receive requirements from above, decompose into tickets, attend standup, remove blockers (meaning: send Slack messages), report status upward. They’re traffic cops. Human middleware.
AI is very good at being middleware. And it doesn’t need a salary, benefits, or a 1:1 with you on Tuesday.
Technical Credibility Is Not Optional Anymore
There’s a second article worth reading — Why Senior Developers Fail to Communicate Their Expertise. It makes a solid argument about avoiding needless complexity and not building what you can reuse. Good advice, generally.
But it feels like it was written for a world that no longer exists. A world where code was the precious, scarce resource. Where building anything was expensive and slow, so you defaulted to existing frameworks and libraries and swallowed their entire dependency chain just to get the three features you actually wanted.
That world is gone.
The Emacsification of Software
There’s a brilliant piece over at sockpuppet.org about “emacsification” — the idea that with AI agentic tools, you can now just… build exactly the thing you need. Not a framework that sort-of does what you need with seventeen configuration options and a plugin ecosystem. The actual thing. Specified the way you want it.
This changes the build vs. buy calculus completely.
Think about RAFT consensus. Before, if you needed leader election and distributed coordination in your system, you had a choice: implement it yourself (months of work, subtle bugs, a team of people who understand it deeply), or adopt etcd or Consul and take on their entire worldview along with it. Most teams took the dependency, then spent years living with the mismatch between what they needed and what the tool provided.
Now? You can spec exactly the RAFT behavior you need, have an AI agent build it, understand it completely because you have the world’s most patient explainer sitting next to you, and ship it.
Same with circuit breakers — you don’t need to adopt a full service mesh to get Hystrix-style behavior. Same with bloom filters, gossip protocols, leader election schemes, custom cache eviction policies. You name it: if it’s a well-understood computer science concept that used to require importing a whole framework, you can now just build the slice you actually need.
The most precious asset is no longer the code. It’s the judgment about what to build - and how to build it.
Lego Blocks, But You Design the Bricks
Here’s the mental model I keep coming back to: engineering has always been about assembling components. But the components were expensive to make, so you used off-the-shelf ones even when they didn’t fit perfectly.
Now you can build custom bricks. The AI builds them from your specs.
That sounds amazing, and it is. But it comes with a catch. When you used a well-known library, you had something priceless: the collective understanding of a community. Stack Overflow answers. Blog posts. Conference talks. Your new hire already knew it.
If you build a custom thing — even a well-specified, well-understood custom thing — it’s yours. You own it completely. The community doesn’t know it.
On the other hand, you have the most powerful code-explanation and modification tooling in history sitting right there. So it’s a different tradeoff, not necessarily a worse one. But you better understand what you built. Actually understand it.
Which brings us back to leadership.
Judgment Is the Whole Job
Engineering leadership has always been about the application of good engineering judgment. Not about the number of tickets closed. Not about deployment frequency. Not about headcount. Judgment. Risk management. Value creation.
Only 10% to 30% of features pushed by tech companies actually yield positive commercial results. If your only measure of success relies on operational DORA metrics, you are likely just building the wrong things, very efficiently.
That quote from the first article is the whole game. Metrics that measure how fast you’re shipping are useless if you’re shipping the wrong things. And AI makes shipping even faster, which means the cost of shipping the wrong thing goes up, not down. You can make more mistakes, more quickly.
The leaders who understand this — who can hold the line on technical strategy, who can distinguish between “the AI can build this” and “we should build this” — those people are more valuable than ever.
The ones who are just… moving tickets? Their jobs are being automated as we speak.
This is a whole new continent of skills forming as we watch - like it was a new island forming from from an eruption of AI.
New land forming whether you're ready for it or not.
We are watching this transformation happen in real time. Telegraph operators didn’t fade away — the job category just ended. Video store clerks. Travel agents. Switchboard operators. Whole professions that existed for decades, then didn’t.
You can’t stop this any more than you can stop a volcanic eruption.
I’m not saying software engineers are going away. Actually quite the opposite! Job listings are *up for Software Engineers.
I’m saying something more specific and arguably scarier: the software managers who lost touch with their engineering skills are going away first. Because their job — the coordination, the decomposition, the status reporting — that’s the part that automates cleanest.
The engineers who can still build things, who understand systems deeply, who have genuine technical credibility? They’re going to be fine. Better than fine, actually, because the tools available to them are extraordinary.
But the manager who can’t read a diff, can’t reason about architecture, can’t tell good engineering from bad engineering? The one who needs a staff of engineers to translate the technical reality into something they can understand?
That job is going the way of the switchboard operator.
And yes, we have a chasm of the junior talent, and how we being them along. I’ve not solved that yet. I have some ideas.
Conclusion
Here’s the thing: this is actually good news, if you’re the right kind of engineering leader.
The best managers I’ve worked with or for have always been technical. They earned their credibility in the trenches. They can see through the bullshit when a vendor promises magic. They know when the team is taking shortcuts that will hurt later. They understand the difference between technical debt and deliberate design tradeoffs. And yes, they have the leadership skills too.
Those people are finally free to do the work they probably have been doing all along — the actual hard stuff. Product discovery. Technical strategy. Scaling the problem-solving capacity of the humans around them.
The glorified babysitters? The Jira ticket routers? Their time is up. If you are one of them, I recommend you get back to coding something nights and weekends and get the rust off quickly.
The volcano doesn’t care if you’re ready. New land is forming. Don’t get burned.
What do you think? Drop me a note on LinkedIn. Seriously. I want to hear from people living through this — especially if you’re a manager who’s figured out how to adapt.