👋 Hey, it’s Stephane. I help engineers become great engineering managers - whether you want to become one or are already leading a team.
Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.
A manager I know has not written actual code in a few years.
Recently, over a weekend he built an internal service-health dashboard with the help of AI, which he demoed to his team on Monday.
It just so happened, that this was the third system in that organisation solving the same problem. Plus, nobody in the team had seen the code for it or was asked what was wrong with the tools they already had.
The team said it looked good, so they inherited it.
I don’t want to talk about “should managers code?”
This is not what this post is about. I’ve written about it before.
The issue here isn’t that a manager wrote some code, or created a new service.. it’s that a consequential decision about the team’s systems was made, and the team was not consulted.
This has been measured
There’s no peer-reviewed research on managers using AI to bypass their teams’ judgement. And I haven’t found a survey that measures this consultation step either.
But in IEEE Transactions on Software Engineering this year, Salomon and colleagues found that 51% of developers now ask AI for help they would previously have asked a teammate for.
6 out of 10 said that’s because there’s no fear of looking stupid when using AI. (I wrote about that research here: 51% of devs stopped asking their teammates.)
I think something similar now is happening with managers. And the cost of that is much higher than when it happens to engineers.
“AI exposes bad managers”
That’s the cliché everyone says. I don’t think it’s quite right though.
Building software used to have a pretty meaningful cost.
If you hadn’t coded in years, building something as simple as an internal tool might have meant:
learning some new frameworks
spending a few weekends on it
researching and talking to people about how to deploy it
At some point you’d probably have asked the team for help.
There’s an old economics idea that an effort cost acts as a sorting mechanism: some things simply aren’t worth doing once you have to pay the cost.
AI has massively reduced that cost.
So I’m not sure AI exposes bad managers.
I think it removes some of the constraints that used to stop managers from doing certain things in the first place.
You could always build something without talking to your team. It was just expensive enough that, somewhere along the way, you probably had to involve them.
Now you can do it over a weekend.
It’s easier to just do it yourself
The temptation is to just do it yourself.
Talking to five people about a problem takes time. You need to explain it, hear different opinions, probably have a few meetings, then agree what to do.
Pointing an agent to a few repos, asking it to do so research and to build something can take an afternoon.
And, to be fair, it feels really good.
It can bring back that dopamine high of seeing something from nothing come to life again. You can have an idea in the morning and in the evening have something that looks like it works.
I think the problem is that there’s a pretty big difference between showing your team an idea and showing them something you’ve built.
Your role is still being people’s manager.
Camille Fournier has a quote I keep top of mind:
“The more senior you become, the harder it is for people to feel comfortable disagreeing with you openly.”
Now imagine disagreeing when your manager hasn’t brought you an idea, but a working new system.
That’s a much harder thing to say no to.
Your team has to maintain it
There’s also what happens after you build the thing.
Bird and colleagues studied ownership and defects across Windows Vista and Windows 7 in Don’t touch my code!.
One of their conclusions was that changes made by people with limited experience in that part of the codebase deserved more attention.
Which I think is a pretty good description of the manager in my opening story (and for many managers generally to be honest).
The problem is not that the thing you built might have a bug to be resolved, it’s that in some time that dashboard might become important enough that people use it and other things depend on it BUT the manager who built it has moved onto other things.
Who’s responsible for maintaining it? The team.
And now, they own something they never really chose to build (or where involved in how to build it).
The question isn’t whether managers should be allowed to build things. Of course they should.
But if you’re going to build something your team will eventually own, I think there are a few things you need to ask yourself first.
For me, there are six.
The six questions
👇👇👇 (access with a paid subscription)