Stop Hunting 10x Engineers: Build a 10x Organization Instead

Tech X (ex-Twitter) keeps reviving the same cursed legend: the 10x engineer.

This mythical creature moves faster than entire teams, rewrites whole systems on a weekend, and operates on raw brilliance and caffeine alone. Companies whisper about finding one, like hunters chasing Bigfoot footprints in the mud.

But Charity Majors – co-founder and CTO of Honeycomb – whose lecture I had the opportunity to attend at this year’s Craft Conference in Budapest – isn’t interested in chasing unicorns or Bigfoot. She wants you to build something stronger and less flashy: a “boring” engineering organization where shipping is safe, tools are sharp, and learning is routine.

The hero engineer is an illusion

“Stop worshipping at the altar of individual brilliance,” Charity says. “The fastest, healthiest engineering teams don’t run on heroes. They run on habits.”

We all know the “hero engineer: up at 2 a.m., fixing what no one else can, holding the whole system in their head. It’s a romantic image, but it doesn’t scale.

Here’s the uncomfortable truth: organizations built on heroes eventually break. If shipping relies on a few brilliant outliers, you’re not building a system; you’re betting they never burn out, quit, or block others.

Charity’s take? Build a world-class engineering organization that never needs heroes in the first place.

Shipping is a way of life

If there is a single non-negotiable truth in Charity’s worldview, it’s this: shipping is how engineers learn.

Not architecture diagrams. Not months of planning. Not 400-comment design docs. Shipping.

The faster your team can ship, the quicker they get feedback. The faster they get feedback, the faster they course-correct. And the faster they course-correct, the quicker they grow – not just as individuals, but as a unit.

You don’t need 10x engineers if you have a 10x feedback loop.

That’s why she champions small, continuous, reversible changes. She obsesses over reducing the time it takes to run tests, deploy, and observe production.

When shipping is slow, testing is slow, and every deploy feels like a minor act of self-endangerment, you create what she calls the “dark matter of suffering” – the invisible drag on velocity you don’t notice until your team feels like it’s wading through molasses.

This is why world-class orgs invest heavily in:

• High-quality tests that run fast enough to be trusted.
  
• Observability tooling that lets engineers see precisely what’s happening in production.
  
• Internal developer tools that remove friction from every part of the engineering cycle.

These aren’t “nice to have” perks. They’re what turn engineering from guesswork into craftsmanship and make shipping feel like breathing, not pulling teeth.

And here’s the kicker: when you make it fast and safe to ship, engineers stop worrying about breaking things and start focusing on building things.

Your org is a system (and it’s training your engineers)

One of Charity’s sharpest insights is that every engineering organization is a system, and every system produces the engineers it deserves.

If you give people slow CI pipelines, fragile deployments, and a production environment that feels like a haunted house, they will adapt by becoming risk-averse. They will fear change. They will learn to optimize for personal survival instead of team velocity.

But if you give them short feedback loops, strong tooling, and a culture that treats mistakes as learning opportunities, they will become bold, learn judgment, and ship.

This is the beauty of boring systems: they’re self-reinforcing. Every test you speed up, tool you sharpen, or friction you remove pays off every time you hire, switch teams, or learn something new.

You don’t have to go hire “world-class engineers.” You create them.

Who thrives at your company isn’t random – it’s a systems choice

During the Q&A session following her talk, I asked Charity a question that I believe lies at the core of this entire debate:

“How can managers shift their perspective on who is considered the best and who will thrive within their organization?”

You must start by observing who is thriving in your organization. Take a look. If you notice that the same narrow demographic keeps sticking around, that’s not an accident. It’s a systems issue.

She shared an example from Etsy: They fostered an engineering culture that celebrated deep care for code craftsmanship, which naturally attracted individuals who shared those values.

“You can’t do this alone as a manager,” she continued. “If you try to build a perfect little team culture in isolation, it will clash with the broader organization and likely fail. You need organizational support. But, simultaneously, you must be willing to identify the types of engineers your organization rewards – and ask yourself if that aligns with your goals.”

Charity’s “golden path” for balancing stability and innovation

I also took the opportunity to ask Charity about a challenge that many managers often find themselves grappling with:

“How do you balance fostering a “boring” engineering organization and supporting engineers’ enthusiasm for exploring new and exciting technologies?

Without hesitation, Charity provided a thoughtful response:

The more foundational your work is, the more conservative you should be.

“You cannot afford to be reckless if you’re handling databases or operating systems. These are the building blocks of your system, so ‘boring’ is essential in those areas.” She adds that if you’re working on developer tools or front-end experiments, you have more flexibility to innovate – it’s a spectrum.

She then introduced what she calls her “golden path” principle:

You define a well-supported, official stack as the “paved road”. If you venture off that path to explore something new, you take responsibility for maintaining it yourself. This ensures stability where it’s most needed while providing space for safe experimentation.

For Charity, the goal isn’t to stifle curiosity but to guide it in a way that fosters stability and innovation.

The right people, not the “best” people

This is where the “10x engineer” myth dies. Stop looking for the “best engineer” and start looking for the right engineer.

The right engineer isn’t the one who crushed every LeetCode problem in 30 seconds. It’s the one who’s excited about your difficulties, communicates, lifts the people around them, and can learn faster than the job changes.

At Honeycomb, says Charity, the interview process is built around conversations, not quizzes. Candidates walk through real-world scenarios with the engineers they’d work with:

• Why did you build this feature the way you did?
  
• What tradeoffs did you make?
  
• If you had more time, what would you change?
  
• How do you explain this to someone new?

Here’s the thing: many engineers can do the work, but those who can teach, explain, and collaborate multiply their value.

And new engineers? They’re gold. When everyone’s learning daily, no one coasts or repeats the same task on autopilot. They stay challenged, grow, and stick around.

Stop hunting unicorns. Start building systems!

Excellence at a 12-person startup differs from a 50.000-person enterprise, and both differ from open source. But one principle remains: in the long run, it’s not a few brilliant engineers but the compounding of hundreds of small, boring, unglamorous tasks that powers great companies:

• Fast, safe deploys.
  
• Clear, visible systems.
  
• Tools that remove friction.
  
• A culture where learning is normal.
  
• A hiring process that looks for the right people, not the loudest ones.

nd the result? A team that ships, learns, and grows. That’s not just sustainable – it’s unstoppable. So next time someone asks if you’re hiring “10x engineers,” smile politely and tell them the truth:

You don’t need 10x engineers. You need a 10x organization.

“And yes, it’s boring. But only in the way gravity is boring: invisible, inescapable, and the only reason anything stays standing”, Charity concluded.