Find the handoff where progress stops
Most engineering managers know this status meeting. A change the customer asked for is “done”. The engineer finished it and moved on. The pull request is green. The ticket says ready for review. And yet nothing has moved for days, nobody is quite sure why, and the account manager wants a date.
When you dig in, the answer usually isn’t that someone was slow. The work fell into the gap between two stages. The next person didn’t know it was theirs, or they opened it and couldn’t act on what they’d been given.
This worksheet is a way to find that gap. It uses six stages and two questions, and it needs nothing beyond the tracker, repository and release record your team already keeps.
Why this matters more with AI in the loop
If your team uses coding agents or assistants, you’ve probably noticed that producing a change got faster while shipping it didn’t, or not by nearly as much. The research so far points the same way. DORA’s 2025 report on AI-assisted software development describes AI as an amplifier of whatever an organization already does well or badly, and found that higher AI adoption is associated with higher delivery throughput and higher instability at the same time. Read DORA’s 2025 report summary. A follow-up DORA analysis of engineers’ own accounts describes where the time goes: what’s saved writing code is often re-spent auditing and verifying it, and much of that load lands on the reviewer. Read DORA on balancing AI tensions.
Madrona’s August 2026 enterprise AI report includes a survey of startup technology and product leaders at its Builders Summit. It’s a small sample from one investor’s community, so treat it as a signal rather than a census. But the pattern matches DORA’s: AI use has spread across the lifecycle, and the leaders surveyed now point to specification clarity and code review as the places where work piles up, not code generation. Read Madrona’s report.
That’s the handoff problem with the volume turned up. When a change is cheap to produce, more of them arrive at validation and review, and every missing owner or missing piece of evidence costs more than it used to.
Two questions at every handoff
At the end of each stage, ask who owns the next action. “Owns” means someone specific will act, and everyone can see who. That can be a named reviewer, an auto-assignment rule, an on-call rotation or a managed queue that someone is accountable for draining. What doesn’t count is a team alias nobody monitors, or “it’ll go out with the next deploy”. A queue can hold work. It can’t act on it.
Then ask what evidence that person needs before they can act. A reviewer needs the acceptance criteria and the validation results. A release owner needs an approval record and a rollback step. If the evidence lives in a chat thread the next owner hasn’t read, the handoff hasn’t happened, whatever the ticket status says.
If either answer is blank, the work is waiting. DORA’s value stream guidance makes the same point: handoffs between teams are a common place for delay and miscommunication, so make the waits visible and pick one constraint to work on. Read DORA’s value stream guide.
The six-stage checklist
Six stages is a diagnostic model, not a mandated workflow. Your team may run validation and review together, bounce between specification and implementation, or ship behind a flag and verify afterwards. That’s fine. The stages are places to stop and ask the two questions. They’re also not the full Blacktops lifecycle, which has eight activities. These six are the ones where handoffs between people most often go wrong.
1. Intent
Done means: the need is stated in the requester’s words, with the outcome and who will confirm it.
Next action: whoever decides scope, usually a product owner.
They need: who is affected, what should become possible, how the result will be checked.
2. Specification
Done means: scope is accepted; acceptance criteria and out-of-scope items are written down.
Next action: the engineer who will make the change.
They need: the criteria, any access or permission rules, open questions.
3. Implementation
Done means: the change exists in a pull request or commit, with tests mapped to the acceptance criteria.
Next action: whoever runs validation, often the same engineer with a pipeline doing the checks.
They need: the change, the list of tests and how to run them.
4. Validation
Done means: checks have run and the results are recorded, including what wasn’t tested.
Next action: the reviewer, or the rule that picks one.
They need: the acceptance criteria, results, the environment used, known gaps.
5. Review
Done means: an authorized reviewer has recorded approval or requested changes.
Next action: on approval, whoever merges and releases, which is the author under continuous delivery and a release manager on a release train. On requested changes, the author.
They need: the approval record, risks noted in review, the rollback step, a change record where required.
6. Release
Done means: the change is deployed to the target and verified there.
Next action: whoever confirms the outcome with the requester, often support.
They need: the version deployed, how to check it, the original request.
Scrum’s Definition of Done does something similar for a whole increment: one shared description of finished, and an item that doesn’t meet it isn’t released. See the Scrum Guide. The checklist borrows that idea for each stage and adds the two questions that turn a stage boundary into a handoff.
Use the stage names your team actually uses. Merge rows, add rows, rename them. The questions are what matter.
A filled-in example
This example is invented. The request, people and pauses are made up to show how the worksheet reads once it’s filled in, and how a change can stall, recover, ship and still leave the customer waiting.
A customer’s account admin asks for an account-wide default time zone for scheduled reports, because reports for their team in Chennai arrive in the middle of the night. Support records the request in the admin’s words and notes that support will confirm the fix with the customer. The product owner accepts a scope: an account-level default that applies to any schedule without its own time zone, editable only by account admins, with per-user overrides out of scope. An engineer picks it up.
Working with a coding agent, the engineer adds the setting and the scheduler change, and writes tests for the admin-only rule and for new schedules picking up the default. One case isn’t covered: schedules that already exist. The scheduler stores each job’s next run time when the schedule is created, so changing the default won’t move reports that are already queued unless those rows are recomputed. The engineer notes this in the team chat as “probably needs a backfill, can discuss”, marks the pull request ready and assigns it to the team’s review alias.
| Handoff | Who owned the next action | What they had |
|---|---|---|
| Intent to specification Clear |
Product owner | Request in the admin’s words, affected accounts, who confirms |
| Specification to implementation Clear |
Named engineer | Criteria, admin-only rule, out-of-scope note |
| Implementation to validation Clear |
Same engineer; CI ran the checks | Change, test list |
| Validation to review Stalled |
Team alias; no assignment rule, nobody watching | Criteria and the existing-schedules gap, in chat only |
| Review to release Clear |
Release owner | Approval record, version, rollback step |
| Release to confirmation Delayed |
Nobody named to tell the customer | Version deployed, deployment window |
Here’s how it played out. The pull request sat on the alias. Nobody was assigned, no rule assigned anyone, and nobody’s week included “watch the alias”. It stayed there until the engineer asked at standup whether anyone had looked at it. A reviewer picked it up, then asked for the acceptance criteria and whether the existing-schedules question had been settled. Both were in the chat thread. Once the criteria were attached to the pull request and the product owner agreed the backfill was in scope, the engineer added a one-off migration with a test for it, the review went through, and the change was approved and deployed in the next release window.
So the change shipped. But nobody had been named to tell the customer. Support found out from the release note, and the customer heard about a fix that was already live. One stall, one recovery, and one delay after the work was finished.
Two things are worth noticing. The stall at review wasn’t a capacity problem; a reviewer was available once anyone knew to look. And the missing test wasn’t carelessness; the engineer spotted the gap. It just wasn’t written down anywhere the reviewer would find it.
Google’s engineering guidance on code review describes the same gap from the reviewer’s side: slow reviews hold up the whole team, and a reviewer who can’t act soon should say when they can, or hand the review to someone who can. Read Google’s guidance on review speed. Either answer keeps the work owned.
Two blanks, two fixes
When the owner is blank, decide who acts at the moment you mark the stage done. Some stages already have mechanisms for this. On GitHub, a CODEOWNERS file requests review from the users or teams listed for the files a pull request touches. See GitHub’s code owners documentation. If it lists a team, pair it with an assignment rule or a rotation so a person ends up on the hook. Otherwise you’ve automated the alias. For stages your tools don’t cover, the fix is usually a required field on the work item: nobody can move it to “ready” without saying who it’s ready for.
When the evidence is missing, attach it to the work item rather than describing it in chat. For the review handoff, that’s the acceptance criteria, the validation record and the list of what wasn’t tested. For the release handoff, it’s the approval, the version and the rollback step. Chat is where evidence gets discovered. It’s a poor place to store it.
What a blank doesn’t tell you
A blank owner or missing evidence is a finding, not a diagnosis. Three different problems look alike from the outside.
- Ownership. Nobody knew the work was theirs. Naming someone, or a rule that names someone, fixes this one.
- Capacity. Someone knew and couldn’t get to it. A named reviewer with no time still stalls, and naming a second reviewer doesn’t create hours. You have to move load, or change what a review requires.
- Validation quality. The owner had evidence and it wasn’t good enough: tests that skip the risky path, results from the wrong environment, a gap nobody wrote down. Attaching more documents doesn’t help. The validation itself has to improve.
The checklist finds the first two reliably, and the third only when someone recorded the gap. DORA’s guidance on change approval is relevant here: review by peers close to the work, backed by automated checks, beats distant approval gates. Read DORA’s guidance on change approval. That only holds when the peer has what they need, and the time to look.
Run it on one change
Pick one change. The best candidates are a change that’s stalled right now, one that shipped late, or one that just completed while the people involved can still reconstruct it. Book a short session with the engineer, the reviewer and whoever handled the request.
Fill the table from records where you can: the work item, the pull request, the pipeline run, the release log. Where there’s no record, write “unknown”. An unknown owner is itself a finding.
You’ll probably find more than one blank. Don’t automatically fix the first one. Ask which blank cost the most, in waiting, in rework or in customer impact, and whether it’s likely to recur. Fix that one: decide who names the next owner and what that owner receives, then apply it to the next comparable change. Afterwards, check whether the wait at that handoff shrank and whether anything downstream got worse.
Four intervals worth watching
You don’t need a metrics program to see whether a handoff is improving. Four intervals, taken from timestamps you already have, cover most of the checklist.
| Interval | What it covers |
|---|---|
| Time to first review | From “ready for review” to the first substantive reviewer action. The validation-to-review handoff. |
| Time waiting for approval | From first review action to approval. Reviewer capacity, and how often evidence has to be chased. |
| Merge to deploy | From merge to running in production. The release handoff. |
| Release to customer confirmation | From deploy to the requester being told. The handoff everyone forgets. |
Look at each interval per handoff rather than at one overall lead time, because the single number hides which gap moved. A handoff that starts with an owner and the right evidence should be cheaper, and DORA’s guidance on working in small batches notes that the fixed cost of a handoff is what pushes teams toward large batches, which lengthen the time to feedback. Read DORA’s guidance on small batches. Cheaper handoffs let work move in smaller pieces.
Where Blacktops fits
Everything above works in a spreadsheet, and that’s a fine place to start.
Run the checklist a few times and a pattern shows up. The fixes are mostly about context travelling with the work: the request in the customer’s words, the accepted scope, what was tested and what wasn’t, who approved, who needs to be told. In most teams that context is spread across a tracker, a repository, a pipeline, a chat tool and someone’s memory, and every handoff is a chance for a piece to fall out. Agents writing more of the code make this harder, not easier, because the volume goes up and the person reviewing has less first-hand context than whoever, or whatever, wrote it.
Blacktops is the Agentic SDLC Platform for exactly that problem. It keeps customer intent, agent work, engineering workflows and delivery connected in one place, so evidence accumulates on the work item instead of around it, routine handoffs happen by rule instead of by reminder, and the decisions that need a human, such as scope, acceptance and release, reach a named person with what they need to decide. We call the operating model Continuous Agentic Software Delivery™, or Blacktops CASD™: people decide, agents do the work, and nobody has to reconstruct the context at the next handoff.
Run the worksheet first. If the same blank shows up twice, that’s what Blacktops is for.
Use the checklist on one recent change.
Related: Why faster coding can still leave a slow release, the first article in this series, follows one customer request to find where it waits.
Continuous Agentic Software Delivery, CASD and Blacktops CASD are trademarks of Blacktops, Inc.