I've spent the last few months building features alongside my engineering team. Not because I had to, but because I wanted to understand what AI-assisted engineering actually feels like at the coalface. It made me a sharper leader. It also nearly made me a bottleneck.

Getting back close to the tools was a deliberate choice. As an engineering executive, it would be easy to operate entirely in the strategic layer: org design, roadmap alignment, hiring plans. But AI has changed the mechanics of software delivery so fundamentally that I didn't trust my ability to lead through it without experiencing it firsthand. So I started building. I picked up tickets, paired with engineers, shipped code, and used the same AI tooling my teams were adopting.

The reconnection was immediate and valuable. I stopped relying on secondhand accounts of what was working and what wasn't. I could feel where the tooling accelerated things and where it introduced new friction. My architectural opinions got sharper because they were grounded in recent, direct experience rather than outdated intuition. When I gave guidance, my team could tell the difference.

You're not the only one

This isn't a solo experiment. In my advisory work with CTOs and CPTOs, and in conversations with engineering executives at events and across my network, the same pattern keeps surfacing. Leaders are getting pulled closer to the tools, partly by necessity as organisations flatten and partly by instinct as AI reshapes what engineering work actually looks like. The role of the senior engineering leader is changing in real time, and nobody has a clean playbook for it yet.

But there's a version of this that goes wrong, and it's worth naming explicitly.

The hero trap

When an executive starts building, the gravity of the organisation shifts. You pick up a complex feature, you move fast, you ship something impressive. Your team watches, maybe even applauds. But nothing changes about how they work. Worse, they start deferring to you on technical decisions because the boss is clearly the most productive person in the room. Your pull requests end up on the critical path. You've accidentally traded strategic leverage for individual contributor output, and your team is less autonomous than before you started.

The hero leader feels productive. They're shipping, they're visible, they're proving they've still got it. But the organisation around them quietly atrophies. If your team needs you to build the thing, the structure is broken. If they need you to unblock the thing, you're doing your job.

The catalyst alternative

The version that works is the same hands-on energy with a different intent. You build to demonstrate what's possible, not to carry the load. You adopt a new tool or pattern first, prove it works in a real context, then measure success by whether the team picked it up and ran with it. You're the first follower of new approaches, not the permanent practitioner.

When I built features with my team, the moments that actually mattered weren't the PRs I merged. They were the conversations that happened afterwards: engineers seeing a pattern I'd used and applying it to their own work, or pushing back on something I'd done and improving it. The value wasn't in my output. It was in the capability transfer.

This is the difference between a catalyst and a hero. A catalyst accelerates a reaction without being consumed by it. A hero carries the weight themselves.

A simple test

I've started asking myself one question at the end of each week: did my technical work leave the team more capable and more autonomous than they were on Monday? If the answer is yes, I'm catalysing. If I'm the only person who could have done the work, I'm hero-moding, and I need to course correct.

The honest truth is this balance is still evolving. I don't think the role of the engineering executive has settled into a stable new shape yet, and anyone who tells you they've figured it out completely is probably selling something. But the leaders I see getting it right are the ones comfortable holding both identities, strategist and practitioner, without letting either one win permanently. Head in the clouds for vision and direction. Feet on the ground for credibility and context. And the discipline to know which one the moment requires.