Table of contents
Research context
This protocol asks how often an offshore release waits on client approval and where that wait accumulates. The unit is one release request, identified by the deployment record and the first approval request. The study measures the time from ready-for-approval to the first reviewer response, from response to approval, and from approval to deployment. It does not evaluate whether the release was technically sound.
Set the scope to one service, one release process, and one approval group. Record the branch protection rules, the deployment calendar, and the approval policy at the start. If the policy changes during the window, keep the earlier definition for the full sample or analyze the change as a separate period. A new required approver can look like a slower team when it is only a different rule.
Define the population as every release request that reached a deployment decision during the window, including requests that were cancelled. The unit is the release request, not the deployment, because a request can be approved and then rescheduled. A second deployment of the same artifact is a new unit. A rollback is a new unit with a link to the original release.
Record the service, the release type, the change size, the requested window, and the approver group. These strata matter because a security release and a routine copy change carry different review expectations. Include releases that were withdrawn, because the withdrawal is part of the process. Test the unit definition on two ordinary releases before collection begins. Use the same categories for every request.
Define ready-for-approval as the time the release owner submits the complete request, not the time the branch was created. Define first response as the first substantive reviewer comment or approval, not an automated check. Define approval as the state that satisfies every required approver. Define deployment as the time the artifact reaches the target environment. Record those four timestamps from one system clock.
Do not count an acknowledgement that does not grant or deny approval as a response. Do not count a request sent to a group as a named reviewer action. A release paused for a missing test should be recorded with the pause and the resume time. Each definition should include one positive example and one boundary example so a second reviewer can apply it consistently.
For each request, capture the release id, service, requester, approver group, ready time, first response, approval time, and deployment time. Add the change size, the number of approval rounds, and the number of missing fields in the first request. Record whether the request arrived during the client's working hours. Keep the timestamp packet with the release record. Store the packet with the deployment record.
Practical application
Also capture the reason for each wait: reviewer unavailable, missing evidence, conflicting change, or deployment platform issue. These fields help explain a delay that looks like approval latency but is actually a release-readiness problem. If a wait was resolved in a chat message, record the message time and the person who answered. A second reviewer should be able to rebuild the timeline.
Draw the sample from the deployment system rather than from a list of late releases. Record the export date, the filters, the row count, and the selection rule. Include requests from every service and every approver group so the result is not dominated by one large release. If the population is ordered by request date, a fixed interval spreads the sample across the window.
Collect the request as it existed at the approval decision, not as it looks after later edits. If the evidence was added after the first response, record the edit time and analyze the first version separately. Do not infer a missing approval from a delayed deployment. Note the collection date separately from the release date so the reader can see how much of the record has aged.
A useful additional measure is the share of requests that were complete on the first submission. A complete request names the artifact, the test evidence, the rollback plan, and the monitoring window. Record the missing fields and the time spent collecting them. That view separates a reviewer bottleneck from a requester-preparation problem. Show the missing fields beside the wait time.
Report the number of requests, the median time to first response, the median time to approval, and the share deployed within the requested window. Show the counts by approver group, change size, and time-zone overlap. Present the share of requests with missing evidence and the share that required a second approval round. Use the same denominator for every rate. Show the request count beside each rate.
Inspect the longest waits and describe which stage dominated without naming the reviewer. A wait concentrated before first response may point to notification or capacity, while a wait after approval may point to the deployment platform. Compare the result with the requested window and the time-zone overlap. Report withdrawn requests separately so their partial timelines do not distort the stages.
A useful additional view is the time between the first response and the final approval. A request that gets a quick comment but waits days for the final signature is not approved quickly. Show the number of approvers and the sequence of responses. That view helps the owner decide whether to simplify the approver group or split the request. Name the approvers in the request record.
Operating controls
The review should separate a client-side wait from an offshore-side wait. A request that is returned with questions and then waits for the offshore engineer to answer is a different bottleneck from one that sits untouched. Record the handoff direction for each wait. That split prevents the team from optimizing the wrong side of the process. Record who held the request at each stage.
The record cannot show whether the approver was thinking about the request or whether the requester was unavailable. It can show only the recorded timestamps and fields. A long approval is not proof of neglect, and a short approval is not proof of a thorough review. The protocol also cannot capture an approval given verbally in a meeting and recorded later.
Deployment systems can omit cancelled requests, edited approvals, and comments from deleted accounts. A request that was reset by a new commit may look longer than it felt. Record those cases and their treatment instead of dropping them silently. If the requester and approver are the same person, note the independence limitation and analyze that subgroup separately. Keep the original request version with the sample.
A useful check is whether the approval requirements match the release risk. A low-risk copy change that needs three approvers may be over-controlled, while a database migration with one approver may be under-controlled. Record the risk tier and the number of required approvers. That comparison helps the owner adjust the policy without guessing. Use the risk tier to set the approver count.
Give the result to the release owner and the approval group and ask them to choose one observable change. The change might be a complete-request checklist, a named backup approver, a shorter approval group, or a scheduled window for low-risk releases. Record the owner, the effective date, and the measure that will show whether the change worked. Avoid changing the checklist and the approver group at the same time.
Repeat the protocol with the same definitions after the change and compare the same fields. If first response improved but final approval did not, the queue may be starting faster without finishing. If approval improved but deployment did not, the platform may be the real constraint. Close the review when the owner accepts the finding and the next sample is scheduled.
The final view is the approver's concurrent queue, including other services and releases. An approver who looks slow on one request may be covering three products. Record the queue size and the requested windows during the wait. That context helps the owner decide whether to rotate approvers or reduce the number of required signatures. Record the next review date with the sample.
Sources
Frequently asked questions
What should happen first?
Begin with a bounded ticket, approved access, explicit acceptance evidence, and a named reviewer.
Who approves production changes?
The client's technical owner keeps final merge and release authority.
Related research
Where does review time accumulate in a distributed engineering team?
What share of outsourced QA defects are reopened after a fix?