Why I won’t go back to coding as a manager - even now that AI makes it easy
The whole industry is sending managers back to coding. I think it's a mistake.
Hey Titans 💪🏻
Today I’m making one argument: sending engineering managers back to hands-on coding has become the industry default, and it’s a mistake.
Now that there’s AI, and the productivity gains it brings - there’s no more reasons for leaders to not code. My take is the complete opposite - it’s a failure of vision for how a leader should actually embrace AI.
Previously, I have posted about:
Decreasing daily anxiety by creating an agent that highlights open matters in The end-of-day check that removes manager anxiety;
Why the best time to be an engineering leader is NOW in Welcome to the golden age of leadership;
Overcoming forgetfulness of your own leadership style in Most managers can’t describe how they lead. Your agent should.
By the end of this one you’ll be able to see why the whole industry keeps pushing you towards coding, and understand why giving in to it burns leaders out and strands the very transformation you’re supposed to be leading.
Let’s get into it.
“but they also need to be a very good coordinator”
At the beginning of 2022, when I was transitioning out of a senior software engineering role, I had my first real coaching conversation with my boss on what it means to be a good leader.
He asked me what I thought made a leader. I answered fast, and I was sure of it: “a leader has to be the best, or one of the best, software engineers on the team… the most technically sound person in the room for sure.”
His reply: “but they also need to be a very good coordinator.”
The point that my boss was making - I’m not tasked with shipping code, but I am responsible to make sure that others do.
Prescribing managers coding tasks goes against that philosophy. These are the consequences that I see of dropping coordination tasks:
Organizational black holes eating up time and resources - unless you work with a PM or have created a workflow where every team member can be informed on the goals;
Dipping team performance - since you miss out on the overview of struggles, you don’t know when to give feedback or whom to coach;
Increased potential for conflicts - returning to coding usually means partially retaking your directs’ scope ; in a healthy team, there’s a soft technical leadership structure in place that when violated, can trigger defensiveness or resentment.
It took me a while to get it that it’s my job to make sure others on my team can do their job the best they can.
Coding is the default because it’s the only place the tools are mature
Here’s what’s strange: in the middle of the biggest shift in how software gets built, a lot of managers are going back to writing code.
Why would you climb into leadership and then climb back down?
I’m fairly confident it comes down to a lack of vision of how a modern engineer or leader should actually embrace AI.
So people reach for the nearest mature tool - an AI-based coding tool.
Claude Code is the obvious example, a genuinely mature product that makes shipping software super easy.
There is no equivalent for leadership, though. No mature product that helps you run a team, coordinate stakeholders, or coach direct reports.
This leads to coding becoming the lowest-hanging fruit - a manager opening the IDE, and integrating Claude Code makes it easy to report progress in the AI adoption process.
My take: adopting a tool and calling it “vision” is extremely generous.
You can’t cram coding back on top of the job
Let’s be honest about what a manager already carries. On any given week you’re responsible for:
Communication;
Performance management;
Crafting and maintaining the roadmap;
Keeping every stakeholder aligned;
Collaborating with project managers, product owners.
The pre-AI understanding of the manager’s job is that one has to be sound in all of the areas above.
Now add hands-on coding back on top. Where does it go?
It’s not I don’t believe we can’t code - most of us, including me, came from engineering and can code just fine. However, one must not forget that it’s one more thing to own. One more surface to be responsible for, one more context switch that you have to make.
Pile it on top of everything above and you get a straight road to burnout.
The agent writes the code - you still own the quality
Even when a manager does code with AI, it isn’t jump-in-and-ship. You don’t “fire and forget” a Claude Code agent and walk away.
You still have to show the expected level of judgement. You’re the ambassador for code quality on your team. Delegating the typing to an agent does not relieve you of the taste for what good code looks like - you still have to read it, analyze it thoroughly, and stand behind it when it ships.
Let’s be real - in its current state, AI is great at generating content and leaving you its assessment and quality control. More code, faster, means more to review, more to reason about, more to sign off on.
So the supposed time-saver quietly becomes a cognitive load multiplier. More content generated for you to review and submit.
That’s the second path to burnout.
You can’t be world-class at both
I was promoted for one thing: my capability to lead the team. So far my boss has not asked me to fold software engineering back into my responsibilities. If he did, I’m confident it would be a step back in my career.
You cannot maintain and lead an excellent, high-performing, world-class team and be a high-performing, world-class individual contributor at the same time. Both jobs demand your best, and you only have one best to give.
I’m not okay being mediocre at any of it. Not the leadership, not the coordination, not the coding craft. Every toolkit I show up with daily, I want sharp.
Force coding back into the role and you guarantee mediocrity somewhere. Something slips - either the team you’re supposed to be lifting, or the code you’re suddenly trying to own again.
That’s the personal cost, sitting right next to the burnout: a quiet career regression dressed up as versatility.
Managers are the ones who carry the transformation
Across the industry, managers are the true drivers of cultural transformation - not the CEO, not the head of engineering, not the individual contributor. The mandate lands on the managers, and they’re the ones who have to communicate it meaningfully and turn it into a plan their team will actually follow.
Any transformation only works if the people at the front lines buy in - the ones doing the daily work, shipping products, writing the code. If they don’t follow, nothing moves.
The engineering manager is the enabler of that buy-in. Your job is to devise a plan the team accepts: high on empathy, logical, easy to understand, with the upside clearly visible.
Unless the person doing the daily work can see that upside for themselves, they won’t buy in and the transformation will fail.
Now put the two things together. A manager who retreats into coding walks away from exactly this role. The one person who’s supposed to be leading the AI transformation is instead heads-down in an IDE.
The coding fallback costs you your own career progression and it strands the whole team’s transformation, because the key enabler is a bottleneck.
The learning: coding was never the leader’s job, and AI didn’t change that. The ecosystem is mature for coders and empty for leaders, so the industry keeps mistaking “easy to adopt” for “right to adopt.”
Don’t take the low-hanging fruit just because it’s the only fruit someone bothered to grow.
My boss handed me the better definition years ago, and it still holds. A leader makes sure others can build. Your work in this agentic era is to lead the transformation your team is waiting on, not to reclaim the IDE.
So here’s my question for you: when you sit down to “try AI this week,” are you reaching for a coding task because it’s the highest-value thing you could do, or because it’s the only thing the tools made easy?
— Leszek