The Three Stages of Engineering Teams

Sign up here for our newsletter on globalization and localization matters.

Mike Krieger, co-founder & CTO of Instagram, believes there are three major growth stages every engineering team goes through.

These are crucial moments in the wider company evolution, and largely match my own experience at a fast-growing startup first, and a larger company later.

He calls them:

1. Generalists

2. Platforms

3. Products

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.

Team

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.

Technology

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 behaviour (e.g. 1:1s).

Feature Teams

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.

Do you want to contribute with an article, a blog post or a webinar?

We’re always on the lookout for informative, useful and well-researched content relative to our industry.

Write to us.