Scaling 20 to 50: Org Design for SaaS Without Silos
Past twenty people, how you arrange teams starts to matter more than who is on them. Structure decides how fast information moves, who owns outcomes and how many handoffs a customer problem needs. This guide compares the common structures and shows how to choose one.
TL;DR
- Structure should follow how customers get value, not the organisation chart of a larger company.
- Conway's law applies: the systems you build will mirror your communication structure.
- Common models are functional teams, product-aligned pods and a hybrid. Each trades specialisation against ownership.
- Every handoff is a cost. Count them for your most important customer journey and remove the unnecessary ones.
- Clarify decision rights and planning cadence before you add layers.
What changes between 20 and 50
At twenty, everyone knows everyone and information flows by conversation. At fifty, it does not. People work on things others do not know about, priorities clash, and customers feel the seams between teams. The question is no longer “who should we hire” but “how should the company be arranged”.
Start from the customer journey
Take your most important journey, such as a new customer signing up, getting onboarded and paying. List every team and handoff it touches. Each handoff adds delay and a chance of misunderstanding.
| Step | Team | Handoff |
|---|---|---|
| Sign-up | Growth | To product for onboarding |
| Onboarding | Product | To success for setup help |
| Setup | Success | To engineering for bugs |
| Billing | Finance | To success for disputes |
If one issue crosses four teams before it is resolved, you have found an organisational problem that no individual can fix. Structure should shorten that path.
The common structures
| Structure | Strengths | Weaknesses | Fits |
|---|---|---|---|
| Functional | Deep expertise, clear careers | Handoffs, slow cross-team work | Early scale, specialised domains |
| Product-aligned pods | Ownership of outcomes, fast decisions | Duplication, uneven standards | Multiple product areas or customer segments |
| Hybrid | Pods for delivery, functions for craft | Matrix confusion if unclear | Most growing SaaS companies |
Matthew Skelton and Manuel Pais’s Team Topologies (2019) offers helpful language: stream-aligned teams that own a flow of work, platform teams that make others faster, enabling teams that help others learn, and complicated-subsystem teams for specialised domains.
Remember Conway’s law
Melvin Conway noted in 1967 that organisations produce designs that mirror their communication structures. If front-end and back-end teams only talk through tickets, expect an interface that feels like a ticket. If a pod owns a customer outcome from interface to database, the system tends to reflect that. Design teams around the architecture and experience you want.
Keep teams small and clear
Amazon’s “two-pizza team” idea is a useful guide: a team small enough to feed with two pizzas, roughly five to nine people. Each team should have:
- A mission written as an outcome.
- A single accountable leader.
- The skills needed to deliver without waiting on others for routine work.
- A few metrics tied to the company’s north star.
Make decisions explicit
Larger organisations fail when nobody knows who decides. Write down decision rights for the common cases:
| Decision | Who decides | Who is consulted |
|---|---|---|
| Team priorities within quarter | Team lead | Product, affected teams |
| Cross-team priorities | Leadership group | Team leads |
| Hiring within budget | Hiring manager | Team, recruiter |
| Pricing changes | Leadership | Product, sales, finance |
Add a planning cadence: quarterly objectives, monthly business reviews and weekly team syncs. Resist adding meetings that exist only to share information that could be written.
Interfaces between teams
Teams will need each other. Define the interfaces:
- Service-style: a platform or data team publishes what it offers, how to request it and how long it takes.
- Collaboration: two teams work closely for a limited time on a shared goal, then separate.
- Facilitation: an enabling team coaches another, then steps back.
Name the interaction type so people know what to expect, and review it every quarter.
Plan the roles you will need
Around 20 to 50, you typically add a layer of managers, someone for people operations, finance beyond bookkeeping and possibly a head of engineering or product. Compare against the moves in scaling from 10 to 20 and the earlier hiring choices in first ten hires. For go-to-market structure, see PLG versus sales-led.
Warning signs
- Customers repeat their story to several teams.
- Teams optimise their own metrics at the expense of the whole.
- Priorities change in each meeting because nobody owns them.
- High performers leave citing politics or unclear ownership.
- Every decision needs a meeting with more than five people.
A staged approach
- Map the key customer journey and its handoffs.
- Choose the simplest structure that removes the worst handoffs.
- Write mission, owner and metrics for each team.
- Document decision rights and cadence.
- Review after a quarter, adjust and avoid re-organising more than once or twice a year.
Reorganisation guardrails
Reorganise rarely and deliberately. Explain the problem it solves, announce who leads what on the same day, keep customer-facing owners stable during the change and measure the original problem again after a quarter. If you cannot name the problem, wait.
Your next step
Pick your most important customer journey and count how many teams and handoffs it crosses. If the answer is more than three, you have found the first thing structure should fix.
Bottom line
Between 20 and 50 people, design the organisation around how customers get value. Count handoffs, choose a structure that matches your products, keep teams small and accountable, and write down who decides what. Structure is a product you iterate on, not a chart you draw once.
Frequently Asked Questions
Should we organise by function or by product?
Functional teams build depth but create handoffs. Product-aligned pods own an outcome end to end but risk duplication. Many companies at this size use pods for product work and functional groups for specialised support.
What is Conway's law?
Melvin Conway observed in 1967 that organisations design systems that mirror their communication structures. If your teams are split in a certain way, your software and your customer experience tend to be split the same way.
How big should a team be?
Small enough to coordinate easily. Amazon's two-pizza team idea suggests roughly five to nine people. The right size depends on the work and the clarity of the team's mission.
What is Team Topologies?
A 2019 book by Matthew Skelton and Manuel Pais that describes four team types (stream-aligned, platform, enabling and complicated-subsystem) and three interaction modes, a useful vocabulary for designing teams and their relationships.
