The 10x Leader: What Great Engineering Leadership Really Means

For most of my career, being good at my job meant my own output. I was the one who could talk to a customer in the morning and ship a fix that afternoon. I built the database, found the bug, shipped the feature. The better I got, the more the company leaned on me, and for a long time that felt like the whole point.

Then I started running a company, and the thing that made me good became the thing slowing everyone else down.

Every decision waited on me. The team learned to wait, because waiting for my answer was safer than guessing at it. I was still the strongest engineer in the room, and the room was moving slower because of it.

That’s the moment most engineering leaders hit and misread. They assume they need to be more available, or work more hours, or hire people who think exactly like them. The real fix is the opposite of the instinct that got them promoted.

The most productive thing you can do as an engineering leader is make everyone around you more productive.

It’s an idea I keep coming back to in my book, Product Driven, and it’s the whole job of engineering leadership. The best engineering leaders aren’t the ones writing the most code or making the most decisions. They’re the ones who give the team enough clarity, ownership, and context that the work no longer runs through them. They make twenty people capable of shipping great features without asking permission.

The shift from hero to leader

This is harder than it sounds, because the work is unlearning the habit that made you valuable in the first place.

I’ll be honest about my own version of it. When I was younger, I used to get frustrated with the people around me. They didn’t move as fast as I did. They didn’t see the problem the way I saw it. They didn’t seem to care as much. I quietly assumed they were the problem, and that if everyone just worked the way I worked, things would be fine.

They weren’t the problem. I was. The people who frustrated me thought differently than I did and were better than me at things I was bad at, and I was too busy being the smartest engineer in the room to notice. The turning point wasn’t lowering my standards. It was resetting what I measured. I stopped grading myself on how much I could personally carry and started grading myself on what the team could do when I wasn’t in the room.

That’s the line I’d draw between a senior engineer and an actual leader. A senior engineer makes themselves more effective. A leader makes the people around them more effective, which means letting go of being the hero. As I put it in the book, I’m not the hero anymore. I’m the leader. Most of the technical brilliance that made you promotable becomes beside the point the day your job is other people.

None of this means the technical track is a lesser path. A staff or principal engineer can multiply a whole team through architecture, code review, and mentoring without ever managing a person, and that’s leadership too. And early on, when it’s just you and a cofounder, you probably do need to be the strongest engineer in the room. The instinct is right at the start and wrong at scale. The day your own output becomes the ceiling on everyone else’s is the day the job changed, whether or not your title did. That moment, when your own output stops being the point, is one of the defining CTO challenges in the AI era.

Why so many great engineers make poor leaders

The trap is that the skills don’t transfer, and nobody tells you that.

The instinct that makes a great engineer is to take the hardest problem and solve it yourself. The instinct a great leader needs is to take the hardest problem and build someone else who can solve it. Those pull in opposite directions, and the better you were as an individual contributor, the harder the second one is, because doing it yourself is faster today and slower forever.

In the book I make the case that ownership is built through trust and safety, not through accountability pressure. You can’t demand that your team think like owners while you reserve every real decision for yourself. That’s fake delegation, where you hand off the task but keep the judgment, and it teaches people to stop trying. Real delegation means handing over the outcome along with the context and the authority to chase it, and then living with the fact that someone will get there 80% the way you would have and 20% in a way you wouldn’t have thought of. That 20% is usually where the good stuff is.

This is also where developer productivity stops being a coding problem and becomes a leadership one. A team of capable engineers producing mediocre outcomes almost never has a talent problem. It has a leadership problem: no clear vision, no real ownership, and a manager who is still trying to be the best engineer instead of building the best engineers.

What multiplying people actually looks like

None of this is abstract. Multiplying your team is the real force-multiplier part of engineering leadership, and it comes down to a few concrete things, most of them about getting out of your own way.

The first is knowing which job is actually yours. In the book I break engineering leadership into four jobs: strategic, product, technical, and operational. The mistake almost every founder-engineer makes is trying to cover all four, usually badly. If you’re personally carrying more than two of them, you’ve got a hiring gap you keep refusing to fill. I lived this at VinSolutions, where I was the CTO doing the vision and trying to force myself into the VP-of-Engineering job of building the systems and the team. The vision was fine. Everything kept breaking around me, because the role I was missing was the one I kept refusing to hire.

The fix came from my COO at Stackify, Craig. He asked to talk, and my first thought was that he was quitting. Instead he told me, gently, that I was the bottleneck, and handed me a copy of Rocket Fuel by Gino Wickman. The book splits leaders into visionaries and integrators. I was the visionary with no integrator, trying to be both. The lesson I took from it is one I give other founders now: find your Craig, the person who builds what you can only imagine, and then go be that person for someone else.

The second thing is structure. Product thinking scales through what you actually build into the week. The leaders I’ve seen do this well don’t give speeches about ownership. They put engineers in front of customers. They run a demo day where engineers show working software and explain the problem they solved, until the whole company can see whose work moved what. They make trade-offs visible so the team learns to choose. None of that requires the leader to be the smartest person in the room. It requires them to build a room where smart people can see what matters.

AI raised the stakes on this, it didn’t remove them

It’s worth saying where AI lands here, because it’s tempting to think it changes the math. It doesn’t, it sharpens it. AI makes individual engineers faster at producing code, which means the scarce thing on your team becomes judgment: what to build, and whether the output is any good. Google’s DORA research found that AI mostly amplifies what’s already on a team, the strengths and the dysfunctions alike, which puts even more weight on the person setting direction. That is exactly the thing a leader is responsible for cultivating. I’ve argued the fuller version of this in why the 10x developer isn’t a myth and in how to build a team of 10x engineers, but the short version for leaders is simple: when the cost of code drops, the value of direction goes up, and direction is your job.

The real career arc

The path I walked, from software engineer to CTO to CEO, looked like a series of promotions. It was really a series of handoffs. Each step meant giving up the work that used to define me so that someone else could own it, and measuring myself by what the team produced instead of what I produced.

That’s the uncomfortable heart of engineering leadership. The skills that make you worth promoting are the ones you have to stop relying on once you are. Your job stops being the answer and becomes the people who find the answers. Get that right and you don’t just ship more. You build a team that ships without you, which is the only kind of scale that lasts.

It’s most of what we think about at Full Scale, where the whole model depends on engineers who own outcomes rather than wait for tickets. The leaders who get the most out of that are the ones who stopped trying to be the best engineer and started building them.