Build With Your Hands

There’s a moment in every technical founder’s career where someone pulls them aside and says the thing. “You need to scale yourself. You can’t be in the code anymore. Your job now is strategy, hiring, and removing blockers.”

And it sounds so reasonable. So grown-up. Like the natural evolution from builder to leader — as if those are different species.

It’s also the worst advice in the industry.

I’ve been writing code for decades. Not because I’m addicted to syntax or can’t let go. Because building things is how I think. It’s how I stay dangerous. The moment a founder stops touching the product is the moment their judgment starts decaying — slowly at first, then all at once. You can’t make good decisions about something you’ve stopped understanding at the resolution where it actually works.

The leadership industry has convinced an entire generation of technical founders that “graduating” out of the code is a promotion. It’s not. It’s a lobotomy. You’re cutting off the part of yourself that made you valuable in the first place and replacing it with calendar management and slide decks.

Here’s what actually happens when a technical founder stops building: they start managing abstractions. Second-hand information. Filtered status updates. The product becomes a story other people tell them instead of something they feel in their hands. Their decision-making gets slower because they’ve lost the intuition that only comes from being in the guts of the thing. They become a king on a throne — suspended above the battlefield, dependent on messengers, making calls based on reports instead of reality.

Nobody wants to follow that person. And deep down? That person knows it.

People don’t want a king on a throne carried by peasants. They never have. They want to charge into battle alongside a warrior general — someone who’s in the work, building alongside the team, debugging the same gnarly production issue at 2am, getting their hands dirty with the same tools. When your team sees you in the code, they know something they can’t know any other way: this person understands what they’re asking of us. They’re not guessing. They’re not relying on a dashboard. They know.

That authority can’t be delegated. It can’t be performed. It can only be earned — with your hands.

I’ve run engineering organizations. I’ve scaled a delivery platform that processed over a million orders. And through all of it, I never stopped building. Not because I was being precious about my identity as an engineer. Because every time I stepped away from the code for too long, I could feel my judgment softening. The decisions got less crisp. The instinct for what was actually hard versus what just sounded hard — it faded. Getting back into the work was like putting on glasses I didn’t realize I’d taken off.

The conventional wisdom says this doesn’t scale. That’s the whole argument — you’re one person, your time is finite, you should be spending it on “higher-leverage” activities. But this math has always been wrong, and in the AI era it’s laughably wrong.

A technical founder with AI tools isn’t choosing between building and leading. They’re doing both — at a speed and scope that would have required a team of ten five years ago. I’m building Athena right now solo, shipping features in hours that used to take sprints, making architectural decisions in real time because I can see the code, feel the tradeoffs, and move. The founder who ships a feature before lunch and makes a strategic hire after it isn’t failing to delegate. They’re operating at a level the pure-manager founder can’t touch.

This is the part the “scale yourself” crowd hasn’t updated on. AI didn’t just change what engineers can do — it changed what leaders can do. The builder-founder was always the right model. Now it’s the unfair advantage.

And yet the playbook hasn’t changed. The industry still treats leadership like a promotion tree in a corporate RPG — you level up by moving further from the actual work. But the real world doesn’t work like that. The real world rewards founders who maintain the sharpest possible understanding of their product, their codebase, their customers. Who can drop into any part of the system and make it better. Who lead from the front because that’s where the information is.

I’m not saying don’t hire. I’m not saying don’t delegate. I’m saying never let go of the thing that makes you you. The code isn’t beneath you — it’s the source of your power. Your taste, your speed, your ability to call bullshit on something that looks right in a deck but would fall apart in production. All of it lives in your hands.

Decades in, I still write code every day. Not because I have to.

Because the moment I stop, I become the kind of leader I’d never want to follow.