How to Build a Team of 10x Engineers

QUICK ANSWER You build a team of 10x engineers by creating the conditions that produce them, because the fixed type everyone tries to recruit doesn’t actually exist. A 10x engineer is what a capable developer becomes inside the right environment: clear product vision, real focus, short feedback loops, and genuine ownership, minus the bureaucracy that slows everyone else down. Hire for the raw material, build those conditions, and you get 10x output without paying 10x salaries or chasing a unicorn that was never going to show up.

A while back I said on my podcast that the real 10x engineers exist, and they mostly exist in startups. It keeps coming up in conversations with clients, so it’s worth unpacking why.

In a startup, the developer who builds a feature often talked to the customer who asked for it. They sat in on the sales call. They heard someone complain about the bug. The loop between the work and the outcome is short enough that they can’t help thinking about the product.

As companies grow, that loop stretches out. Developers get tickets. They stop hearing the complaints and stop asking why. The job quietly narrows to execution, where someone else decides what to build and the developer builds it.

That isn’t a talent problem. It’s an environment problem.

Most companies trying to hire a 10x engineer are shopping for a finished state when they should be building the conditions that produce it. I made the full version of that argument in a companion piece on why the 10x developer isn’t a myth. This one is about what to do with that idea when you’re hiring and building a team.

What people get wrong about the 10x engineer

The term gets mocked, and I get why. It’s been stuck on every kind of nonsense: the rockstar who doesn’t need sleep, the lone genius who out-codes a whole sprint in a day, the brilliant jerk whose ego you tolerate because the output supposedly justifies it. That version is a caricature, and it’s not what I mean.

What’s real is that engineers don’t produce equal outcomes. One developer ships something that works, lands on time, and needs almost no cleanup. Another ships something that technically runs but leaves six months of technical debt and three broken integrations behind it. The gap in business impact between those two is enormous, often several times over.

Most companies assume that gap comes from raw technical ability, so they hire the smarter coder, pay for the better résumé, and spend six weeks chasing the perfect candidate. That’s the wrong place to look. The bigger driver is how the developer thinks about the work: whether they ask why we’re building this, what it’s supposed to do for the customer, and what success looks like, or whether they just close the ticket.

I wrote about this in my book, Product Driven: the problem is usually product thinking. Most engineers have the technical skill. What they’re missing is the habit of asking what the code is actually for. I’ve watched it play out hundreds of times across VinSolutions, Stackify, and Full Scale, where the developer with the stronger résumé produced worse business outcomes because they optimized for the spec instead of the result. Developer productivity is mostly a leadership problem, which is why throwing résumés at it rarely works.

The short version of what a 10x engineer actually needs is four things, and only one of them is talent: knowing what to build, the ownership to act on it, the time to focus, and the skill to deliver. Talent is the part every hiring process measures, and the smallest of the four. The other three you build around the person after they walk in the door.

Why a great hire still depends on the environment

Here’s what a typical senior-engineer hiring process looks like. Post a job description, get 200 applicants, filter for years of experience and stack match, run a coding challenge, make an offer.

Nothing in that process tells you whether the candidate thinks like a product owner. Do they push back when a spec is unclear? Do they care what happens after the code ships? Do they ask why before they start building? A standard technical interview answers none of that.

So even a great hire is a bet, and the bet only pays off if the environment lets it. You can hire someone with every instinct of a 10x engineer, drop them into a place that buries those instincts, and watch them turn into a ticket-closer within a quarter. The reverse is the whole opportunity: take a solid, curious developer, put them somewhere the conditions are right, and they grow into the engineer you were trying to hire.

You don’t find a 10x engineer. You build the place where one can happen, then hire people who can grow into it.

The environment that creates 10x engineers

When I think about what that environment requires, it’s four of the conditions I built the Product Driven framework around: vision, focus, clarity, and ownership. They aren’t soft ideas. They’re the specific things that let a capable engineer turn into a 10x one.

Vision. Every engineer needs to know what the company is building and why. In the book I make the case that vision is the thing guiding the work when you’re not in the room, and that a developer who understands where the product is going makes a hundred small decisions a week in the right direction without being told. The practical version is a North Star the whole team can name. At VinSolutions we pointed everyone at lead response time and cars sold, because that was how our customers measured success, and it turned a hundred scattered judgment calls a week into aligned ones. Without that, a developer who only sees the destination as the next ticket makes those calls in a random direction and ships them.

Clarity. This is the short feedback loop, rebuilt on purpose. A startup engineer is effective because they can see the customer and know what success looks like, and the book breaks that into three kinds of clarity worth protecting: product, scope, and technical. Clarity is a daily practice, not a one-time spec drop. The mechanism I’ve seen work best is a standing demo day. The book tells the story of Basys, where an engineer named Chris Borchers started a weekly session where engineers showed working software and explained the pain they were solving. It pulled in operations, sales, and eventually the CEO, who called it the best meeting he’d ever been in. That ritual does more for clarity than any requirements document.

Focus. Real, uninterrupted time to go deep, instead of a day chopped into six meetings. This is where the work actually happens. I have ADHD, and when I lock onto a problem I care about, I cannot put it down. Not long ago I got an idea for using Claude Cowork to rewrite the content across our website, and I disappeared into it for two solid weeks until I had a working system. That kind of depth only shows up when the environment protects the time for it. The quiet enemy is internal urgency, the stakeholder pressure that outranks actual customer pain, and the book’s rule is to make trade-offs visible so the team learns what to say no to. Protect the time and the priorities, and you get the depth. Fragment everyone’s attention and you never see it.

Ownership. This is the condition that matters most and the one most companies strangle. Engineers need to own the outcome rather than the scope, with the room to decide how to get there and then go do it. The hard-won lesson in the book is that ownership grows through trust and safety, and that fake delegation, where decisions stay gated and direction keeps shifting, kills it fast. The mechanism that taught me the most was on-call. At Stackify we rotated engineers through it, so they lived with what they shipped, heard the angry customer at 2 a.m., and fixed what broke. Quality went up, because they owned the result instead of the ticket. Ownership is what lets someone take their creativity and go build something good instead of waiting for permission at every step.

The thing that kills all four is friction. Bureaucracy, sign-offs stacked several deep, a product manager standing between the engineer and the actual customer, work that gets re-scoped after three weeks until nobody invests in whether it’s right. Pile on enough of it and your best people stop asking questions, stop pushing back, and stop caring. Not all process is the enemy here. Some of it carries real weight, like security review or the coordination a large system genuinely needs. But most of what slows a good engineer down is just accumulated bureaucracy, and clearing that away while you protect vision, clarity, focus, and ownership is how you get the engineer everyone is trying to hire.

One caution, because it’s the failure mode of this whole idea. Ownership is not a license to be the brilliant jerk. I was that guy when I was younger, frustrated that nobody else moved as fast or saw it the way I did, and I only became useful as a leader once I accepted that other people think differently than I do and are better than me at things I’m weak at. The environment you want rewards ownership and curiosity, takes courage to speak up in, and has no room for ego. A genius who has to be the hero everything routes through just becomes the bottleneck, however good the code is.

AI fluency is part of the environment you build

I’ll be honest: around mid-2025 I was a skeptic. I didn’t think AI was changing software development in any deep way. Then it kept getting better, and now I push our teams to use it as much as they can, in a structured way. The thing that unlocks it is the same product thinking as everything else, knowing why you’re building before you let a model build it.

Awareness is having used GitHub Copilot or Claude or Cursor. Fluency is knowing which tasks to hand the model, how to get something useful out of it, how to review what it produces, and when to skip it entirely.

Sundar Pichai said in April 2026 that roughly 75% of Google’s new code is AI-generated, and every line is still reviewed and approved by an engineer. That’s the right model, with the human owning the judgment instead of writing the boilerplate. The judgment is the whole job: Veracode’s 2025 research found that 45% of AI-generated code carried a known security flaw, and bigger models weren’t safer. The review layer is what keeps 10x output from turning into 10x liability.

This is why a high-volume code generator is the wrong hire in 2026. Google’s DORA research summed up the year well: AI amplifies what’s already there. Strong teams get faster, and weak teams ship their problems quicker. AI makes output cheap. Judgment stays scarce, and that is the part that produces a 10x engineer.

Not every project needs a 10x engineer

I was having coffee with a founder friend recently who told me he was hunting for 10x engineers to build out some ideas he’d been sitting on. We talked through what he was actually trying to do, and within a few minutes he realized he didn’t need a 10x engineer at all. He needed the right process, the right tools, and two people who would ask him good questions. The buzzword dissolved the moment we applied it to something real.

Some work is well-defined, well-scoped, and just needs to get done cleanly. A developer who tries to rethink the product strategy on a maintenance ticket is a liability on that kind of work. So the better question is simple: what does this work actually need?

We had a client doing exactly that kind of work, rolling out a straightforward HTML implementation across a set of websites. Limited scope, a fixed finish line. They needed capable developers who execute cleanly and move fast, so that’s what we staffed. The honest version of our cost model is that our developers don’t cost 10x a US engineer, but there are still tiers by seniority, and matching the right level of developer to the right work is how you get the most out of what you spend. A team that keeps getting better beats a single mythical hire every time.

What to screen for when you hire

You can’t interview for a finished 10x engineer, but you can screen for the raw material that grows into one in the right environment. A few things I look for.

Ask about a time they pushed back on a requirement. The answer tells you whether they had enough product context to form an opinion, and whether their old environment let them voice it.

Ask what happened after something they built shipped. Did they follow up and care how it landed, or close the ticket and move on?

Ask them to explain a technical decision to a non-technical person. Communication, curiosity, and courage are the three traits I keep seeing in engineers who produce outsized results, and someone who can explain what they built and why, without jargon, is already thinking about audience and impact.

Most of all, look for curiosity over raw competence. The developers who keep up with AI tools usually aren’t the ones with the most impressive backgrounds. They’re the ones who install the new thing over the weekend and show up Monday with five opinions about it. The technical skills matter, but I’ll take the engineer who asks “why are we building this?” over one who never asks, every time.

How Full Scale builds the environment at scale

I’m the CEO of Full Scale, so weigh the next part accordingly. I’ll let the structure speak.

We built the Product Driven framework because I needed to explain, in operational terms, what we were trying to produce in our engineers: people who carry vision, focus, clarity, and ownership into the work, whatever the org chart says. Product thinking belongs to every engineer, not only the founders and PMs.

On the AI side, what we built is structured knowledge transfer across 350-plus engineers, where people share what’s working and what isn’t on the kinds of problems we actually solve. We run capstone projects where we review real code to find the judgment gaps, and sessions with engineering leadership about where AI got it wrong and why. The goal is the Google model: faster on the work that doesn’t need judgment, harder judgment on the work that does. The leadership layer of this gets its own treatment in great engineering leadership, because building the environment is mostly a leadership job.

One client came to us because their US team was resisting AI adoption, and they wanted the Full Scale team in the Philippines to lead it. Our senior engineering manager ran weekly check-ins, drove the training, and kept asking what the client was building and why. A month later the client was raving, because the Philippine team’s results were creating buy-in from the US side. That’s what the environment produces when you combine real training with people who already think about the why.

The numbers that come out of it: 350-plus developers and operations staff, four straight years on the Inc. 5000, 93%+ annual developer retention, and a Great Place to Work score of 95% against about 65% for a typical company in the Philippines. The AMC Theatres team is what it looks like at enterprise scale. Their CIO, Derrick Leggett, put it this way: “It’s a fully integrated team. It’s just some of the people happen to be living in the Philippines.” They’re in the standups and the roadmap conversations. They know what the work is for, which is exactly the condition that produces 10x outcomes.

The cost case, spelled out

This is where “without paying 10x salaries” turns into arithmetic. A US senior software engineer earns $150,000 to $185,000 in base salary. Add benefits, payroll taxes, equipment, and recruiting overhead, and the loaded cost runs about 1.25 to 1.4 times base, which puts a senior US developer north of $200,000 a year. Full Scale bills $30 to $40 an hour, which works out to roughly $62,000 to $83,000 a year.

Senior developer	Loaded annual cost
US hire ($150k–$185k base × 1.25–1.4)	~$200,000+
Full Scale ($30–$40/hr)	~$62,000–$83,000

That’s 50 to 60% below the loaded cost of a comparable US hire, before recruiting fees. Most offshore shops optimize for price instead of impact. I call that cheapshoring, and it’s why so many offshore engagements disappoint: you save money and lose the product thinking. We hear the same story from new clients constantly, who tried offshore staff augmentation before, got something between bad and fine, and came to us because the difference was obvious. The difference is the environment, the same vision, focus, clarity, and ownership I’ve been describing, built into how we train and run teams. Affordable doesn’t have to mean low quality. A product-driven, AI-fluent team at staff augmentation cost is a different proposition than “we’re cheaper.”

Full Scale has been placing senior, product-thinking developers since 2017, more than 500 placements across 200-plus tech companies, built around the Product Driven approach and the AI training behind it. If that’s the kind of 10x team you’re trying to build, it’s worth a conversation.