The 10x Developer Isn’t a Myth. I Am the 10x Developer.

Search “10x developer” and almost every result tells you the same thing: it’s a myth, a fairy tale managers tell each other, a bit of Silicon Valley folklore that does more harm than good.

I think they’re wrong.

The 10x developer is real, and I’ve been one my whole career.

But it has almost nothing to do with what most people picture. They imagine a genius who types faster than everyone else and has every framework memorized. Whether you call it a 10x engineer or a 10x programmer, that lone-genius picture is the part that falls apart. What’s real underneath is more boring, and a lot more useful, because you can build it.

The lone-genius version really is a myth

Let me start by agreeing with the skeptics on a couple of things.

When we sold Stackify, there was a developer on the team everyone treated like a god. He could debug anything. He knew every corner of the codebase. People lined up to ask him questions. For a long time I thought that was what a 10x developer looked like: raw, intimidating coding skill.

It wasn’t. Knowing every framework didn’t move the business. It mostly made him the person we couldn’t function without, which is a fragility problem in disguise.

There’s a darker reason people call it a myth, too, and it’s worth saying plainly. You don’t want the kind of 10x developer who thinks they’re better than everyone else, the genius in the room who has to be the hero and the bottleneck everything runs through. For years the label was basically code for that brilliant jerk, the one who ships fast and leaves everyone else cleaning up behind him, and it carried so much bro-energy baggage that plenty of good engineers won’t say it out loud. That reputation is earned. Worshipping one coder and building the whole team around his ego is a culture problem dressed up as a productivity strategy, and it usually burns everyone out, including him.

The famous “10x” number doesn’t really support the genius story either. It traces back to a 1968 study that found big gaps between the best and worst programmers, somewhere between 10x and 28x depending on what you measured. The researchers weren’t even trying to measure individual talent. They stumbled onto it while testing something else, on tiny tasks, with people working alone. People have argued about it ever since.

You can’t put a clean number on any of this, which is the skeptics’ favorite objection, and a fair one. But the more useful finding came later: most of the variance comes down to the organization a developer works in, not the developer. The same person is wildly more productive at one company than at another. I dug into why in a separate piece on measuring engineering productivity, so I won’t relitigate it here.

If the environment is most of the story, then a 10x developer is less someone you hire than a set of conditions you create. And once in a while, one person gets all of them at once.

The actual formula

Here’s what it really takes to move 10 times faster than the people around you. It comes down to four things, and you need all four at once.

First, you have to understand what needs to be done: the real problem underneath the ticket, and why it matters.

Second, you need ownership, the agency to decide how to solve it without stopping for permission at every turn.

Third, you need time. It means real, uninterrupted focus, the kind you never get in a day carved into six meetings.

Fourth, you need the talent to actually pull it off.

Most people obsess over that last one. Talent is the part everyone screens for and argues about. But one thing has become clear to me over the years.

Talent is the smallest part of the formula.

Plenty of skilled developers never get within a mile of 10x, because they’re missing the other three. They’re talented, and they’re stuck.

I said this on my podcast a while back, and it’s still the cleanest way I can put it. A 10x developer is someone who knows exactly what needs to be done, knows how to do it, and can just go do it, with no bureaucracy and nobody writing their requirements. They wake up, they know what matters, and they build it.

I had Noah Lindner on the show too, a former Airbnb engineer who liked the term enough to name his company after it. His take was that a 10x developer is someone who ruthlessly automates their own workflow with the best tools. He’s not wrong that good tooling matters. But automating your workflow only helps once you already know what to build. The knowing comes first. Everything else is just speed stacked on top of it.

I felt this for the first time at 19, before I had any of these words for it. I built a little database for a local car dealership. Nobody told me what to make. It was the owner, his problem, and me. I shipped something that actually solved it, and the feeling was electric. That feeling has never changed. Years later at VinSolutions, the company I bootstrapped to $35 million in revenue and sold for around $147 million, I worked the same way. I’d talk to a customer in the morning and ship a fix that afternoon. There was no ticket and no product manager in the middle, just the problem and the room to solve it.

That’s the trick. When you have all four pieces, you move so fast it looks unfair.

Why you mostly see them in startups

So why does the 10x developer feel so rare?

Because most people, at most companies, never get all four. They’re talented and they have time, but they spend their days waiting: for the spec, for sign-off, for someone to tell them not just what to build but how to build it. What caps their speed is the system around them. Developer productivity is mostly a leadership problem, more than a talent one.

This is why you mostly see 10x developers at startups. A startup hands someone a problem and a goal and says go. There’s no Jira queue filled by committee, no three layers of approval, no product manager translating the customer through a game of telephone. The friction that caps everyone at 1x simply isn’t there yet. The job is figuring out what’s actually worth building and then building it.

Drop that same developer into a big company and watch them slow to a crawl. The talent didn’t change and the hands didn’t change, but the output falls to a tenth of what it was. Take away the ownership and the speed goes with it.

Laura Tacho, the CTO of DX, made this point better than I could when she came on the podcast. The real 10x developers of the future, she said, are tiny teams that deeply understand the product and have no organizational friction to fight through. They just move. Meanwhile the big company drowns in its own process. The small teams that really understand the customer, in her words, run circles around everybody else.

The hard truth is that most engineers never get the chance to work that close to the problem, because nobody ever hands them the keys.

ADHD is my version of the engine

I have ADHD, and I’ve come to see it as one of my biggest advantages.

Most people I know with ADHD have a hundred ideas running at once. That’s the creative side. The flip side is hyperfocus. When I lock onto a problem I find interesting, I genuinely cannot put it down. I think about it in the shower, at dinner, at two in the morning. I stay on it until I figure it out, long after a reasonable person would have moved on.

Take a recent example. I had an idea to use Claude Cowork, Anthropic’s AI tool for getting real work done, to help rewrite the content across our entire website. Then I vanished into it for two weeks. Morning to night, it was the only thing I could think about. I built something elaborate inside it, and it now helps draft a huge amount of our content. Two weeks, one problem, almost nothing else got my attention. Call it discipline if you want, but it’s really just what my brain does when it grabs onto something it loves.

That’s the part people miss about the 10x developer. A lot of that speed is obsession aimed at the right target, with nobody standing in the way. Raw horsepower has less to do with it than people think. Point someone wired like this at a problem they care about and they’ll move mountains, because nobody is assigning them the work and nobody is slowing them down. A lot of the founders and CTOs I know are wired the same way. The pattern and the job line up almost too well.

I won’t pretend it’s sustainable, because it isn’t, and people like me burn out. But burnout isn’t even the usual ending. More often my brain just gets bored. I’ll go all in on the Cowork build for three or four weeks, and then one morning the spark is gone and I’m already deep in something else. The lucky thing about software is there’s always a next thing to grab: a big rewrite this month, an ugly production bug the next, then a project to cut our hosting bill in half. I bounce from one to the next, and somehow it adds up to a career.

For years I was the guy who showed up to the meeting, opened his laptop, and kept working on whatever I was hyperfocused on, because I could not stop thinking about it. Everyone else was in the room. I was somewhere better, pulling my dopamine from the problem instead of the agenda. It was a little rude, and it’s also exactly what being a 10x developer feels like from the inside.

AI did not hand everyone a 10x

This is where 2026 complicates things. The obvious objection to everything I’ve said is that AI changes all of it. Now anyone can be a 10x developer, right?

I use AI constantly, and it really has made me faster, so I want to be careful here. But the real impact of AI on software development is clearer than the hype, and it is not the great equalizer people hoped for.

A 2025 study from METR put this in sharp relief. Experienced developers using AI tools expected to finish their work about 24% faster. Afterward, they felt like they’d been about 20% faster. They were actually 19% slower. The feeling of speed and the fact of speed pointed in opposite directions, and a 2026 follow-up found the slowdown largely held for experienced developers.

DX, the company Laura runs, found something similar across hundreds of companies. AI usage shot up, but the work developers actually shipped rose by around 10%, nowhere near 10x. One of their senior engineers said it plainly: a four-day task might now take three, but that doesn’t mean he’s shipping three times the work.

Google’s CEO has said roughly 75% of the company’s new code is now AI-generated. That number gets quoted a lot. The part that gets dropped is the rest of the sentence: every line is still reviewed and approved by an engineer. And the 2025 Stack Overflow survey found that 84% of developers now use or plan to use AI tools, while only about a third trust what those tools produce.

Put it together and the picture is consistent. Google’s DORA research summed it up best: AI amplifies what’s already there. It makes a strong developer faster and a chaotic team more chaotic. It doesn’t manufacture judgment. This is the same point I keep coming back to about building software when AI writes the code: the tool got faster, the thinking didn’t get easier.

Which gets at the thing I really believe.

The bottleneck was never typing. It was knowing what to build.

AI is incredible at the typing, and useless at deciding what’s worth typing, whether the result is any good, and whether you should have built it at all. Those are exactly the scarce parts of my formula: knowing what to do, owning the call, having the authority to make it. AI hands you a faster engine. You still have to do the steering. So it makes the person who already knows where they’re going dramatically faster, and it leaves everyone else stuck at the same intersection, just generating code at it more quickly.

The other kind of 10x developer

There’s one more version of this, and it’s the one I care most about now.

For most of my career, being a 10x developer meant my own output. My problem, my obsession, my afternoon ship. That works right up until you’re running a company, and then it stops working, because you become the bottleneck. Every decision waits on you. The thing that made you fast is now the thing slowing everyone else down. Learning to scale past that was the hardest part of the job for me.

It was personal, too, because for a long time I was that brilliant jerk I just warned you about. When I was younger I got frustrated that other people couldn’t move as fast as me, didn’t care the way I did, and didn’t see what I saw. Growing up meant accepting that everyone is wired differently, and that the people who frustrated me had strengths I didn’t. That shift, from being annoyed that nobody else was me to actually valuing what other people brought, is the same one that turns a strong developer into a leader. I couldn’t make anyone else more productive until I’d made it.

I wrote about this turn in my book, Product Driven, and it’s the lesson that took me the longest to learn.

The most productive thing I could do was make other people more productive.

Once that clicked, my definition of 10x flipped. The most valuable person on a team is usually the one who gives everyone else clarity on what to build, hands them real ownership, and then gets out of the way. They 10x the whole team around them, not just their own output.

Honestly, “developer” is the wrong word for that person. I’d call them a 10x teammate, and you don’t need a title to be one. At scale you might call them a 10x leader. Either way it’s the same instinct as the kid who built a database at 19, just pointed at a team instead of a task. The question changes from “what can I build” to “what can we build without me in the room.” It’s also the core of what engineering leadership actually looks like: the best leaders multiply the people around them instead of out-coding them.

That’s also why I’m wary of the lone-hero version, even though the title of this piece leans on it. If your product depends on one irreplaceable genius, you’ve got a single point of failure wearing a cape.

So, is the 10x developer a myth?

No. And here’s the simplest way I know to spot a real one.

Invite them to a meeting and watch who can’t stay in it. The 10x developer is the one half-listening with a laptop open, still chewing on something they can’t wait to get back to. They’ve found a problem they’re excited about, and the meeting is in the way of it.

That’s the whole formula in one image: someone fired up about the problem, nobody slowing them down, and good enough to actually do the work. You can’t fake the excitement and you can’t buy the skill. But the part in the middle, whether you slow them down, is entirely on you.

Which is why most of what passes for hunting a 10x developer is really just a company getting in its own people’s way.

You don’t find a 10x developer. You stop blocking one.

Give a capable person a problem worth caring about, real ownership of it, and the room to disappear into it, and you’ll be surprised how many of your 1x developers were 10x all along. The best leaders take it further. They don’t just protect that spark in themselves, they build a whole team of 10x engineers who work that way. That’s most of what we do at Full Scale: we help you build a team in the Philippines that owns its work, because that’s where the speed comes from.

Build the place where someone can finally move, and the genius shows up on its own.