4 lessons from small teams that ship fast

Software engineering provides a lot of leverage. A small team can generate a disproportionate amount of value or impact a huge number of users.

For example, Instagram scaled to 14 million users with only 3 engineers, back in 2011.

Examples of teams that ship fast

I did my best to display a variety of teams below.

They all vary in size.

OpenAI

OpenAI shipped ChatGPT, ChatGPT Plugins, and GPT-4 in the span of 6 months. Considering their competition is Google (170k+ employees), OpenAI’s ~335 employees (in 2022) seems tiny in comparison.

Source: Trendline

Bun

The new “fast all-in-one JavaScript toolkit” made waves in the frontend world upon it’s v1 release. The team seems to have around ~10 people total.

Bun is an impressive engineering feat. It replaces many parts of the JS ecosystem as a faster drop-in replacement.

Source: Bun 1.0

Meta’s Threads

The team started with 12 and grew to around 70 right before shipping (“peak week”). They shipped faster than their expected launch date and handled 100M+ users with ease. While they did have the help of Meta’s enormous resources, it still is an impressive accomplishment regardless.

But, has Threads “outperformed the competition”? We don’t know yet as it’s still ongoing, but it has set some user acquisition records. It also had one of the smoothest social media launches I’ve seen.

Retention is now a struggle for Threads, but it set the record of 5 days to reach 100 million users worldwide.

Source: Genuine Impact

Indie hackers / Solopreneurs

Pieter Levels, Damon Chen, and Danny Postma have one-person businesses (+ contractors) that make $1M+ a year. They are not the only ones, but the most popular and public about their earnings on X/Twitter.

Pieter Levels’ current public revenue statistics 

How small teams ship fast

These lessons not only apply to teams, but also can be used by any engineer in their own work or projects.

Keep things simple and have a clear vision

Make an unbroken MVP first and add features later. 

• ChatGPT launched with the focus on chatting. Features like searchable history and pre-prompting were added later on. 

• Threads launched with just an algorithmic feed - no web app, search, etc. 

Reuse code liberally

As engineers, it can be tempting to create something from scratch. But, our job is to solve problems, not fiddle around with the latest tech stack (though that is fun!).

• Threads re-used parts of Instagram’s Django stack.

• Many of the mentioned indie hackers use the same stack for everything. Pieter Levels is particularly known for using PHP and jQuery for all his products.

Build upon the work of others

Great products and software are built through the incremental innovations of the work of the team and of others.

I’m stating the obvious, but, everything is a remix.

• Bun built on top of the amazing work of NodeJS contributors.

• Threads built on top of the work of Instagram and other FB engineers. Since X/Twitter is so popular, Threads has built on top of the product-market fit of X/Twitter.

• ChatGPT built upon the work of Google Research and DeepMind.

• Indie hackers built upon their own work, product market fit of others, and acquisitions. For example, Pieter Levels iterated upon his own products until he landed on PhotoAI.

Trust your engineers

Software engineering, in my opinion, is inherently a creative pursuit. Creativity does best under constraints and the constraints here are an end product.

A key commonality was the freedom to succeed through giving autonomy to people on the team.

Thoughts on the future

Necessity through layoffs

Part of the recent focus on “small teams” has come out of necessity with recent tech layoffs.

We’ll probably see more fast-shipping small teams in the future, thanks to AI

AI developer tools, like GitHub Copilot, can sustain huge productivity increases for engineers when used correctly. I think we’ll see more small teams that ship fast as a result.

For anybody working in tech, it’s worth spending time to see how AI can fit into your workflow in a productive manner.

Source: McKinsey (yes, I know. I’m sorry! The chart was useful!)

This is useful because even if you find that AI isn’t good enough yet to help you be more productive, you at least know what to look out for so you can integrate AI into your professional life when it finally is good enough. 

Higher velocity = faster career growth

Code velocity is, in my opinion, the best way to grow as an engineer.

As with anything, the more effective reps you do of something, the better you get at it.

Source

Smaller teams usually provide this opportunity. In a way, I think the best engineers seek out teams with momentum, and as a result of their own ability, they provide the team with more momentum. It becomes a cyclic, self-fulfilling prophecy.

As a result, the only advice I can give to ambitious individual contributors (not just software engineers, but designers, product managers, and more), is to try to join a team that ships more. 

This is so useful for not just your own technical growth but also for things like promotion. More “shots on goal” for projects to showcase and problems to solve is just a massive bird in the hand.

Better manager-IC ratios

The “coordination tax” of larger teams and too many managers can be harmful.

I think we’ll see that the most effective teams of the future have a better ratio of individual contributors to managers, at the very least. At the risk of stating the obvious, joining a team with less bureaucracy and meetings just feels better.