I'm a VP of Engineering. Why Am I Still Writing Code?

Every few months someone asks a version of the same question. You're a VP of Engineering, why are you still opening an editor? Shouldn't your time go to strategy, hiring, roadmaps, the things only you can do? It's a fair question, and for a long time I didn't have a crisp answer beyond "it feels important." I have a better answer now.

The question assumes the wrong tradeoff

The usual framing treats leadership time and hands on time as if they compete for the same hours, and every hour spent building is an hour stolen from the organization. That framing only holds if hands on time is unbounded and undirected. Done deliberately, in small doses, aimed at the right targets, it is not a tax on leadership. It is an input to it.

What staying close actually buys you

• Better judgment in architecture and design reviews. You can smell a bad tradeoff faster when you've made similar ones yourself recently, not just years ago.
• Credibility with the team. Engineers trust a leader who still has calluses over one who only has opinions.
• Faster, more honest gut checks on estimates and timelines, because you have a real feel for how long things actually take right now, with today's tools.
• Staying current with how the craft changes. Agentic AI and the tooling around it move fast enough that if you stop touching it, your mental model of what's possible goes stale within a year, not a decade.

The trap: becoming the principal engineer

Here is where it goes wrong. If the code you write ends up on a team's critical path, if you become the reviewer every PR has to pass through, if people wait for your technical sign off before they'll commit to a decision, you have stopped being a force multiplier and started being a bottleneck. Worse, you have taught the team not to trust their own judgment, because the real decision maker is you, and everyone quietly knows it.

That failure mode is easy to fall into precisely because it feels productive. You're shipping, you're reviewing, you're in the code. It still adds up to a worse organization, because ownership never actually transferred to the people who are supposed to have it.

Where the line actually is

• Never own a piece of code that a team's roadmap depends on. If it disappearing would hurt a deliverable, it is not yours to hold.
• Build in the margins. Personal projects, prototypes, weekend explorations of a new framework or a new agent pattern, things that inform how you guide the team without becoming something the team depends on.
• Time box it and protect the time. Hands on work that only happens after every leadership task is done never happens, because leadership work is never done.
• Treat what you build as a scouting report, not a deliverable. Bring findings back to the team instead of shipping your own prototype into production.

What this looks like for me

My own consumer apps, WaterNation AI and the others, are the sandbox. That is the "still writing code" part, and it is deliberate that it happens on my own things rather than at work. It keeps the muscle sharp without creating a bottleneck anywhere that matters. What I learn experimenting with agentic patterns on my own time is exactly what shapes how I think about structuring AI pods and workstreams for the team, which I've written about separately.

Staying technical as a VP of Engineering isn't nostalgia for a simpler job. It's a forcing function that keeps judgment calibrated to reality instead of theory. The real risk was never writing too much code. It's the opposite: losing the instinct for what's actually hard, one abstracted decision at a time, until every call you make is a guess dressed up as experience.