essay · team design
Applying SOLID principles to team design
Single responsibility isn't just for classes. When a codebase gets tangled, we reach for architecture principles. When an organisation gets tangled — duplicated ownership, bottleneck teams, "this always breaks because of that team" — we usually reach for a reorg chart. Same instinct, wrong tool.
For the last few years I've been designing squads the way I design code: SOLID as an org design language. It turns out the principles map almost one-to-one — and the failure modes are identical.
S — Single responsibility
One squad, one domain, one reason to change. A squad owning "the policy admin platform" is a god class. A squad owning "quote-to-bind for the PV&T line" has a clear purpose, clear success metric, and a bounded body of code it can actually hold in its head.
O — Open/closed
Squads should be open for extension, closed for modification. New business lines shouldn't require touching another squad's core — they should plug into well-defined extension points (APIs, contracts, config). When a new line of business arrived, the question was "what do we expose?", not "who gets reassigned?".
L — Liskov substitution
Any squad should be replaceable without breaking the system — including the humans in it. That means ownership boundaries that are explicit, documented interfaces, and no invisible tribal knowledge. If a squad's bus factor is one, it has a Liskov violation.
I — Interface segregation
Squads shouldn't depend on things they don't use. Handoffs become narrow contracts: an event, a schema, a SLA — not "talk to Dave". Segregated interfaces are what let five squads ship in parallel without queueing on each other.
D — Dependency inversion
High-level policies shouldn't depend on low-level squads — both should depend on abstractions. Domain squads depend on a platform contract, not on the platform team's internal rituals. That's what makes a conveyor-belt delivery model possible: 3–4 Associate EMs, each owning a domain squad, all depending on shared abstractions instead of each other.
The result: 8–10 releases per client per quarter, shipped in parallel, without the quality cliff that usually comes with growth.
The uncomfortable truth is that org design and system design fail the same way: coupling, hidden dependencies, god objects with too many responsibilities. The fix is the same too — treat teams as systems, and apply the principles you already trust.