On this page
Research context
This protocol asks what knowledge and access actually survive when an outsourced engineer rotates off a codebase. The unit is one handover between a departing engineer and a named receiver. The study measures the receiver's ability to complete a small change, explain the environment state, and name the owner of each open decision. It does not evaluate the departing engineer's performance or the quality of the codebase.
Set the scope to one repository, one team, and one handover period. Record the handover plan, the access model, and the review process in force at the start. If the plan changes during the window, keep the earlier definition for the full comparison or analyze the change separately. A new checklist can look like an improvement in handover quality when it is only a new form.
Define the population as all handovers that started or completed during the window, including handovers that were extended. The unit is the handover, identified by the departing engineer and the receiver. A handover that is paused and resumed remains one unit with a timeline. A second handover for a different repository is a new unit.
The receiver's first independent change should be chosen to exercise the parts of the handover that are hardest to document. A change that touches the build, the tests, and the deployment path is more informative than a text-only edit. Record the time and the help required, and compare it with the estimate in the handover plan. The gap between the estimate and the actual effort is a useful signal.
Record the repository, the receiver's experience, the handover duration, and whether the receiver had prior work in the area. These strata matter because a receiver who already knows the code needs less transfer than one who has never seen it. Include handovers that ended early, because the reason is part of the evidence. Test the unit definition on two ordinary handovers before collection begins.
Define a successful change as one the receiver completes without help from the departing engineer, with tests and a review. Define state knowledge as the receiver's ability to name the environments, flags, scheduled jobs, and open migrations that affect the area. Define decision ownership as a named person for each open item. Each definition should include one positive example and one boundary example.
Do not count a change as independent when the receiver needed a hint about where to start. Do not count a document as state knowledge when the receiver cannot explain the current environment without rereading it. A handover that transfers code but not the reason behind a workaround is incomplete. The coding rules should distinguish a successful transfer from a successful meeting.
Practical application
A handover can look complete while the receiver still depends on the departing engineer's personal relationships with vendors and client contacts. Record the introductions that were made and the ones that were missed. A receiver who does not know who approves a production change is not independent, even if the code is understood. Include the contact map in the handover evidence.
For each handover, capture the departing engineer, the receiver, the dates, the repository, and the areas covered. Add the change the receiver completed, the time taken, the help required, and the review result. Record the environments, flags, jobs, migrations, and open decisions the receiver could explain. Code each field as present, missing, or not applicable.
Also record whether the receiver had access on the first day, whether the access was least-privilege, and whether the departing engineer's access was removed on schedule. These fields help explain a handover that looked complete but left the receiver unable to act. If the receiver needed to contact the former engineer, record the reason. A second coder should be able to classify the handover from the record.
Draw the sample from the handover register and the repository access log rather than from a list of recent departures. Record the export date, the filters, the row count, and the selection rule. Include handovers of different sizes and durations so the result is not dominated by one easy case. If the population is ordered by start date, a fixed interval spreads the sample across the window.
The departing engineer's access should be removed before the first independent change, not after it. If the receiver needs help, the help should come from the team rather than from a former account. Record the removal date and the confirmation, and check for indirect access through shared accounts. A handover that leaves the old account active undermines the whole exercise.
Collect the evidence from the repository, the ticket system, and the access log as they existed at the end of the handover. Do not reconstruct a missing walkthrough from memory. If the receiver's first independent change happened after the window, record it as a follow-up rather than moving the handover date. Note the collection date separately from the handover date so the reader can see how much of the record has aged.
Report the share of handovers where the receiver completed a change independently, the share where state knowledge was complete, and the share where every open item had an owner. Show the counts by receiver experience and handover duration. Present the median time to the first independent change and the number of help requests. Use the same denominator for every rate.
Operating controls
Inspect the handovers with the most help requests and describe where the receiver stopped. A cluster around the build or release path may point to a missing runbook, while a cluster around the data model may point to a missing map. Compare the result with the handover duration, because a longer handover is not automatically a better one. Report the access-removal result separately.
Review the handover again after the first independent release, because the pressure of a real release exposes gaps that a practice change does not. Ask the receiver what they had to look up, who they had to ask, and what they would change in the handover plan. Record the answers and update the plan for the next rotation. The second review is often more valuable than the first.
A useful additional view is the receiver's confidence against the observed evidence. A receiver who says the handover was fine but cannot complete a change without help is a different case from one who says it was difficult and then acts independently. Record both and describe the gap. The comparison should guide the handover plan rather than judge the person.
The record cannot show whether the receiver will remember the knowledge months later or whether the codebase will change in a way that invalidates it. It can show only what was demonstrated at the end of the handover. A successful change is not proof that every area was transferred, and a failed change is not proof that the handover was worthless. The protocol measures a sample of the work, not the whole relationship.
Registers can omit informal conversations, pair sessions, and access that was granted outside the identity provider. A receiver who learned the code before the formal handover may look more successful than the plan deserves. Record those cases and their treatment instead of dropping them silently. If the departing engineer also performed the access removal, note the independence limitation.
Give the result to the engineering manager and the receiving team lead and ask them to choose one observable change. The change might be a required live change during the handover, a named owner for every open item, or an access checklist. Record the owner, the effective date, and the measure that will show whether the change worked. Avoid changing the plan and the access model at the same time.
Repeat the protocol with the same definitions after the change and compare the same fields. If independent changes improved but state knowledge did not, the handover may be too focused on tasks. If ownership improved but access removal did not, the plan may be treating the exit as an afterthought. Close the review when the owner accepts the finding and the next handover is scheduled.
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
How often do outsourced debugging sessions expose production secrets?
How reproducible are bug reports before outsourced triage begins?