As a company prepares to scale-up from a nascent startup, the inevitable question comes to engineering leaders, how do we structure our teams for success? and how do we move faster? A scaling company on first name terms now needs to divide itself in order to conquer. But where do you draw the lines, and what are the tradeoffs in doing so?
Understanding what you need to optimise for will make the decision process easier. Let's consider the options available based on a product focused startup.
Cross functional teams (XF/Squad)
Popularised by the Spotify model cross functional teams optimise for ownership and autonomy, making it possible to focus and go deep in a particular area. Teams will vary in size, usually adhering to the two pizza maxim. Operating vertically a team might focus on a specific verb i.e. "search", "discover", "support" depending on the logical separation of the product domain.
Challenges typically arise in this structure as the product grows in complexity, a couple symptoms can often be identified:
- Team velocity starts to reduce. Technical debt may have accrued, or simply doing what intentionally would not scale is now hurting the team.
- Different problems with very similar qualities begin to be solved in isolation by XF teams (i.e. multiple different implementations for webhooks), meaning more technical overhead and less focus towards product challenges.
If you observe this, it might be the right time to consider introducing a platform team.
Platform teams
The devops movement has made platform engineering a compelling proposition to scale-ups. These teams operate horizontally, and their goal is to accelerate the vertical teams productivity. These teams instil a build once mentality, reducing the complexity and duplication individual teams have to contend with. Standardising the way engineers tackle persistence, communication, storage, monitoring are all candidate areas where platform teams can bring value.
Look for the symptoms described before spinning up a platform team, as timing is crucial. Starting with a reduced scope is recommended, executing on a couple of small wins will build momentum, giving teams time to adapt to a different model of engagement. An embedded model, where platform engineers work directly with vertical teams on particular problems will accelerate building trust and having a closer understanding of team workflows and pain points.
Functional teams
Structuring engineering teams by their functional discipline optimises for technical knowledge sharing, and technical cohesion. This arrangement may result in Frontend/Backend/Data engineers being co-located. PM's typically sit outside of these teams and request shaped product work be resourced/funded. In this structure code quality and technical architecture may improve, at the expense of product ownership. A team may also "spin up" out of the functional teams to deliver a clearly defined workstream, this requires strong stakeholder management. While this structure has fallen out of vogue, it is worth noting.
Adaptability
Any scale-up will experience growing pains, as change is the only constant. Having a means of measuring teams performance will allow engineering leaders to make informed decisions about when to make adjustments.