In Praise of "Normal" Engineers 🛠️

A guest article by Charity Majors.

Hey, Luca here! This is a new article from our brand new guest author program, where some of the best engineering writers in the world contribute to Refactoring with original pieces!

Today’s article is from Charity Majors, CTO of Honeycomb, and one of my favorite authors! Also check out her blog and her books.

With Charity we are going through what it means to create 10x engineering teams, and why this is a better strategy than fixating over 10x engineers.

Here is the agenda:

1. 📈 The problem with 10x engineers — why this concept is slippery and problematic.

2. 🧘‍♂️ In praise of “normal” engineers — the best engineering orgs are the ones where 1x engineers can do great work.

3. 🎽 Turning normal engineers into 10x teams — how to create top-performing teams that mint 10x engineers like nobody's business.

4. 🏆 Hiring the right people instead of the best — how to focus on our individual strengths, instead of our lack of weaknesses.

Let’s dive in!

---

---

Most of us have encountered a few engineers who seem practically magician-like, a class apart from the rest of us in their ability to reason about complex mental models, leap to non-obvious yet elegant solutions, or emit waves of high quality code at unreal velocity.

I have run into a number of these incredible beings over the course of my career.

I think this is what explains the curious durability of the 10x engineer meme. It may be based on flimsy, shoddy research, and the claims people have made to defend it have often been risible (e.g. “10x engineers have dark backgrounds, are rarely seen doing UI work, are poor mentors and interviewers”), or blatantly double down on stereotypes (“we look for young dudes in hoodies that remind us of Mark Zuckerberg”). But damn if it doesn’t resonate with experience. It just feels true.

The problem is not the idea that there are engineers who are 10x as productive as other engineers. I don’t have a problem with this statement; in fact, that much seems self-evidently true. The problems I do have are twofold:

1. 📈 Measuring productivity is fraught and imperfect

2. 🎽 Engineers don’t own software — teams own software

Let’s look at both:

---

📈 Measuring productivity is fraught and imperfect

First: how are you measuring productivity? I have a problem with the implication that there is One True Metric of productivity that you can standardize and sort people by.

Consider, for a moment, the sheer combinatorial magnitude of the skills and experiences at play:

• Are you working on microprocessors, IoT, database internals, web services, user experience, mobile apps, embedded systems, cryptography, gen AI… what?

• Are you using GoLang, Python, COBOL, Lisp, React, or Brainfuck? What version, which libraries, which frameworks?

• What adjacent skills, market segments, or product subject matter expertise are you drawing upon…design, security, data viz, marketing, finance, etc?

• What stage of development? What scale of usage? What matters most — prototyping rapidly to find product-market fit, or writing code that is maintainable and performant over many years?

Also: people and their skills and abilities are not static. At one point, I was a pretty good DBRE (I even co-wrote the book on it). Maybe I was even a 10x DB engineer then, but certainly not now. I haven’t debugged a query plan in years.

“10x engineer” makes it sound like 10x productivity is an immutable characteristic of a person — but someone who is a 10x engineer in a particular skill set is still going to have infinitely more areas where they are normal or average (or less).

I know a lot of world class engineers, but I’ve never met anyone who is 10x better than everyone else across the board, in every situation.

🎽 Engineers don’t own software — teams own software

Second, and even more importantly: so what? It doesn’t matter.

Individual engineers don’t own software, teams own software. It doesn’t matter how fast an individual engineer can write software, what matters is how fast the team can collectively write, test, review, ship, maintain, refactor, extend, architect, and revise the software that they own.

The smallest unit of software ownership and delivery is the engineering team.

Everyone uses the same software delivery pipeline. If it takes the slowest engineer at your company five hours to ship a single line of code, it’s going to take the fastest engineer at your company five hours to ship a single line of code. The time spent writing code is typically dwarfed by the time spent on every other part of the software development lifecycle.

If you have services or software components that are owned by a single engineer, that person is a single point of failure.

I’m not saying this should never happen. It’s quite normal at startups to have individuals owning software, because the biggest existential risk that you face is not moving fast enough, not finding product market fit, and going out of business. But as you start to grow up as a company, as users start to demand more from you, and you start planning for the survival of the company to extend years into the future… ownership needs to get handed over to a team. Individual engineers get sick, go on vacation, and leave the company, and the business has got to be resilient to that.

If teams own software, then the key job of any engineering leader is to craft high-performing engineering teams. If you must 10x something, 10x this.

Build 10x engineering teams.

Which leads to my next point 👇

🏃‍♂️ Make normal engineers do great work

When people talk about world-class engineering orgs, they often have in mind teams that are top-heavy with staff and principal engineers, or recruiting heavily from the ranks of ex-FAANG employees or top universities.

But I would argue that a truly great engineering org is one where you don't HAVE to be one of the “best” or most pedigreed engineers in the world to get shit done and have a lot of impact on the business.

I think it’s actually the other way around.

A truly great engineering organization is one where perfectly normal, workaday software engineers, with decent software engineering skills and an ordinary amount of expertise, can consistently move fast, ship code, respond to users, understand the systems they've built, and move the business forward a little bit more, day by day, week by week.

Any asshole can build an org where the most experienced, brilliant engineers in the world can build product and make progress. That is not hard. And putting all the spotlight on individual ability has a way of letting your leaders off the hook for doing their jobs.

The best engineering orgs are the ones where normal engineers can do great work

It is a huge competitive advantage if you can build sociotechnical systems where less experienced engineers can convert their effort and energy into product and business momentum.

A truly great engineering org also happens to be one that mints world-class software engineers. But we’re getting ahead of ourselves, here.

🙋‍♀️ Let’s talk about “normal” for a moment

A lot of technical people got really attached to our identities as smart kids.