The reorganisation made sense at the time. Your platform was growing, and the technical domains within it were specialising fast — cost management, security posture, governance controls, architecture standards. Grouping people around their areas of deepest expertise looked like the right response to that complexity. Most CIOs in the same position made the same call.
What follows is harder to name precisely. Delivery doesn’t collapse — it slows. Cross-team work that used to move in weeks now moves in months. Features that touch more than one discipline queue in three different backlogs. The platform is technically capable of producing what the business needs. The constraint isn’t skill; it’s the seams.
What has happened is that the functional handoff problem — the one the reorganisation was meant to resolve — has been reproduced inside the platform. It’s operating under new labels.
In Brief
- Organising platform teams around cloud disciplines reproduces the functional handoff problem in a new configuration.
- Conway's Law (1968) describes a structural correspondence: systems mirror the communication patterns of the organisations that build them.
- Discipline-based platform organisation creates handoff latency, ownership gaps, and duplicate approval circuits at the seams between teams.
- The structural indicators of delivery performance — deployment frequency and change lead time — are directly determined by handoff count, not expertise depth.
- The constraint is structural, not attitudinal: improving collaboration within the current structure does not resolve what the structure itself creates.
The seam creates the queue
In 1968, Mel Conway observed that organisations which design systems produce structures that mirror their own communication patterns (Conway, 1968). The law is precise: it describes correspondence between communication structure and system design — not a general principle about teams mattering, or a soft suggestion that culture shapes technology. The correspondence is structural.
When platform teams are organised around cloud disciplines, the communication boundaries fall between FinOps and security, between governance and architecture, between each discipline and the teams it nominally serves. The platform’s technical components — cost controls, identity services, pipeline tooling, policy enforcement — reflect those boundaries. A delivery team requesting infrastructure support that crosses two disciplines doesn’t encounter one backlog or one decision point. It encounters the boundary.
The coordination cost at that boundary is specific: handoff latency. A request for a new workload environment needs cost tagging standards from FinOps, security group configuration from the security team, IAM role definitions from governance, and an architecture review before provisioning. Each team holds a piece. No team holds the whole. The delivery team’s wait time is the sum of four queue positions, not one.
The problem isn't the expertise — it's how the expertise is organised
The discipline-based structure is not wrong because cloud specialisation is unimportant. FinOps, security, and governance are serious domains that warrant serious investment. The issue is that practice-area organisation answers the question “how do we grow deep expertise?” rather than “how does the platform need to operate to serve what delivery teams actually require?”
When Skelton and Pais examined what distinguishes high-performing platform organisations from slower ones, the differentiator was not depth of expertise per discipline — it was the degree to which teams were organised around the work that needed to flow rather than around the knowledge domains that contributed to that flow (Skelton & Pais, 2019). A cross-functional team accountable for a platform capability — say, a secure, cost-managed environment provisioning service — holds the authority and the knowledge to move a request from intake to completion without a handoff. A set of discipline teams contributing to the same capability does not.
This distinction matters because delivery teams downstream don’t experience the platform’s internal expertise map. They experience the time it takes to get something done. Forsgren, Humble, and Kim found that deployment frequency and lead time for changes are the most sensitive structural indicators of delivery performance — and both are directly affected by how many handoffs a change must traverse before reaching its destination (Forsgren et al., 2018). The platform’s internal structure is the primary determinant of that handoff count.
The structure doesn't just create delay — it fragments accountability
Handoff latency is the most visible cost. A request that crosses discipline boundaries waits in each queue independently before the next team can begin its portion of the work. The aggregate wait is not the sum of the work — it’s the sum of the waiting.
Ownership gaps form at the seams. When a delivery team’s infrastructure request falls between governance and architecture — as is common with non-standard workloads — neither team is clearly accountable for the outcome. Both teams own their component. The gap between components is owned by the dependency, and dependencies tend to sit until someone escalates.
Duplicate approval circuits compound the wait. A single environment provisioning request can trigger parallel approval tracks in FinOps, security, and governance. Three reviews is three times the wait from the delivery team’s perspective, even if each review is individually reasonable and technically independent.
The fourth cost is the hardest to surface: prioritisation becomes opaque. The delivery team knows what it needs and when. The platform teams each run their own prioritisation process, their own cadence, their own definition of urgency. A high-priority request in one backlog may be mid-priority in three others simultaneously. No individual platform team is making a bad decision; the structure ensures the decisions can’t add up to the right outcome.
Alvarez and Marsal’s analysis of product and platform models identifies cross-functional team accountability as the structural enabler of platform value — the arrangement that converts deep expertise into delivered capability rather than specialist input (Alvarez & Marsal, 2026). Without that accountability architecture, expertise accumulates within disciplines and rarely reaches delivery teams at the speed the business expects.
The constraint is structural, not attitudinal
The natural interpretation of slower delivery is that teams need to collaborate more effectively, or that processes need tightening, or that better tooling would reduce the friction. Those diagnostics can all be true simultaneously while the underlying constraint remains untouched.
Conway’s Law operates at the organisational level. The correspondence between communication structure and system design holds regardless of how skilled the people within each discipline team are, or how committed the heads of FinOps and security are to the delivery teams they support. The structure creates the handoffs. The handoffs determine the queue. The queue determines the pace.
The question worth sitting with is not how to make the current structure collaborate more smoothly. It is whether the current structure is the right one for the work the platform needs to do. Organising around cloud disciplines answers a real question — it just tends not to be the question that determines whether delivery gets faster.
References
- Alvarez & Marsal. (2026). Product and platform models: The operating model enterprises need to scale technology and generate recurring business value. https://www.alvarezandmarsal.com/thought-leadership/product-and-platform-models-the-operating-model-enterprises-need-to-scale-technology-and-generate-recurring-business-value
- Conway, M. E. (1968). How do committees invent? Datamation. https://www.melconway.com/Home/Conways_Law.html
- Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The science of lean software and DevOps. IT Revolution Press. https://www.oreilly.com/library/view/accelerate/9781457191435/
- Skelton, M., & Pais, M. (2019). Team topologies: Organising business and technology teams for fast flow. IT Revolution Press. https://teamtopologies.com/book
