Write less code, get more done

What happens when you measure value not by keystrokes, but with leverage?

For years, my identity was tied to my keyboard.

The more I shipped, the more valuable I felt. When people asked what I did, I’d say “I build things.” And by “build,” I meant something very specific: I write the code. I architect the systems. I ship the features. My hands on the keyboard, my logic in the codebase, my commits in the git history.

There’s a particular kind of satisfaction that comes from solving a hard problem in code. That moment when the tests pass. When the feature works. When you push to production and watch real users interact with something you built. It’s tangible. It’s measurable. It’s yours.

I optimized my entire career around that feeling.

But I’ve been lying to myself about what it actually means.

The uncomfortable math

Here’s what nobody tells you when you become a leader: every hour you spend deep in implementation is an hour you’re not spending on the thing that actually matters.

As a developer, the equation is simple. Your value equals your output. The code you write, the bugs you fix, the features you ship. More output, more value. It’s clean and satisfying.

As a leader, the equation inverts. Your value equals your team’s output. Not yours. Theirs.

And here’s where it gets uncomfortable: those two things are often in direct competition.

Last month, we had a bug that needed fixing. Nothing critical, but annoying. I knew exactly how to fix it. I could have had it done in an hour, maybe two. Instead, I spent 30 minutes explaining the problem to a junior developer, another hour pair-programming through the investigation, and then reviewed their PR the next day.

Total time: probably 3 hours of my involvement, spread across two days.

If I’d just done it myself? Two hours, done, move on.

So why didn’t I?

Because that junior developer now understands that part of the codebase. They learned a debugging technique they didn’t know before. Next time a similar issue comes up, they won’t need me at all. The hour I “lost” today bought dozens of hours in the future.

But here’s the thing: every instinct in my body screamed to just fix it myself. It would have felt so much more productive. So much more satisfying. So much more me.

The hero trap

There’s something deeply seductive about being the hero.

You know the pattern. A problem emerges. Something’s broken, or blocked, or just hard. You swoop in. You fix it. Everyone’s grateful. Your brain floods with dopamine. You feel essential, valuable, needed.

I’ve been that hero for years. The one who always knows how to fix things. The one people come to when they’re stuck. The one who can jump into any part of the codebase and figure it out.

It feels amazing. But it also creates a trap.

Because when you’re always the hero, you become a bottleneck. When you’re always the one who fixes things, your team never develops those muscles. When you’re always available to swoop in, people stop trying to figure things out themselves.

I’ve watched this pattern play out so many times. Someone on the team hits a problem. They struggle for a bit. They ask me. I solve it quickly because I’ve seen it before. They thank me and move on.

Everyone’s happy, right? The problem got solved. We shipped faster.

Except: that person learned nothing. Next time they hit a similar problem, guess who they’ll ask? And the time after that? I’ve accidentally trained my team to depend on me, and then I wonder why I’m overwhelmed and they’re not growing.

The uncomfortable truth I had to face: sometimes my “helping” was actually hurting.

My ownership was someone else’s missed opportunity to grow. My speed was the team’s bottleneck. My “just let me do it quickly” was a lesson someone else never learned.

I thought I was being efficient. I was being selfish. I was optimizing for my own satisfaction instead of the team’s capability.

The question that changed everything

A few months ago, I started asking myself a different question before jumping into any task:

“Who else could do this? And what would they learn from doing it?”

Not “who else should do this?” That’s easy to dismiss. Of course I should do it, I’m the fastest. But “who else could do this” forces a different kind of thinking.

The answer is almost always: someone else could do it. Maybe not as fast. Maybe not as elegantly. But they could do it, and they’d be better for having done it.

This reframe changed how I spend my time. Instead of asking “what’s the fastest way to solve this problem,” I started asking “what’s the best way for the team to solve this problem.”

Sometimes that still means I do it myself. Some things genuinely need my specific context or expertise. But way more often than I expected, the right answer is to step back.

The multiplier math

There’s a concept that keeps running through my head: multipliers versus diminishers.

Diminishers are brilliant individual contributors who happen to have leadership titles. They do the work themselves. They’re the smartest person in every room. They have all the answers. They move fast by doing everything themselves.

Multipliers are something different. They create space for others to grow. They ask questions that unlock insights. They move fast by enabling everyone around them.

The math is brutal but clear:

Hero math: 1 person × 100% efficiency = 1x output

Multiplier math: 5 people × 80% efficiency = 4x output

Even if you’re twice as good as everyone else (even if you’re the literal best in the world at what you do) the multiplier will always win. Because multiplication beats addition every single time.

This is obvious when you write it down. It’s incredibly hard to internalize when you’re in the moment, staring at a problem you know you could solve in an hour, watching someone else struggle through it over a day.

But every time I catch myself wanting to jump in, I try to remember: I’m not optimizing for today. I’m optimizing for next month, next quarter, next year. And the compounding effects of a capable, independent team absolutely dwarf whatever I could accomplish on my own.

The second revolution: AI changes the game

But here’s the thing: there’s another dimension to this that makes 2025 different from any year before.

We’re living through a moment where AI can genuinely build.

I don’t mean autocomplete. I don’t mean suggestions. I mean: describe what you want, review what comes back, iterate on the direction, ship the result.

Last month I needed a data migration script. Nothing fancy, but fiddly: lots of edge cases, careful handling of null values, proper error logging. Old me would have spent a morning writing it, testing it, handling the edge cases I discovered along the way.

Instead, I described the requirements to Claude. Reviewed the first draft. Pointed out a few edge cases. Got back a revised version with tests. Ran it. Done.

Total time from my hands: maybe 30 minutes. And honestly, the code was better than what I would have written. More thorough error handling. Better logging. Edge cases I hadn’t even thought of.

This isn’t a one-off. This is becoming my default mode. The ratio of “time spent typing code” to “features shipped” has completely inverted. I’m building more than ever while writing less code than I have in years.

From musician to conductor

I’ve started thinking about this shift as moving from musician to conductor.

As a musician, you play the instrument. You produce the sound. Your skill is in your fingers, your technique, your direct manipulation of the tools. There’s a ceiling to what you can produce, one person, one instrument, limited hours in the day.

As a conductor, you don’t play anything. You direct. You shape. You bring out the best in each section of the orchestra, balance the voices, keep everyone aligned toward the same interpretation. The music that emerges is vastly more complex than any single player could produce.

That’s what building software feels like now. I’m not the one typing the code. I’m the one directing what gets built, reviewing what comes back, iterating on the direction, making sure it all hangs together.

I still build. I still contribute meaningfully. The decisions I make—what to build, how it should work, what tradeoffs to accept—those matter enormously.

But I’m operating at a completely different altitude. Less typing, more thinking. Less doing, more directing. Less output, more outcome.

And the same principle applies to the human side of the team. My job isn’t to write the code. My job is to make sure the right code gets written, by the right people (human or AI), in the right way.

---

The compound effect

When you stop being the bottleneck (for your team and for yourself_ something magical happens. Things start to compound.

I can run multiple AI agents in parallel, each working on a different piece of a feature. I can spin up experiments that would have taken weeks and validate them in hours. I can test ideas that would have been “too expensive to try” and kill the bad ones fast.

Meanwhile, the team is growing into challenges they would never have faced if I kept swooping in. They’re developing judgment, building context, becoming the experts I used to be. Every week, there are more problems they can solve without me.

The result: more gets built, better than before, with less of my direct involvement.

This is what leverage actually feels like. Not working harder. Not being faster. Multiplying.

Why this is terrifying

I won’t pretend this transition is easy.

It’s scary to let go of the thing that defined you.

When your identity has been “the person who builds,” and suddenly you’re not the one typing the code, who are you? When your value was measured in commits and pull requests, and now you’re measured by team output, how do you know you’re still valuable? When you could always point to lines of code and say “I made that,” what do you point to now?

There are days when I feel like a fraud. Days when I wonder if I’m even a real engineer anymore. Days when I watch my commit count drop and feel a weird grief for a version of myself that’s fading away.

This isn’t just a behavior change. It’s an identity shift. And identity shifts are hard. They take time. They feel like loss before they feel like growth.

But I keep coming back to the question: what do I actually want to build? A monument to my own coding ability? Or something bigger than I could ever create alone?

The 2026 resolution

Write less code. Get more done.

This is my commitment for the year. Not because writing code is bad; I still love it, still find it deeply satisfying. But because I’ve finally internalized that my satisfaction isn’t the metric that matters.

Practically, this means catching myself before I jump into implementation. Asking who else could do this and what they’d learn. Defaulting to AI for tasks that don’t need my specific judgment. Reviewing and directing instead of writing. Measuring my success by what the team ships, not what I personally produce.

It means being okay with being less essential. Less heroic. Less visibly productive.

It means trusting that multiplication beats addition, even when addition feels so much better in the moment.

The counterintuitive truth

Here’s what I believe will happen:

By writing less code, I will build more than ever. Not despite writing less code. Because of writing less code.

The best version of 2026 me isn’t the one who wrote the most code. It’s the one who built the most… without writing any. The one who multiplied instead of added. The one who finally got out of his own way.

The invitation

If you’re a founder or leader who still writes most of the code... if your team can’t ship without you... if you’re the hero everyone relies on...

Maybe this is your resolution too.

The hardest part isn’t learning to delegate, or learning to use AI, or learning any new skill at all. The hardest part is unlearning the identity that got you here. Letting go of the satisfaction of being the one who fixes things. Trusting that the new way is better, even when it feels like less.

Here’s to getting out of our own way.

---

Building the future of work at neople.io. Where the goal isn’t to write more code—it’s to build more, together.