June 6, 2025
We've just updated our Delivery 360 diagnostic for 2025. We are always evolving but the framework now accounts for two realities that have reshaped technology delivery since we first built it: AI-assisted code generation is now standard practice across most engineering teams, and AI-driven product features have become a primary growth lever for many technology companies. Both change what good delivery looks like, and both create new ways for organisations to misdiagnose their own performance.
Ourfounding argument remains the same.
When technology delivery underperforms, the diagnosis almost always lands in the same place: engineering. Teams aren't shipping fast enough. Quality is too low. The backlog is unmanageable. Leadership brings in a consultant, runs a DORA metrics analysis, and launches an engineering improvement programme.
Sometimes that's the right call. But often, it isn't.
The real problem is that engineering is downstream of almost everything. It sits downstream of product decisions, leadership behaviour, organisational structure, how demand enters the system, and whether teams genuinely understand the problem they're trying to solve. When upstream things go wrong, engineering still absorbs the consequences — but then gets blamed for them.
This is the founding insight behind the Delivery 360, Implement Partners' evidence-based diagnostic of the full organisational system around technology delivery. Its purpose is to help technology organisations improve the delivery of outcomes and the return on their technology investment. It does that by examining 18 dimensions across product, engineering, design, commercial, and leadership as a single connected system. Not because every delivery problem is a leadership problem, but because the evidence consistently shows that most delivery problems have multiple causes, and the most significant ones are rarely where the initial diagnosis points.
This article explains the thinking behind Delivery 360, how it works, and what it produces. It is also the opening post in a series that goes deep on each of the five pillars the assessment covers.
The DORA State of DevOps 2024 report puts a number on the scale of the problem. Only 19% of software delivery teams are classified as elite performers. The low-performance tier has grown to approximately 25%. More tellingly, DORA's own researchers noted "the performance gap between top and bottom teams is widening dramatically."
That growing gap is not explained by engineering skill. The researchers are explicit that metrics do not explain why performance changed or which organisational capabilities need improvement. The metrics describe what is happening at the delivery layer. They say nothing about why.
The why tends to live upstream.
One of the most persistent problems is that organisations misread their own performance. Research suggests nearly 30% of platform teams do not measure success at all, and a further 24% of those that do measure cannot confirm whether their metrics have improved. When visibility is this poor, it is almost inevitable that the diagnosis defaults to the most visible symptom — which is usually engineering output.
This is what DORA describes as the "measurement crisis": the root cause of perceived performance gaps is often the absence of reliable instrumentation, not the absence of engineering capability.
Team Topologies makes the systemic argument explicit. Authors Matthew Skelton and Manuel Pais write that effective delivery "is not just about rearranging product or engineering teams; it is about how entire capabilities support and accelerate value delivery across the business." The book elevates cognitive load as a primary design principle, framing team structure around the question: "what can this team safely hold in its head?" — before considering reporting lines or skills.
Their guidance has shifted from prescribing team types to something more diagnostic and evolving team structures and interactions in response to real flow constraints. That is a systems-thinking argument, not an engineering one. It points directly at leadership, governance, and organisational design as the variables that determine whether engineering can perform.
Delivery 360 is structured around a straightforward premise: technology delivery is not a function, it is a system. For example, product management determines the quality of demand that engineering receives. Leadership either creates the conditions for good work or destroys them. Organisational structure determines whether teams can move independently or spend most of their time navigating dependencies. The commercial reality of pricing, positioning, and retention either informs what gets built or it doesn't. All of these things interact. None can be fully understood in isolation.
The assessment examines 18 dimensions across five pillars, and directionally mapped to Stafford Beer's Viable System Model — the well-established framework for understanding how complex organisations function and adapt. The VSM is not a management trend; it has been used for decades to diagnose why organisations succeed or fail at responding to change.
Each pillar matters independently. But the more important point is that weakness surfaces in others. A product operating model that treats teams as feature factories will degrade engineering performance regardless of how capable the engineers are. Leadership behaviour that creates ambiguity around decision rights will slow down every team it touches. An organisational structure built around three-year-old hiring patterns rather than current product architecture will generate coordination and dependency overhead that no process improvement can fully compensate for.
This is why isolated functional reviews (engineering-only, product-only, process-only) consistently miss the most important findings. They examine one part of a system without accounting for the conditions that part operates in.
At the same time, as we write there is a broader industry shift underway that makes the systemic view more urgent. Organisations are moving away from project-based delivery toward empowered product teams that own outcomes continuously. Success metrics are shifting from features shipped to customer and business outcomes. And continuous discovery and experimentation are becoming the default operating model for product organisations.
This shift has significant implications for how delivery problems should be diagnosed. A team operating in a project-based model with a defined scope, delivering it, and moving can be evaluated primarily on execution. A team operating in an outcome-focused model needs strategy clarity, customer insight, decision-making authority, and reliable feedback loops. If any of those conditions are absent, the team will underperform regardless of its engineering capability. The diagnostic has to fit the emerging models.
The Delivery 360 uses three inputs in combination because each reveals something the others cannot.
Implement Partners uses engineering metrics — change lead time, deployment frequency, failed deployment recovery time, change fail rate, deployment rework rate — alongside flow metrics and capacity allocation data where available. DORA's own research confirms that "speed and stability are not a trade-off: top performers do well across all five metrics, while low performers do poorly across all of them." That means a strong DORA profile is genuinely informative. But it also means that a weak profile tells you what is happening, not why. The metrics are the starting point, not the conclusion.
Interviews span all functions. We talk not just engineering and product, but commercial, HR, sales, legal, and operations aswell. This matters because each function experiences the delivery system differently,. And the most significant signals are usually in the gaps between what different people believe to be true and what it true. Engineering says product decisions are the bottleneck. Product says engineering is slow. Sales says the product doesn't reflect what customers actually need. All three perspectives contain truth. Some truth. The 360n diagnostic maps them into a coherent picture.
Structured surveys gather signal at scale across larger organisations. Desk research allows us to review strategy documents, roadmaps, team topologies, commercial data, product analytics, and architecture decisions. We do this to test whether what people say matches what actually exists. The gap between stated strategy and operational reality is one of the most consistent findings across engagements.
Every dimension is tyoically evaluated on a maturity scale using three triangulation lenses:
This combination is necessary because an organisation can have a process on paper that nobody follows, or a practice that people are confident in but that fails external benchmarking. Both are problems. Both look different from the outside. A single lens — metrics alone, or interviews alone — will miss one or the other.
The result is a scored profile across all five pillars and 18 dimensions, with findings that distinguish causes from symptoms and recommendations that connect back to business outcomes rather than engineering theory.
The Delivery 360 output is not a list of things engineering should do differently. It is a systemic reading of what is preventing the organisation from delivering value at the pace and quality its strategy demands.
That means our findings frequently land in uncomfortable places. For example, we may find that strategy is unclear below the executive level; that product management is operating as a backlog administration function rather than a discovery and prioritisation engine; that decision rights are ambiguous in ways that slow down every team; that team structure reflects three-year-old hiring patterns rather than current product architecture. None of these are engineering findings. They require responses from leadership, from product, from commercial.
The diagnostic produces three outputs:
A scored assessment across all 18 dimensions, with evidence notes and a clear distinction between what is observed, what is inferred, and where confidence is lower. Every score is defensible against the evidence collected.
A synthesis of the three to five systemic themes that best explain the delivery profile with a clear reading of which are structural, which are behavioural, and which are proximate versus root causes. Working across many engagements becomes very valuable for insight: most delivery issues have precedents, and knowing what they typically mean and where they typically lead is something no internal stakeholder can offer.
A prioritised set of recommendations, structured to distinguish what leadership needs to own from what product and engineering need to own, and sequenced by impact and feasibility. Not a 60-point improvement plan. The four or five interventions that will move the system meaningfully.
The Delivery 360 is designed all organisations but we find much benefit for two situations:
This is where leadership suspects something systemic is wrong. That is, value is being left on the table, competitors are moving faster, or the organisation keeps hitting the same performance ceiling no matter what it tries. The diagnostic gives leadership evidence-based picture that no internal stakeholder can produce, because every internal perspective is partial and often adversarial. We are not.
This is where investors or boards need an objective view of the delivery system in order to understand current performance, inform a value creation programme, or establish a baseline before a significant intervention. In this context, objectivity is everything. The value of the diagnostic depends on following the evidence wherever it leads, including to uncomfortable conclusions about leadership, product strategy, or structural decisions that predate the current team.
As we said, this post is the first in a series that goes deep on each pillar and dimensions in the Delivery 360. Each post explains why the area matters, what good looks like, what poor performance typically signals, and what upstream causes we most commonly find. The series is written for senior leaders who want to understand the diagnostic thinking, not just the framework mechanics.
The series will cover:
If your organisation is experiencing delivery pain — slow output, quality problems, misalignment between what is being built and what the market needs, or simply a sense that the engine is not running at its potential — the answer is rarely where it first appears. It is usually in the system around it.
That is what Delivery 360 is built to find. If you want to understand what that looks like in practice for your organisation, get in touch with Implement Partners to discuss a diagnostic conversation.
Alternatively, learn more about the first pillar: Identity & Direction.
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.
