Most orgs staff these as two teams with two backlogs and two sets of OKRs. They're not two disciplines. They're the inner loop and the outer loop of a single delivery system — and when one outruns the other, the seam always shows, usually at 2 a.m.
Developer Experience asks: how quickly can someone go from idea to running code on their machine, with confidence it'll behave the same way in production? DevOps asks: how quickly can that code go from commit to production, with confidence it'll behave the same way it did on their machine? Read those back to back. It's the same question, asked from opposite ends of the pipeline.
Split them into separate org charts and you get two teams optimizing two halves of a loop that only works when it closes. The platform team ships a beautiful golden-path CLI that generates services nobody's pipeline actually deploys the way the generator assumes. The SRE team builds a bulletproof deploy pipeline that developers route around because the local dev loop is too slow to trust it. Neither team is wrong. The boundary between them is wrong.
Zoom out and every delivery pipeline is one continuous loop that developers experience as two: a fast one they run themselves, and a slower one that runs on their behalf. DEX owns the felt experience of the first. DevOps owns the mechanics of the second. The feedback that flows between them is the only thing that makes either one trustworthy.
Owned by: DEX / platform tooling
Owned by: DevOps / SRE
A slow, untrustworthy inner loop pushes developers to skip it and lean on the outer loop as their real test suite — CI becomes the place bugs are found for the first time, not confirmed. A rigid, opaque outer loop pushes developers to over-trust the inner loop — "works on my machine" becomes a shrug instead of a red flag. Either failure mode looks like a culture problem. It's almost always a loop-design problem.
Push either discipline forward without the other and you get a specific, recognizable failure pattern — not a vague "misalignment," an actual symptom you'll see in the next sprint.
DORA measures the outer loop. SPACE measures the inner loop. Track only one family and you'll optimize your half of the system straight into the other half's blind spot — the bridge is reading both together and asking what the gap between them is telling you.
High deployment frequency with falling satisfaction scores isn't a win — it's a team shipping fast on fumes. Rising satisfaction with a flat or worsening change failure rate isn't DEX succeeding — it's a nicer cockpit on the same unreliable plane. Read one family without the other and you'll miss exactly the failure this whole piece is about.
Not a reorg. A handful of decisions that treat the loop as one thing owned jointly, with one team accountable for the whole path from keystroke to production signal.
The scaffold a platform team ships and the pipeline that deploys it are designed by the same review, in the same sprint — not a tooling team's output thrown over a wall to an ops team to wire up later.
A queue of "help me deploy" requests closed quickly is a platform quietly failing — the metric that matters is how many teams stopped needing to ask.
A Terraform module with no sane default is a DevOps artifact wearing DEX debt — someone will still need tribal knowledge to use it safely.
Alert fatigue, missing runbooks, and unclear ownership are developer-experience failures that happen to surface during an incident instead of during a sprint.
Removing the approval gate before the golden path is trustworthy doesn't create autonomy — it just moves the failure from a review comment to a production incident.
Every DEX win that isn't backed by outer-loop reliability is theater. Every DevOps win that isn't felt in the inner loop is a pipeline nobody trusts enough to use as designed. The two disciplines aren't competing for the same budget — they're two instruments reading the same system, and the gap between their readings is the most honest signal a platform team has.