Shipping Fast Changes Your Life ⚡

And what happens to your team when you don't

Last week I discovered that the "10x Engineer" idea had officially become a meme.

I also learned it was originally born out of real findings from a 1968 paper, titled "Exploratory experimental studies comparing online and offline programming performance". The authors showed that the performance ratio between the worst and best programmers was ~10.

I have never been a great fan of this idea. Not only I don't find it particularly useful as a mental model, but it is dangerous too. It easily leads to justifying toxic behaviour, and to creating ridiculous interpretations of the engineering work.

My modest proposal is to shift our focus from 10x engineers to 10x teams.

Great teams make great engineers, while viceversa is not guaranteed.

Everyone who has been in the industry for some time has an intuitive understanding of what separates high performing from low performing teams. If you happened to join a few in both categories, you may have noticed what things look like:

• ⬆️ High performing teams spend their time delivering features and moving the business forward.

• ⬇️ Low performing teams spend their time fixing things, waiting for things (code reviews, deploys, each other) and fighting with things (infrastructure, their tools, each other).

Sounds familiar?

So, how do you create a high performing team? 👇