Delivery debt
Delivery debt is the umbrella term for the accumulated friction in a software-delivery organisation's ability to ship — encompassing technical debt (debt in the code), process debt (debt in the team's working agreements and tools), and decision debt (debt in the architectural and product choices that no longer fit). Each component compounds independently; the three together set a ceiling on a team's effective delivery velocity that no individual remediation can lift.
The named concept exists because the industry has historically discussed only technical debt — the kind that lives in the code — while empirically the other two categories often dominate. Process debt (Stride's prior research) describes ritual structures, on-call rotations, and estimation practices that no longer fit the team. Decision debt is the older but less-named cousin: an architecture decision made under different constraints, a product positioning chosen for a different market, a hiring profile that fit a previous stage. Treating any one in isolation produces incomplete remediation: a team that pays down technical debt but leaves process debt and decision debt still hits the same delivery ceiling, blamed on different proximate causes each quarter. Delivery debt is the framing that lets a team see the three together. The diagnostic move is a delivery-debt audit: rank the top items in each of the three categories by their compounding cost, then prioritise across categories rather than within. Stride's recommended cadence is annual; teams that try quarterly tend to thrash on small items rather than address the structural ones. Adjacent concepts: tech-debt-quarter (an anti-pattern that addresses one debt at the expense of the others), the SPACE framework (an operational measurement that surfaces all three indirectly), the Westrum cultural typology (predicts which orgs can address delivery debt at all).
Related terms
- Technical debt
Technical debt is the accumulated cost of shortcuts taken during development — code that's harder to change than it should be, missing tests, outdated dependencies, or architectural choices that no longer fit.
- Process debt
Process debt is the accumulated friction from team processes that no longer fit the work they govern — sprint structures that produce overcommitment, retrospectives that surface action items without follow-through, on-call rotations that never get re-tuned, estimation rituals that produce false confidence.
- Connected delivery graph
A connected delivery graph is a unified data model in which every artefact of software delivery — initiatives, PRDs, ADRs, stories, acceptance criteria, code commits, test cases, test runs, defects, deployments, incidents — is a typed node with explicit edges to the other nodes it depends on or is depended on by.