Quality does not usually collapse. It drifts.
One team adopts a slightly looser review standard. Another stops writing tests for a client who pushed back on timelines. A third builds a deployment process that only one person understands. Six months later you have four teams producing four different standards of work under one brand, and the client who got the weakest one does not care which team it was.
Here are eight practices that hold quality steady across multiple delivery teams, grounded in what the delivery research actually supports. Rise92 works with delivery organisations on the staffing side of this problem through curated sourcing.
The eight, in short
| # | Practice | The drift it prevents |
| 1 | One definition of done, centrally owned | Teams quietly redefining acceptable |
| 2 | A non-negotiable engineering baseline | Standards varying by client pressure |
| 3 | Identical metric definitions across teams | Dashboards that cannot be compared |
| 4 | Comparing teams to themselves, not each other | Wrong conclusions from blended data |
| 5 | Measuring consistency, not only speed | Unpredictable delivery hiding inside good averages |
| 6 | Cross-team review rotation | Isolated teams developing local habits |
| 7 | Seniority ratio protected per team | The team that quietly has no senior review |
| 8 | Watching for AI-driven throughput masking decay | Metrics improving while quality falls |
1. Own the definition of done centrally
The most common source of variance is that each team has quietly built its own understanding of what finished means.
What a central definition covers:
- Test coverage expectations, stated as a threshold rather than an aspiration
- Code review requirements, including how many approvals and from whom
- Documentation that must exist before a ticket closes
- Security and accessibility checks that are not optional
- What gets demonstrated to a client, and in what state
The rule that makes it hold: the definition is owned by one person or group across the organisation, not negotiated per engagement. Client pressure is precisely the force that erodes it, which is why the authority to change it cannot sit with the team under that pressure.
The practical test: ask three team leads what done means on their current project. If you get three answers, you do not have a standard; you have a preference.
2. Set an engineering baseline that does not move
A definition of done describes the output. The baseline describes the machinery that produces it.
| Baseline element | What it prevents |
| CI pipeline, identical structure across teams | Each team inventing its own release process |
| Automated test suite as a merge gate | Coverage decaying under deadline |
| Linting and formatting enforced automatically | Review time spent on style rather than logic |
| Branch and merge policy | Inconsistent release behaviour |
| Dependency and vulnerability scanning | Security debt accumulating unseen |
| Deployment automation | Knowledge concentrated in one person per team |
Why automation matters more than policy here: anything enforced by a human gets negotiated away under pressure. Anything enforced by a pipeline does not.
Where investment pays off most: strengthening automated test coverage improves several delivery measures at once, including how quickly you can identify which change caused a failure. It is the single highest-leverage item on the list.
The exception to standardisation: technology choice should vary by client need. Engineering standards should not. Confusing the two produces either rigid teams that cannot serve varied clients, or a free-for-all.
3. Define your metrics identically before you compare anything
Most agencies running multiple delivery teams eventually build a dashboard. Most of those dashboards are not comparable, because each team’s tooling defines the underlying events slightly differently.
The DORA framework, introduced in Accelerate by Forsgren, Humble, and Kim, remains the most widely adopted engineering measurement standard. The core metrics are deployment frequency, lead time for changes, change failure rate, and time to recovery, with more recent treatments adding a rework measure.
The prerequisite everyone skips: consistent definitions across teams and enough historical data to establish a reliable baseline. Without that, the data integrity question sinks the whole exercise, because leaders act on numbers that do not mean the same thing.
What to settle explicitly before measuring:
- When does lead time start, at first commit or at ticket acceptance?
- What counts as a deployment, and does a config change count?
- What counts as a failure, and who decides?
- Does recovery time end at mitigation or at full resolution?
The finding worth building on: DORA’s research consistently shows that elite and high performers have both better change failure rates and faster recovery than lower performers. Speed and stability reinforce each other rather than trading off, which means a team defending slow delivery on quality grounds is usually describing a process problem rather than a tradeoff.
4. Compare each team to itself, not to the others
This is the practice that most agency leaders get wrong, and DORA’s own guidance is explicit about it.
The guidance: metrics should be applied in the context of the specific application or service a team is delivering. Blending metrics across multiple teams or entire organisations is problematic, because context varies between applications, clients, and constraints.
Why this matters commercially: a team maintaining a legacy system for a regulated client will never match a team building a greenfield product. Ranking them against each other produces a league table that punishes the harder assignment and rewards the easier one.
What to do instead:
- Establish a baseline per team, per engagement
- Track each team’s trend against its own history
- Investigate movement, not position
- Reserve cross-team comparison for the standards themselves, which should be identical, rather than for the outcomes, which should not
The one legitimate cross-team comparison: whether each team is applying the same engineering standards. That is a compliance question with a right answer, unlike delivery speed.
5. Measure consistency, not just averages
A genuinely useful refinement, and one most delivery organisations have not adopted.
Research from a group shipping across four platforms found that teams placing in identical DORA tiers behaved very differently downstream. Two teams with comparable deployment frequency and change failure rate can still create completely different experiences for QA and dependent teams, because one ships on a steady cadence while the other releases unpredictably.
The standard metrics cannot distinguish those patterns. The researchers proposed a delivery consistency measure based on the variability of intervals between releases.
Why this matters especially for agencies: your clients experience predictability, not averages. A team that ships every Tuesday is easier to plan around than a team that ships four times in one week and then goes quiet for three, even when the totals match.
The practical version if you do not want a new metric: look at the spread of your release intervals rather than the mean. High variance is a signal worth investigating even when headline numbers look healthy.
6. Rotate reviewers across teams
Isolated teams develop local habits. Some are improvements worth spreading, and some are drift worth catching. You cannot tell which without crossing the boundary.
What rotation looks like in practice:
- A reviewer from another team on a defined proportion of pull requests
- Architecture decisions reviewed outside the originating team before commitment
- Incident reviews written for an audience that was not in the incident
- A standing forum where team leads discuss what changed in their practice
Two benefits beyond quality control: it distributes knowledge, which reduces the risk concentrated in any single team, and it makes the definition of done real rather than theoretical, because someone outside the client relationship is checking it.
The resistance to expect: teams under delivery pressure will describe this as overhead. That objection is itself the signal that the standard is slipping, since the review load is only burdensome when the baseline work is not being done.
Keep it proportionate: cross-team review on everything creates a bottleneck. A meaningful sample catches drift without stalling delivery.
7. Protect the seniority ratio in every team
The structural failure that produces most delivery quality problems, and the one that dashboards never reveal.
How it happens: a senior engineer rolls off to a more demanding engagement. The team continues with four mid-level engineers and nobody explicitly senior. Work still ships, reviews still happen, and standards decay slowly because nobody in the room has the experience to notice what is missing.
What to hold constant:
- A named technical owner on every team, with actual authority over the standard
- A minimum senior presence per team, defined explicitly rather than assumed
- Review coverage where at least one approver has the depth to catch architectural mistakes
- Explicit handover when senior people move between engagements
Why this is harder than it sounds: senior engineers are the scarcest resource in any delivery organisation and the most in demand across engagements. The temptation to spread them thin is constant, and the cost appears two quarters later in rework.
The commercial consequence: rework is the most expensive thing an agency does, because it is unbillable and it damages the client relationship simultaneously.
The honest constraint here is supply. Maintaining a senior presence across multiple delivery teams means staffing delivery teams with senior depth continuously, and the engineers who can hold that standard are typically employed and not applying anywhere. That is the case for off-market sourcing through closed networks rather than reactive hiring when a gap appears.
8. Watch for throughput gains masking quality decay
The newest risk on this list, and the one most likely to catch agencies out in the next two years.
The pattern: AI-assisted development raises throughput, so deployment frequency and lead time improve on the dashboard. Meanwhile, stability risks rise and technical debt accumulates underneath, and standard delivery metrics cannot attribute any of it.
What the research indicates: the 2025 DORA report on AI-assisted development, based on nearly 5,000 technology professionals, found that delivery metrics alone are no longer sufficient. AI adoption improves throughput but often increases instability when teams lack proper observability. Reported throughput gains sit in a modest range while failure rates and technical debt can move in the wrong direction.
Leading indicators worth tracking:
| Signal | What it suggests |
| AI-assisted pull requests taking longer to review | A delivery bottleneck forming |
| High churn in recently written code | Quality problems surfacing as rework |
| Declining suggestion acceptance over time | Trust or relevance problems |
| Senior engineers increasingly consumed by review | Early warning of burnout and review degradation |
The management response: treat improving speed metrics with more scrutiny than declining ones, particularly when the improvement coincides with tooling adoption. A metric moving in the right direction for the wrong reason is harder to catch than one moving in the wrong direction.
The broader framing: newer measurement frameworks place delivery speed inside a wider set covering effectiveness, quality, and impact, precisely because optimising for speed in isolation creates blind spots.
What this costs to run properly
Quality maintenance across multiple delivery teams has a real cost, and pretending otherwise leads to it being cut first.
| Investment | What it buys |
| Automated test and CI infrastructure | The baseline that survives deadline pressure |
| Cross-team review time | Drift detection before a client finds it |
| Senior presence held in every team | Architectural mistakes caught early |
| Measurement tooling and definition work | Data you can actually act on |
| Standardised onboarding material | Consistent ramp time regardless of team |
The comparison that matters: rework is unbillable, damages client relationships, and consumes senior time that was already scarce. Every item above is cheaper than the rework it prevents.
Where the largest variable sits: the cost of maintaining senior depth across a growing number of teams, which is a staffing economics question rather than a process one. The full cost comparison sits in transparent pricing.
Frequently asked questions
Standardise the inputs rather than the outputs. That means one central definition of done, an automated engineering baseline that cannot be negotiated away under client pressure, identical metric definitions, and cross-team review rotation. Standards should be identical across teams, while delivery outcomes should be compared to each team’s own baseline rather than to each other.
No. DORA’s guidance is explicit that blending or comparing metrics across teams is problematic because application, client, and constraint context vary. A team maintaining a regulated legacy system cannot be fairly compared with a greenfield product team. Track each team’s trend against its own history and investigate movement rather than position.
Change failure rate and recovery time are the stability signals worth watching most closely, since research consistently shows the fastest teams are also the most stable. Add a consistency measure, because two teams with identical averages can create very different experiences depending on whether their release intervals are steady or erratic. Speed metrics alone will mislead you.
Automate enforcement and remove the authority to waive it from the team experiencing the pressure. Anything enforced by a person gets negotiated away on a deadline, while anything enforced by a pipeline does not. Keep technology choices flexible by client and keep standards fixed.
What to take from this
The choice is narrower than the marketing suggests. Establish whether the person is an employee or a genuine contractor, establish whether you own a local entity, and five of the six options usually eliminate themselves.
Then model total cost per country rather than comparing provider fees, because statutory variation dwarfs fee variation.
And keep the sourcing decision separate from the employment decision, because conflating them is how companies end up paying an ongoing percentage for something a one-time arrangement would have covered.
To work through which structure fits your situation, get in touch.
The underlying principle
Standardise what should be identical, and stop standardising what should not.
Engineering standards, the definition of done, metric definitions, and onboarding should be the same everywhere. Delivery outcomes, technology choices, and cadence will legitimately differ by client, and forcing them into a single comparison produces bad decisions confidently made.
The one thing that quietly determines whether any of it holds is whether each team has enough senior depth to notice when the standard slips. Process cannot substitute for that, and no dashboard reports it.
To talk through maintaining senior depth as your delivery organisation grows, get in touch.
