What Good Delivery Looks Like

Previously, at Meridian — and why this training exists

Two minutes of context, then the evidence. Meridian Utilities (our fictional regional utility, ~1,400 staff) spent a year modernizing its estate and another season securing it — those stories are the Cloud Modernization and Zero Trust trainings, and nothing here requires them. What that year left behind is this training’s premise: a small, newly-official platform team with a mandate — make good delivery repeatable for every team at Meridian, not just the ones we sat next to. You’re on that team. This training is your year.

And it opens with the question every delivery effort should open with: what does “good” even mean, measurably?

One team, not three — why this training says DevSecOps

Here is the idea to get across to your leadership before anything technical, because in most organizations it is the hard part: development, security, and operations no longer work as serial handoffs across fences. The teams still exist; the fences do not. The old shape — developers write it, a security team first sees it at the end, an operations team runs it and gets paged — produces the failures DORA (the long-running research program that measures software delivery performance) measures: slow lead times (waiting on the review queue), high change-failure rates (the reviewer sees the change too late to shape it), and long recoveries (the people who can fix it are not the people holding the pager).

What replaced it is not a new org chart; it is a shared system. The pipeline templates every team extends (Module 2) carry the security scans and policy gates inside them (Module 3), so “was this checked?” is answered by the template, not by a meeting. Operations stops being a downstream team and becomes the platform team that runs the road everyone drives on (Module 6). Security engineers write the gates and the scan matrix instead of reading every pull request after the fact — and spend the time that frees on the judgment calls and independent reviews that automation cannot make and compliance still requires. And the measure of success is one set of numbers for the whole system — the four keys plus rework, below — rather than each silo’s backlog.

SERIAL HANDOFFS (what leadership usually pictures)
  dev writes -> sec reviews at the end -> ops runs and gets paged
  three queues, three backlogs, "who approved this?"

ONE DELIVERY SYSTEM (what this training builds)
  one pipeline, extended by every team, gates built in, operations
  running the platform it all rides on
  security = templates and policy the code passes through on every
  change (with specialists doing judgment work, not routine review)
  "which gate checked this?" - answered by the template, recorded
  as evidence

The “Sec” in DevSecOps is the name for that shift — security built into the system rather than inspected onto it. It is also why the rest of this training does not have a “security module”: security is in the pipeline templates, the scan matrix, the artifact integrity, and the evidence pipeline, which is where it lives when the silos are gone.

The vocabulary: four keys, plus one, minus the clusters

For a decade the answer has come from DORA’s research program, and its current (2025) report updated the vocabulary in three ways worth knowing cold:

THE METRICS  - lead time for changes        (commit → production)
             - deployment frequency
             - change failure rate
             - failed-deployment recovery time
             + REWORK RATE (added 2024, kept): the share of deployments
               that are unplanned fixes for user-facing bugs - the
               honesty metric for AI-era volume

THE GROUPING - the old elite/high/medium/low clusters are GONE from
               the presentation;
               DORA now describes SEVEN TEAM PROFILES ("harmonious
               high-achievers" ... "legacy bottleneck") - teams are
               shapes, not ranks

THE REPORT   - the annual report itself was retitled "State of
               AI-assisted Software Development" - the research
               program's center of gravity moved to AI's effect
               on delivery

Why the additions matter: rework rate exists because generating code got cheap — a team can look faster while quietly re-shipping the same feature three times. And the profile model exists because “be elite” turned out to be less useful advice than “you have a specific dysfunction shape; here is its name.”

The finding that frames this whole training

DORA’s current numbers: about 90% of developers now use AI at work. In 2024, AI adoption correlated with worse delivery throughput and stability. In the current research, throughput has flipped positive — but stability is still negative: teams ship more with AI and break more, unless something else absorbs the speed. That something is the finding:

AI is an amplifier. It magnifies the strengths of strong delivery systems and the dysfunctions of weak ones. The returns come from the surrounding system, not the tool.

DORA even names the capabilities that determine which way the amplifier points — and three of the seven are the least glamorous items in this curriculum: strong version control practice, working in small batches, and a quality internal platform. Read that list again as a syllabus: it is the argument that foundations training matters more in the AI era, not less — which is exactly why this course exists and why its modules are ordered the way they are.

One more number to keep you honest, from the sharpest experiment run on this question: a randomized trial by METR of experienced open-source developers found them 19% slower with AI assistance while estimating themselves 20% faster. Perception is not measurement. Lesson 6.2 builds the measurement; until then, distrust vibes — including your own.

Prompt first: the self-assessment

Assess our team against DORA's AI-era capability list. For each — clear AI
policy, healthy data ecosystem, AI-accessible internal data, strong version
control, small batches, user-centric focus, quality internal platform —
rate us strong/mixed/weak with one sentence of EVIDENCE from our actual
repos and processes (branch lifetimes, PR sizes, revert frequency, platform
docs), not from aspiration. Then: which ONE capability, if improved, would
most change what AI adoption does to us? That answer is our starting point.

Run it on a real team - your own - and keep the output (Meridian’s version reappears as a worked example through the coming modules) — Lesson 6.2 turns it into a measured baseline, and the modules in between fix what it finds. For most teams the “which one” answer lands on version control discipline or batch size, which is convenient: that’s the very next lesson.

Key takeaway

Good delivery has a current, measurable vocabulary — four keys plus rework, read as a team profile, not a rank — and the defining current (2025-report) finding is that AI amplifies whatever delivery system it lands in. Three of the seven capabilities that decide the amplifier’s direction are classic foundations: version control, small batches, a quality platform. And the organizing idea under all of it: one delivery system, not three silos — which is what the Sec in DevSecOps names. That’s the course. Next: the trunk.

LEADERSHIP DECISION   fund one delivery system - a platform team owning the
                      shared templates and the gates inside them - instead
                      of three siloed teams and a review stage at the end
PRACTITIONER ACTION   run the DORA self-assessment on a real team; find
                      which capability (version control, small batches, a
                      quality platform) most changes what AI does to you
SUCCESS MEASURE       lead time and recovery time improving on one shared
                      dashboard (calendar time); findings first seen at a
                      pre-release review trending to zero (audit findings
                      avoided)