This is an opinionated blog post about my experiences with scaling engineering teams, and my preferences for each level of the scale-up journey. All CTOs are different, and the scaling journey will always reflect the CTO, the company, and what they are developing, so this post is not intended as immutable laws, but merely as inspiration.

Level 1: One Team

My rule of thumb is to have a single engineeering team for as long as possible. In practical terms, this means as long as there are less than 10’ish members of the engineering, I keep it as one team. The reason is to avoid the overhead of having multiple teams and to maximize the benefits of smallness (low overhead, instant communication, fast decisions) for as long as possible.

I don’t really think too much about defining leads or other roles at this level, and I strongly prefer Full-Stack Engineers (or Full-Stack Product Engineers), rather than front-end or back-end developers, simply to be able to move as fast as possible.

Level 2: Multiple Teams

As some point at the end of seed funding or start of Series A, the number of engineers in the SaaS will exceed 10 people, and one needs to start to think of having multiple teams.

My strong preferen here is to use Product Teams, rather than Technology Teams, to align the teams with the product portfolio and with what’s important for the business. For example, I’d prefer to have a car booking and billing team, rather than a frontend and backend team.

It’s kind of like when Uncle Bob talked about Screaming Architecture (in his fine book, Clean Architecture), meaning that when you look at the architecture you should know whether it the architecture for a social media platform, a car rental service, or computer game. I think it’s the same when it comes to team structure: the org chart should scream what this department is developing, not what technologies are used.

Level 3: Team of Teams

At some later point in the scale-up journey, the company may reach a size (in the ballpark of around 100’ish members of engineering) where all teams cannot report directly to the CTO and you need another organizational layer.

For this I much prefer some variation of the so-called Spotify model where related product teams (squads) are group into tribes — and avoid things like SAFe and related methodologies favored by non-technical CTOs. Again, to minimize bureacracy, align the teams with the business success, and maximize speed.

Now, what are your experience with scaling engineering teams? 🚀