Of 10x Engineers and 1/10th Teams

The future will not be YOLO'd

Pieter Levels had done it again. The king of indie makers shared his latest solo-developed hit: PhotoAI, a highly-focused product generating a tidy $65k of MRR ($780k annual recurring revenue), built with… raw PHP and jQuery.

Levels’ recent grenade of a humblebrag was the latest in renewed conversation about “10x engineers”, which has been driven largely by the rise of AI-assisted coding, along with AI-assisted everything. Will AI-as-force-multiplier enable 10xers to become 1000xers?

And this was before ChatGPT

The idea of a “10x engineer” tends to elicit eye rolls, likely due to the use of the term from over-enthusiastic recruiters, who have breathlessly included the term in job descriptions alongside “rockstar engineer” and my personal favorite, “coding ninja”. But while I’ve never encountered any engineers that balance their development work with sold-out MSG shows (in the former case) or secret assassinations (in the latter), I’ve certainly encountered engineers like Levels who just… produce an order of magnitude more impact than the vast majority of their peers.

Talent is distributed on a curve, so it’s no wonder 10x, 100x, whatever-x engineers exist. Take natural talent distribution, apply the diminishing marginal production costs of software, and multiply by internet scale, and there’s nothing magical about 10xers.

What’s more interesting than the existence of 10xers, is the paucity of 10x teams. After all, when we say “10x engineer”, it’s a relative proposition – 10x what?

Perhaps the best way of becoming a 10x engineer is to leave a 1/10th team.

What’s a 1/10th team? It’s a team that works long hours, but doesn’t ship value to users. Or a team that ships features, but doesn’t increase business value. A team that spends countless hours in meetings, but never manages to make decisions. A team that meets every couple weeks for a retrospective, but never improves their process.

Unfortunately, I’ve encountered far more 1/10th teams than 10x individuals. And this discrepancy should not be the case. Sure, we’ve all known since The Mythical Man Month that engineers don’t scale linearly: every person introduces communication costs and collaborative overhead. But assuming one is hiring correctly, a group of 10 individuals should provide significant value: greater breadth of expertise, greater diversity to generate productive ideation, more eyes to identify and poke holes at irrational assumptions in planning.

So why do so many 1/10th teams exist?

Ownership is not Measured in Stock Options

A distinguishing characteristic of any product built by a lone-wolf engineer is their level of “skin in the game”. It’s not just the financial incentives, both in terms of the cost of time and money invested in building something and the returns on that investment. It’s the social capital and the pride that comes from adoption.

Take this substack: it’s my own creation. Every individual reader delights me; every like or comment or share fills me with joy. I’ve taken something of mine, put it into the world, and it’s purely mine. There’s both desire for adulation and attention, and fear of rejection, and this heady emotional cocktail is intoxicating and addictive. For a solo-engineer, especially one shipping often and publicly, there’s a constant feedback loop of these emotional highs and lows.

Compare this feedback loop and pride of ownership to the typical team. They work for weeks or months on a big launch and then… what? In a remote environment, there’s a 12 person shoutout on Slack. In a co-located environment, maybe there’s a happy hour. Don’t forget the special “swag” of some scratchy t-shirt of highly commoditized origin. What part of the output is mine? What part of it is my teams? Does anyone even know I was part of creating it?

The tragedy of the commons exists because common ownership is of secondary importance to personal ownership (and the associated responsibility). Replicating that dynamic within teams and organizations is a recipe for diminished care.

What’s more, the greater any team’s win, the less any individual on the team receives the public credit – it goes to the company brand, or perhaps the founders and leadership team, who are invited to parties and dinners and conferences to speak about their brilliant strategy in delivering said win while the team that actually built the win… works anonymously in their scratchy t-shirt swag.

Curiosity Fuels Creativity

What are we building? How are we building it? For a solo-engineer, every project can scratch a curiosity itch. Maybe it’s an opportunity to learn a new technology, or address a business hypothesis, or any number of things. The individual can align a project perfectly with their own interests, which pours rocket fuel on the willingness to work harder, longer.

Compare that to most engineering teams, who are handed a spec by a product manager, a marketing brief from a PMM, an understanding of users and their needs from design and UXR. As for technological decisions: well, those are made by simple fact of top-down timelines. If you’re told how long you have to ship a thing, you don’t really have the capacity to explore new and better approaches to delivery.

Conventions are Costly

About two months ago, I spiked a new feature for Loom in a couple weeks, which was originally estimated to take at least a few engineer-months to build. I did it as a solo-engineer. Then, in mid June, I spent at least the same amount of time as the original spike to re-write the whole thing, because I was about to transition the code from a solo-engineer driven POC to a team-owned feature for development.

When you’re coding for yourself, you’re writing for yourself. There’s countless decisions in style that don’t matter when you’re writing for yourself – your own style is your own style – but which can produce significant headaches when working with others. Our idiomatic styles, whether as individuals or as teams, are meant to accelerate our work via conventions; these conventions allow us, ideally, to spend less time on things that don’t really matter. But the aligning on these conventions and idioms takes time. The more people to align, the more time it takes (exacerbated by the tyranny of small differences). And then every time a team changes members, this norm-formation needs to happen all over again.

This alignment doesn’t just manifest in coding style and architecture; every decision benefits from tighter loops and cleaner alignment. Just this last week, legendary product builder and strategist

Scott Belsky

offered reflections on the future of teams, and advocated for “collapsing the talent stack”. He writes on his Substack (emphasis added):

As I reflect on the teams I’ve led and hundreds of start-ups I’ve worked with, there is a consistent unfair competitive advantage i’ve witnessed when the talent stack was collapsed - when the lead designer was also the product leader, when the front-end engineer was also a designer, when the designer is also a great copywriter, when the product leader was also the founder/ceo, etc. Tighter conduits for decision making and synthesizing information are an incredible advantage when it comes to crafting products. Many start-ups enjoy the benefits of collapsed talent stacks and then undo them as they grow (and most big companies just don’t understand this). In your hiring (and your consolidating), I encourage you to collapse the stack whenever you can.

The Path to 10x Teams

As wonderful as indie makers are, the future is not going to be created by AI-fueled solo engineers. Rather, the future will be created by 10x teams.

Lone Palm Labs, the creators of the buzzy new photo sharing app Retro, share the following on their site:

We’re building our company on the conviction that the best things come from small teams of people with a shared passion and the right mix of talent, experience, and chemistry.

Count me as an enthusiastic +1.

We need smaller teams, with real autonomy to pursue their curiosity and creativity, with clear and visible ownership to share the spoils of a win – and the ignominy of a failure. We need long-lasting teams, with the kind of communication short-hand that emerges from hard work solving compelling problems, not top-down cultural “celebrations”.

Let me be blunt: if you’re starting your project with writing a DACI, you’ve already lost.

Small, autonomous teams don’t need a DACI. Small, autonomous teams don’t need to spend two to four months a year in planning cycles. Small, autonomous teams don’t need to argue over just what tenth of a percent of a metric is going to move in an OKR. (They don’t even need the OKR, for that matter.)

There’s joy in building something that’s yours. But there’s greater joy in building something with people you care about it. The balance is finding a scale that allows you to maintain the individuality of a solo project, with the camaraderie of a team project. It’s not a two-pizza team. It’s a team where you know every teammate’s favorite topping.

If you’re an IC, finding a team like this will provide incredible satisfaction and growth, and likely a good amount of financial reward. If you’re a leader, building and protecting teams like this will enable the kind of culture that builds truly iconic brands and products.