Something shifted in the last year, and it took me a while to name it.
A growing number of people are running organizations while still doing real hands-on technical work. Not as a hobby, not on weekends, not as a vanity exercise to keep their commit graph green. They are building things their teams depend on — and they are doing it as a deliberate part of the job, not in the cracks between meetings. The work has a specific shape. It is rarely a production feature. It is the layer underneath: developer productivity tooling, internal services, agentic harnesses, MCP connectors, the infrastructure that unblocks everyone else.
For most of my career this combination didn’t really hold together. You could code or you could lead, and the moment you tried to do both seriously, one of them rotted. I’ve watched plenty of technical executives keep a foot in the codebase and slowly become the bottleneck everyone routed around politely. The pattern was familiar enough to be a warning.
What changed is not that leaders suddenly got more disciplined. It’s that the time cost of meaningful technical contribution collapsed. Agentic coding made a hybrid role viable that wasn’t viable before — and the more I look at it, the more I think this isn’t a new invention at all. It’s the recovery of a very old idea that modern specialization interrupted.
I’m writing this as someone living in the middle of it. I spend roughly 30% of my time coding. And when I say coding, I mean directing a team of agents — much closer to that than hands-on work, which is probably the whole point. That’s not a full-time IC’s week, and it isn’t meant to be. It’s enough to stay close to the work that matters and to build the enabling infrastructure I think is worth my own hands on the keyboard.
TL;DR
A distinct role is emerging: leaders who run organizations and still do deep technical work — specifically enabling/institutional work (tooling, harnesses, internal services), not critical-path product features.
This satisfies Charity Majors’ actual advice. Her line was never “stop coding.” It was “stop writing code in the critical path.” Enabling work fits that exactly.
The integration of strategist and practitioner has deep cross-cultural precedent — Japan’s bunbu-ryōdō, Rome’s Marcus Aurelius, China’s wen-wu, the Renaissance polymath, Mattis’s “warrior monk.” The modern role is a recovery, not a novelty.
Agentic coding is what makes it newly viable: focused sessions now deliver output that once required sustained, uninterrupted immersion. The Anthropic 2026 data shows ~27% of AI-assisted work is work that “wouldn’t have been done otherwise.”
Directing agents feels like delegation — the same skill leaders already use with human reports. Which is why experienced leaders adapt to it more naturally than juniors do.
The pattern, named
The difficulty with the coding executive was never philosophical. It was attentional.
Charity Majors mapped this years ago in The Engineer/Manager Pendulum, and the piece holds up because she was precise about the mechanism. Management is interruptive by design — your job is to be available, to unblock, to absorb the chaos so your team doesn’t have to. Serious engineering is the opposite. It requires blocking interruptions for long enough to hold a complex system in your head. Two incompatible attention modes. Try to run both at once and you do neither well.
But here is the part people skip when they quote her. Majors never said managers should stop coding. Her actual advice was sharper: don’t write code in the critical path. Don’t be the person others are waiting on. Stay technical, stay sharp, just don’t make yourself a dependency that blocks shipping. “The best frontline eng managers in the world,” she wrote, “are the ones that are never more than 2-3 years removed from hands-on work.”
That distinction carries the whole argument. Because there is a category of technical work that is consequential without being critical-path, and it turns out to be exactly the work senior people are best positioned to do.
Call it enabling work. Internal tooling. Developer productivity infrastructure. Agentic harnesses. MCP services that other teams plug into. Architectural prototypes that prove a direction before anyone commits to it. None of this is what blocks a release on Thursday. All of it multiplies whoever comes after. It tolerates interruption — you can pick it up Tuesday afternoon and put it down when a real fire starts — precisely because nobody is standing at your desk waiting for it.
This is also where the industry is putting its money. Gartner named platform engineering a top strategic trend for two years running and projects that 80% of large engineering organizations will run dedicated platform teams by 2026. The structural reason a leader can work here without becoming the bottleneck is built into the definition of the domain: its output unblocks others rather than blocking them.
Will Larson’s Staff Engineer archetypes circle the same territory without quite landing on it. His “Architect” sits in a permanent argument — some organizations demand the Architect stay deep in the code, others forbid it. The leader/practitioner resolves that argument by relocating it: deep in the enabling and infrastructure work, absent from production product code. Not the pendulum, not the staff IC. A real hybrid, and a newly coherent one.
This is not new
Here is where I want to slow down, because the most interesting thing about this role is how old it is.
The idea that a leader should be both a strategist and a practitioner — not separate modes to alternate between but a single integrated way of operating — shows up independently across at least five civilizations. That kind of convergence usually means a culture has found a durable answer to a real problem.
Japan gave it a name: bunbu-ryōdō (文武両道), the way of both the literary and the martial. Bun is letters, cultivation, strategy. Bu is the martial, the active, the practitioner’s hand. Ryōdō means both ways, together — not balanced, not traded off, but held at once. By the mid-fourteenth century the dual-talented warrior was already established as the model leader, and during the Edo period the Tokugawa shogunate made it official policy for the samurai class. The phrase that survives captures the stakes: culture without power is ineffective, and power without culture is barbarous.
The archetype is Miyamoto Musashi. Undefeated in more than sixty duels, often fighting with a wooden sword against live steel. He founded a two-sword school, and in the last months of his life he wrote The Book of Five Rings in a cave. He was also a recognized master of ink painting and calligraphy — his Shrike on a Withered Branch survives as a designated Important Cultural Property of Japan. The same hands that won sixty duels produced fine art a nation still protects. He didn’t oscillate between the sword and the brush. He held both, and each sharpened the other. “When I apply the principle of strategy to the ways of different arts and crafts,” he wrote, “I no longer have need for a teacher in any domain.” Mastery in one discipline illuminating all the others.
Rome had Marcus Aurelius, the philosopher-king made historical rather than theoretical. He ran the empire and commanded its armies on the Danube, and he wrote the Meditations in the war camps — fragmentary notes to himself, composed in the middle of campaigning and administration. That book was never published philosophy. It was a working journal, the most powerful man in the ancient world writing to stay grounded while doing the job.
China institutionalized the same ideal as wen and wu — civil cultivation and martial capability — and ran it for roughly thirteen centuries through the scholar-official class. Zeng Guofan is the canonical case: he rose through the imperial examinations to high Confucian office, then built and commanded an army of more than a hundred thousand, reportedly keeping a diary on Neo-Confucian ethics even as he directed the campaigns. The integration wasn’t left to personal taste. It was built into the examination and career structure.
And the archetype still lands today. James Mattis earned the nickname “Warrior Monk” — battlefield commander and devoted reader, a 7,000-book library, the Meditations carried into combat. The chain from Aurelius to Mattis is literal: the same book, eighteen centuries apart. That we still reach for “warrior monk” as a compliment for a leader tells you the integration never stopped resonating.
Across all of it, the answer is the same. The contemplative and the active were not specializations to assign to different people. They were a single discipline, each half informing the other. Modernity — with its org charts, its clean role boundaries, its professional specialization — interrupted that. The leader/practitioner is not a tech-industry novelty. It’s an old integration becoming feasible again.
Why now
So what actually changed? Not the wisdom. The economics.
The thing that made the coding executive a bad idea was the attention math. Serious technical work demanded long, unbroken stretches of focus — the exact resource a leadership schedule cannot reliably provide. You cannot design a system in the fifteen minutes between a board prep and a one-on-one. The pendulum was a real constraint, not a failure of will.
Agentic coding changes that math directly. The unit of work moved up a level. Instead of holding every implementation detail in working memory across a four-hour session, you specify intent, direct an agent, review what comes back, correct course, and direct again. A focused 30-minute session now produces what used to require an afternoon of immersion — not because the thinking got easier, but because the implementation cost collapsed.
The Anthropic 2026 Agentic Coding Trends Report puts numbers on the shift. Average session length has climbed to 23 minutes in the agentic era, up from about 4 in the autocomplete era — the work got denser, not just faster. 78% of Claude Code sessions now involve multi-file edits, up from 34% a year earlier. Teams running multi-agent workflows report 2–4x faster delivery from task creation to deployment. And the figure that matters most for this argument: roughly 27% of AI-assisted work consists of tasks that “wouldn’t have been done otherwise” — the scaling projects, the nice-to-have tools, the exploratory infrastructure that was never quite worth the manual hours.
That 27% is the enabling work. It is the category that lives or dies on time cost, and it’s the category a leader/practitioner is best placed to take on.
The arithmetic is what makes 30% credible. I documented a 6–10x multiplier on focused technical sessions in The Irreducibles earlier this year — a project I estimated at 150–200 billable hours compressed into roughly 50–70 hours of wall-clock time, most of which wasn’t coding at all. If directed work runs several times faster than hand-coding, then a day and a half a week can produce what once consumed a full-time engineer’s week. That’s not a marginal gain. It’s a change in what’s structurally possible.
There’s another dimension that doesn’t show up in the productivity numbers: the work itself is unstable. Agentic coding patterns are still shaking out. There aren’t many experienced practitioners, the field is moving fast, and we don’t yet have good consensus on which patterns are load-bearing and which are fashion. A manager who’s only reading about it can’t make that distinction on behalf of a team. You have to be in it to know.
There’s a counterintuitive wrinkle worth naming: the people best positioned to exploit this are the senior ones. A University of Chicago working paper from late 2025 found experienced developers were 5–6% more likely to succeed with AI agents for every standard deviation of work experience, largely because they worked plan-first — laying out objectives, alternatives, and steps before invoking the tool. That’s the opposite of the assumption that AI flattens the seniority curve. Expertise improves your ability to delegate to a model for the same reason it improves your ability to delegate to a person. AI doesn’t change what senior engineering is. It reveals what it always was.
Directing agents is delegation
This is the part that interested me the most, and it’s the bridge between the leadership job and the technical one.
A year or so ago, working with Claude Code felt like coding. Now it feels like delegating. I wrote about that shift when it first became undeniable — the move from being a programmer who uses AI to being something closer to a technical project manager who directs it. Anthropic’s report uses the same vocabulary, describing engineers moving “from writing code to orchestrating the systems that write it.”
What I didn’t fully appreciate at the time is how directly that maps onto the muscle leaders already have. Delegating to an agent feels, in practice, just like delegating to a human engineer. You frame the problem, set the constraints, hand it off, and come back to assess the result. Give a directive, walk away, return to completed work. That loop is the daily reality of management. Leaders developed it because they had to, and it transfers to agents almost without friction.
So the leader/practitioner doesn’t have to become a coder again in the old sense. The skill in demand is judgment plus delegation, and that’s the skill leadership has been building all along. The hands-on knowledge tells you what to ask for and whether the answer is any good. The delegation instinct does the rest.
This is why the enabling work and the agentic tools fit together so cleanly. Enabling work tends to be well-defined, non-user-facing, and long-horizon — exactly the profile agents handle well and exactly the profile that tolerates a leader’s interrupted schedule. The hands-on contribution mostly takes the form of specifying constraints and patterns, which is what I’ve called pattern mastery: when you write the pattern down, you’ve written the spec, and the spec multiplies everyone else’s output.
What it actually looks like
Let me ground this without turning it into a war story.
The concrete examples from my own work are the kind of thing I mean. I built an agentic harness — the orchestration layer I argued is the real determinant of AI coding outcomes, where the same model can swing more than a quality point depending on the scaffolding around it. I built MCP services, the org-specific connectors that replaced a handful of standalone tools in a few hours of directed work each. None of that was a production feature. All of it was infrastructure other people now depend on.
Here’s a detail that may make the point. I now have an “AI architect” on my leadership team helping maintain the very infrastructure I originally built — not just the harness, but our inference relationships, our training program, office hours, the real human work I no longer have the time, or the right, to be doing myself. And I expect to hand off more over time. The enabling work I do today partly becomes the system that does tomorrow’s enabling work. That handoff is the role in miniature: you build the thing that multiplies the team, then you put someone in place to build the next version.
The proportion matters. Around 30% hands-on keeps judgment fresh without putting me in the critical path. Even full-time senior ICs aren’t full-time coders — Bain’s Jue Wang, quoted in MIT Technology Review last December, put developer coding time at 20–40%, with the rest going to analysis, strategy, and the surrounding work. A leader at 30% isn’t doing something exotic. They’re spending their technical budget on the layer where it compounds.
The decision is not “how do I find time to code.” It’s “what enabling work is worth my own hands?” Those are different questions. The first leads to the bottleneck I watched so many executives become. The second leads somewhere useful.
The choice
I’ll resist overselling this, because it isn’t for everyone and it isn’t automatic.
This is a deliberate role, not a default. Staying technically current costs ongoing investment, and the work is often invisible — enabling infrastructure rarely shows up in a quarterly review the way a shipped feature does. The role is easy to misread, too. From the outside, a CTO who codes can look like a CTO who hasn’t let go. The defense against that reading is the discipline Majors named: stay out of the critical path. Build the multipliers, not the blockers.
The returns are real, though. Fresh judgment — the kind that lets you evaluate not just what and why but how. Trust from engineers who see you in the work rather than above it. And institutional infrastructure that makes the whole team faster, built by the person with both the technical depth and the positional authority to prioritize it.
There’s a closing note in the history worth keeping. Bunbu-ryōdō wasn’t only a personal aspiration. The Tokugawa shogunate institutionalized it — built career and class structures around the assumption that a leader should be both. China did the same with its examination system. We’re not there yet. For now, the leader/practitioner is an individual choice, made one person at a time, made viable by tools that finally collapsed the cost of staying hands-on.
But the precedent suggests where this could go. When a way of working proves durable, organizations eventually build structures around it. The era of the leader/practitioner is early. It is also, I’d argue, a return — to an integration we knew was valuable long before we had the means to make it practical again.
Bob Matsuoka is CTO of Duetto and writes about AI-powered engineering at HyperDev.
Related reading:
From Coding with AI to Managing AI — When agentic coding starts to feel like delegation
It’s The Harness, Stupid! — Why orchestration quality dominates AI coding outcomes
AI Power Ranking — Tool comparisons and benchmarks for AI practitioners
LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders