October 6, 2025
Delivery 360 — Pillar 4 of 5
Welcome to this fourth post in our series on the pillars of our Delivery 360. The Delivery 360 is an independent, evidence-based diagnostic that investigates the full system around technology delivery — not just engineering in isolation. It aims to provide a clear picture of where the issues sit, why they exist, and what to do about them. The Delivery 360 assesses across five key pillars: Identity & Direction; Intelligence & Adaptation; Control & Optimisation; Coordination; and Operations.
In this pillar we look at Coordination in the organisation to assess the shared infrastructure that allows multiple teams to work in parallel without destructive interference. We are getting into the weeds of how teams and processes work together and the mechanisms through which delivery and the organisation stays coherent. When all of this works well, teams move independently and fast. When they don't, coordination becomes the work and the actual work slows down.
As we've said previously, we draw much inspiration from the Viable System Model for organisation analysis. In this system the Coordination function covers the set of mechanisms that prevent parts of a system from oscillating destructively against each other. In a technology organisation, this is the difference between ten teams that work well together and assist each other's progress and ten teams that spend most of their time managing dependencies, resolving misalignments, and rebuilding what another team just changed.
Coordination failures are particularly insidious because they are easy to misattribute. A feature may miss its date due to an undiscovered dependency. Diagnosis: engineering is slow. A product launch fails because sales were briefed too late. Diagnosis: marketing didn't deliver. A new engineer takes three months to become productive. Diagnosis: onboarding is a problem. In each case, the real cause is structural: an absence of the shared language, process, tooling, or ownership clarity that would have allowed the teams to function better. And these failures get worse with scale. A two-team organisation can coordinate informally; a twenty-team organisation cannot. The organisations we see failing hardest at coordination are almost always ones that grew quickly and assumed informal mechanisms would scale with them. They don't.
When we look at Coordination, we typically analyse across five dimensions, each addressing a different layer of the coordination challenge: Process & Ways of Working; Tooling; Cross-functional Collaboration; Team Structure, Topology, & Cognitive Load; and Design & Experience Capability.
The diagnostic question: Is work structured, sequenced, and governed consistently across the delivery system, and do rituals and cadences create coordination without waste?
Process is the most visible coordination mechanism, and the one most organisations believe they have adequately addressed. They usually have something. The important question is whether it functions as designed, and whether the function it provides is genuine coordination or just the appearance of it.
When we look at technology companies we look for maturity levels in process and ways of working. At lower maturity levels, teams improvise. Rituals may exist on paper but are absent or performative in practice. There's the standup nobody really believes in. The retrospective that generates discussion but no actual action. The planning session that produces a list of tickets rather than a commitment to an outcome. Or work goes through ad hoc requests or personal relationships. And new joiners learn the process by asking colleagues, which means what they learn varies by who they ask.
In more mature organisations, process is not only documented but followed and effective. Teams describe ceremonies as useful and not as overhead. Planning produces an explicit commitment to an outcome. Retrospectives drive actual changes. And those changes are tracked to completion. Process effectiveness is measured through sprint goal achievement, lead time, and flow efficiency. Cross-team syncs are cadenced and produce decisions, not just updates.
At the highest levels, process is self-improving. Teams initiate changes to their ways of working based on their own data, without being directed.
One of the most common findings in our reviews is "process as compliance." That is, organisations have implemented an Agile framework primarily as a management reporting mechanism and to impose process adherence without true process value. Teams follow the ceremonies because they are required to; but they do not believe the process helps them deliver better. This is detectable in the interviews. Teams that describe ceremonies as useful are in a fundamentally different place from teams that describe them as overhead.
What we look for in the evidence
When we're looking at process we're looking for clear signals that answer clear questions:
The diagnostic question: Does the tooling stack support visibility, coordination, and delivery performance? Are tools actually used as intended, producing reliable results and data that inform decisions?
Tooling is the infrastructure of coordination. When it works, it makes the state of work visible to everyone who needs to see it without requiring anyone to ask. When it doesn't, coordination reverts to informal channels and the data it was supposed to produce is either absent or unreliable.
The most common failure we see is not absence of tooling but inconsistency of adoption. In immature teams, Jira exists; half the teams use it as intended and half have developed their own workflows that technically comply but produce data that cannot be compared or aggregated. The result is shadow tracking: parallel spreadsheets, Notion boards, and personal task lists that duplicates what the official tool is supposed to capture. When engineering leads keep a spreadsheet of actual capacity because the tool does not reflect it, decisions get made on the spreadsheet, and the tool becomes a reporting artefact rather than a working system. In this case, governance is operating on one person's musings.
At higher maturity levels, tooling configuration is standardised across teams. Key delivery data is accessible to Product Managers and leaders without engineering mediation. Shadow tools are identified and eliminated. Tool adoption is actively measured. If a significant number of teams are not using the agreed workflows, delivery data is unreliable.
At the highest levels, tooling data flows into commercial and product decisions. Delivery performance data informs roadmap sequencing, release timing, and investment reporting. And the introduction of new tools follows a defined evaluation process; existing tools are sunset before new ones are introduced.
What we look for in the evidence:
When we are looking at tooling we look for clear signals:
The diagnostic question: Do product, engineering, design, commercial, and operational functions work effectively together, with clean handoffs, shared goals, and are the right interaction modes applied across team boundaries?
Cross-functional collaboration is where coordination failures become most visible commercially. When design is brought in after decisions are made, the product looks polished but does not solve the right problem. When sales teams are surprised by launches, adoption suffers because the go-to-market was not ready. When data, customer success, or commercial functions have no defined touchpoint in the planning cycle, the feature is built without the necessary inputs that would have made it more successful.
The fundamental issue we see in weaker and lower maturity organisations is a default to one interaction mode, open-ended collaboration, for all cross-functional relationships, regardless of whether the work calls for it. This kind of collaboration is appropriate when the problem is uncertain and the right solution is unknown. But it is expensive and slow when the interaction is stable and repeatable.
A well-defined handoff — what is requested, at what lead time, in what format, with what response time — is a much more efficient interaction mode for relationships that have that shape. The 2024 DORA report reinforces this: teams with clearly defined responsibilities and low coordination overhead consistently outperform those where cross-functional interaction is ad hoc.
At higher maturity levels, interaction modes are documented and deliberately applied. For example, the product trio (PM, engineering, and design) co-owns discovery and holds shared outcome goals. Commercial functions have defined touchpoints in the planning cycle. Cross-functional dependencies are resolved at team level without escalating to leadership.
When we are looking at cross-functional collaboration, we're looking for clear signals like:
The diagnostic question: Are teams correctly typed, sized, and structured at the portfolio level? Are team boundaries aligned to the work they own? Is cognitive load actively managed?
This is the dimension that most directly addresses the structural conditions for sustainable delivery. It asks the wether the current structure allows each team to work with sufficient focus and autonomy, or does it force them to manage so many systems, contexts, and dependencies that sustained quality delivery becomes impossible?
Cognitive load is a central concept here. Team Topologies frames cognitive load as being the primary design constraint for team structure, not headcount or hierarchy. When teams are structured around technology layers or project initiatives or ad hoc, rather than stable product/value domains, cognitive load simply accumulates. That is, how much domain, technical, and process “stuff” a team must hold in its collective head to be effective. Every team has a finite capacity to hold context. When a team owns too many services, too many domains, or too many cross-team dependencies, the overhead of managing those relationships crowds out the focused work of building and improving product. The symptoms are familiar: missed sprint goals, quality issues, slow velocity, high turnover. The cause is structural, not motivational.
For low maturity organisations, teams are defined by project or initiative; ownership is transient; dependencies discovered late. For higher maturity organisations team types are defined, service ownership is mapped, and dependencies are visible at portfolio level.
At highest maturity organisations, each team is assigned a type, usually following the Team Topologies model or something like that: stream-aligned team, platform team, enabling team, or complicated subsystem team. Cognitive load is monitored through surveys and service count per team. Team stability is tracked as a delivery input.
When looking at organisations to assess for Team Structure, Topology, and Cognitive Load, we're looking for the following signals:
The diagnostic question: Is product design a first-class capability that shapes what gets built and how it works? Or is it a production service applied after decisions are made?
Design capability is the coordination dimension organisations most commonly either underinvest in or structurally misuse. Underinvestment means there is no dedicated design function, or design is resourced as a single shared designer across multiple teams. This results in design being present as a checkbox, not as a substantive capability. Structural misuse means design does exist and is adequately resourced, but is positioned downstream of decisions rather than upstream of them. It's in the wrong place in the process. Downstream positioning can be particularly expensive because it imposes the cost of design work with few of its benefits. Design brought in after a solution has been decided can improve visual execution and interaction detail. It cannot reframe the user problem, discover that the solution does not match the user's actual behaviour, or prevent the team from building the wrong thing well.
In low maturity organisations, design is a production service. Designers are briefed on solutions rather than problems. UX research may not exist as a practice, or may do so only nominally, but is not connected to decisions.
At higher maturity organisations design is embedded in product teams and involved from problem framing. A design system exists and is actively used by engineering. UX research outputs are documented, shared, and traceable to design decisions. Design debt is tracked and considered in prioritisation.
At highly mature organisations design research influences strategic decisions. Senior leaders can often cite a design research finding that changed a strategic or market positioning choice in the last year. Design and engineering co-own experience quality: neither can declare a feature done if the other has identified a quality issue.
What we look for in the evidence
When examining Design we look for answers to key questions:
Looking at Coordination through the lenses of Process & Ways of Working; Tooling; Cross-functional Collaboration; Team Structure, Topology, & Cognitive Load; and Design & Experience Capability gives us a good understanding of the organisation. The five dimensions in this pillar form a coherent system.
Weakness in any one of these degrades the others. It's obvious but worth saying: a team with strong process but no tooling to make its work visible to adjacent teams is a black box that coordination has to work around. Or a team with good tooling but poorly defined ownership boundaries will have reliable data about work that does not reflect a coherent domain. The dimensions in this pillar reinforce each other, and they degrade together.
What distinguishes organisations that coordinate well at scale is not more process or more meetings. It is clarity: clarity about who owns what, how interaction between teams works, what the tooling is supposed to produce, and what each team's cognitive limits are.
Coordination at scale is primarily an information architecture problem, not a culture problem. It responds to structural interventions much faster than cultural ones.
Next in the series: Pillar 5 — Operations. In this we look at last at operations and the delivery engine itself. That is, how well the engineering system builds and ships, and whether what ships actually reaches users and gets adopted. Read next
A 30-minute call is usually enough to know whether a Delivery 360 would be useful — and what it would look at in your situation.
