Operating Models
How an organisation arranges people, ownership and decision rights to deliver and run systems — which determines what architectures are viable.
Definition
The operating model answers: who owns what, who decides what, who runs what, and how work flows between them. It constrains architecture more directly than most technical factors.
The models and what each supports
Centralised functional teams — a development team, a QA team, an operations team, a database team. Every change crosses all of them. Supports large batch releases and defeats flow. Conway's Law then cements it: the architecture develops interfaces mirroring the handoffs.
Project teams — assembled per project, disbanded afterwards. Nobody owns the outcome long term, so maintainability is systematically deprioritised and the operational burden lands on whoever is left.
Stream-aligned product teams — durable teams owning a capability end to end, including running it. Supports independent delivery and requires platform investment to be viable, because each team must otherwise solve every infrastructure problem itself.
You build it, you run it — the strongest version, where the team that builds also operates. The feedback loop between a design decision and being woken by it is what makes reliability an engineering concern rather than someone else's problem.
What makes stream alignment work
- A platform providing self-service capability, so teams are not each solving infrastructure from scratch. Without it, autonomy is just isolation and the cognitive load is unmanageable.
- Bounded cognitive load. A team can own so much and no more. Twelve services across four engineers will be badly operated regardless of the design's elegance.
- Clear ownership, with a named team per service and no orphans.
- Decision rights that match accountability. A team responsible for availability must be able to make the decisions that affect it.
The architectural consequence
Conway's Law is not advice; it is an observation. Systems mirror the communication structure of the organisation that builds them. So either align the organisation to the architecture you want, or accept the architecture your organisation will produce.
Designing a system whose boundaries cut across the org chart is designing something that will be fought by gravity for its entire life.
Failure scenarios
- Microservices with functional teams, producing a distributed monolith with handoffs.
- Project teams building systems nobody will own.
- Stream-aligned teams without a platform, so each reinvents infrastructure.
- Ownership on paper only, with no capacity or decision rights attached.
- Cognitive load ignored, so ownership is nominal.
Interview question
"An organisation with functional teams wants to adopt microservices. What do you tell them?"