The Three Stages of Engineering Teams 📊
A simple framework for structuring growing teams, inspired by Instagram.
Hey 👋 this is Luca! Welcome to a ✨ monthly free edition✨ of Refactoring.
Every week I write advice on how to become a better engineering leader, backed by my own experience, research and case studies.
You can learn more about Refactoring here.
To receive all the full articles and support Refactoring, consider subscribing 👇
Mike Krieger, co-founder & CTO of Instagram, believes there are three major growth stages every engineering team goes through.
He calls them:
Each of them represents a different way to organize teams and engineering work within your company.
Let's see them one by one 👇
🃏 Generalists Stage
This is when you are just starting up and your team is roughly under 10 people.
At this stage you are still figuring out what to build and how to build it. You can't really anticipate what you will be doing, both in terms of tasks and tech you will be using.
For this reason, it is wise to surround you of generalists who are happy to do pretty much anything.
These are curious people — they don't bother about switching technologies, mixing them with no-code tools, and do whatever it takes to deliver the product.
Even more so, they thrive doing it.
On the other side of the spectrum, you probably don't want someone who is heavily invested in some specific technology, as they will try to use it no matter what, because they feel their career depends on it.
Finally, generalists often make for good managers down the line, as they develop systems thinking by working on a wide array of activities.
As a rule of thumb, you should expect everything you build at this stage to be scrapped at some point in the future. This is almost inevitable as you 1) try different things to see what sticks, and 2) you move really fast.
So my advice is:
Don't create premature abstractions that are likely to backfire later.
Make full use of no-code / low-code tools to keep your tech footprint low.
🧱 Platforms Stage
As your team grows, you get to a point where the generalists stage breaks, usually for two reasons:
📣 Communication — in a larger group of people, “everyone does everything” makes it hard to organize work properly.
📚 Skills — tech becomes more complex and it requires specific skills to move forward.
The most natural choice at this stage is to organize your engineering team into layers/platforms based on your stack — e.g. Frontend + Backend.
Separating layers helps to build engineering culture and practices, and slowly makes your team shift from generalists to specialists.
It also allows for an easy chain of reporting where you identify a lead for each layer and make them implement the first management behaviours (e.g. 1:1s).
In a team organized by platforms, complex features are delivered by Feature Teams.
These are cross-functional teams assembled with the purpose of delivering a specific feature, and dismantled later.
My feeling about feature teams is they are a necessary evil in between the generalists and the products stage.
Feature teams have two major pitfalls:
Loose product ownership — being temporary, teams retain little ownership of what they build. This in turn makes it harder to 1) properly iterate on features and 2) develop product expertise over time.
Hard resource allocation — while they are a flexible way to work, they also require continuous negotiation between stakeholders to define what is the best way to allocate engineers.
🧩 Products Stage
At some point, the overhead brought by feature teams becomes unnecessary and it gets more convenient to create stable teams working around different product areas.
This change is enabled by two trends:
👥 Your headcount is larger — so you are physically able to split people into more groups than just layers.
⛰️ Your product gets more stable — so you can identify areas that require continuous work, and you are comfortable in allocating stable resources to them.
With respect to platforms, this organization brings mostly upsides, with a few downsides:
➕ It builds ownership — teams retain strong ownership of their domain and improve their knowledge over time. You are also able to define KPIs and make teams work towards goals, which is great.
➕ Easy work planning — each team is responsible for the evolution of its product area, so there is no more continuous negotiation over who works on what.
➖ Harder to ship cross-team initiatives — since teams are built to be independent, it may become harder to collaborate on a larger initiative that spans multiple teams.
➖ Reporting is trickier — chain of reporting becomes less obvious, as you have multiple ways to organize responsibilities of PMs, tech leads and engineering managers.
This stage is usually perceived like the endgame of engineering teams, and many people I know are anxious about doing it right, and doing it at the right time.
However, my experience is that when the time comes it just feels like a natural step. You will already have people who have been working on an area for some time, and are recognized as experts on that. So product teams mostly formalize what is already implicit.
If it doesn’t feel like a natural improvement, maybe the time isn’t right and you can stay with platforms a little longer.
🌀 Feature Teams vs Durable Teams — if you want to learn more about the differences between feature teams and durable product teams, I wrote a full article about them earlier this year.
📑 How Instagram Co-founder Mike Krieger Took Its Engineering Org from 0 to 300 People — this interview inspired me to write this article. I took many ideas from it and I recommend you to check it out for more great insights.
📹 Life of a Startup CTO — this is a presentation I gave to an entrepreneurship class a few months ago. It builds on the same topics, also discussing your responsibilities as a CTO and the stages of your business.
⭐ Weekly Featured Jobs
Here are the remote engineering jobs featured this week! They are all from great companies and I personally review them one by one.
🆕 Journey — Founding Frontend Engineer — a storytelling tool designed for the internet age.
🆕 A Team — Independent Software Developer ($130-190/hr) — professional network for A-Talent to connect and form full-stack teams.
Companion — Senior Backend Generalist — transformative learning experiences for your dog.
Tidelift — Senior Software Engineer — a managed open source subscription, backed by creators and maintainers.
Everli — Backend Engineer (PHP, Laravel) — get groceries delivered to your home, from all supermarkets.
River — iOS Engineer — a primary and behavioral health plan to deliver real peace of mind.
Candor — Software Engineer, Infra / Backend / Fullstack — the way top tech employees manage their RSUs.
Catawiki — Senior Back-end Developer — the online marketplace with weekly auctions.
Pallet — Full-Stack Software Engineer — infrastructure for modern hiring.
Secureframe — Full-Stack Software Engineer — it helps companies to streamline their security compliance.
Browse many more open roles (or add your own) on the full board 👇
Hey, I am Luca 👋 thank you for reading this far!
Every week I read tens of articles and draw from my own experience to create a 10-minutes advice about some engineering leadership topic.
Subscribe below to receive a new essay every Thursday and put your own growth on autopilot!