Thread by @mipsytipsy

Thinking about great teams today. (Yes, still with the damn DORA report.) People see the "7% of teams function at a elite level" stat and they assume those teams must naturally be made up of the top 7% of elite engineers. Not so.

SO not so.

You can't just gather together 10 engineers in the top decile and assume you get a team in the top decile. Being a good teammate relies on categorically different skills than being a good engineer.

In fact, people who are used to leaning on their eng skill set too hard tend to fail in predictable ways.. So what you get is a powerful engine of lemmings (who would strenuously resist that description, probably on reddit).

But this is the category of mistake that the Googles and Facebooks of the world tend to make. They seriously need more mediocre engineers.

I say this with love.

Powerful engineers are powerful tools. They can super charge any team. But they won't necessarily build anything worth building without a complement of skills.

I'm not a horse person, but I know enough to know that your show pony is using different skills than your lead sled dog guiding a team of 12. Wait, did I switch species...

I've seen mid level engineers join elite teams and become elite engineers. I've seen elite engineers join fucked up teams and their productivity screeched to a halt. Which begs the question: what even is an elite engineer?

The big companies define engineering greatness in raw data structures and algorithms, because frankly that's the easiest answer. I define it in terms of impact.

You can't be a great engineer if you aren't on a great team. Period. So it's your job to help the team get there.

The best teams I have ever worked on had maybe one or two "elite" engineers from the top 7% in raw ability, and the rest were in the messy middle.

Turns out there's a fuck ton of work that has to get done, that doesn't require some particular genius to do it.

I will posit that anyone in the middle 50% of raw engineering ability is more than capable of holding their own on an elite engineering team with a balance of skills.

Maybe even the middle 75%.

What we learned from the DORA report is that speed and quality aren't tradeoffs, they accelerate each other. That it's not about preventing all failures, it's about them catching them and remediating and learning from them fast. This is not the stuff of genius engineering.

It's also about having the right tools. Consider the canonical story where an engineer leaves Google after 5 years and joins the real world, and staggers to a halt. What happened?! They were a high performer!

...when they had the right tooling and a support staff of thousands

Honeycomb is one of those rare few tools that can leverage your engineers and be a force multiplier for them. I've experienced it, and I've heard it from our users, but I'm still trying to figure out how to sell it as such. 🤔

We have no dedicated ops team at honeycomb, 2.5 years in/after lots of accelerated growth. Because we dogfood like crazy, and expect engineers to support and understand their own code.

And honeycomb makes it not just reasonable, but easy.

We also don't have (or want) a team of "elite 7% engineers". Fuck that. It's not what matters. We want solid engineers who care. Period.

Anyway. What you need to build an elite engineering team is not lots of elite engineers, but a team that is willing to iterate on their tools and processes.

Care about user experience. Double down on what works. And choose good tools to help you get there.