Discover more from Engineer’s Codex
4 lessons from software 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.
Bun is an impressive engineering feat. It replaces many parts of the JS ecosystem as a faster drop-in replacement.
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.
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.
I write about outperformance in real-world software engineering every week. Subscribe for free!
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.
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.
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.