Table of contents
Research context
This protocol asks where onboarding time goes for a new outsourced engineer during the first thirty days. The unit is one new engineer, identified by the start date and the assigned work lane. The study measures time spent waiting for access, setting up the environment, learning the domain, completing a first ticket, and waiting for review. It does not evaluate the engineer's ability or the quality of the hiring decision.
Set the scope to one client team, one engineering lane, and one onboarding plan. Record the repositories, tools, environments, and reviewers assigned at the start. If the plan changes during the window, keep the original definition for the full cohort or analyze the change as a separate period. A new onboarding checklist can look like faster learning when it is only a different form.
Define the population as every engineer who started in the lane during the window and reached the end of the thirty-day plan. The unit is the engineer, not the ticket, because the same person can work on several tasks. An engineer who leaves before day thirty remains in the sample with a termination date and a reason category. A contractor extension is not a new unit.
Record the engineer's prior experience, the assigned mentor, the time-zone overlap, and the access tier. These strata matter because a senior engineer with repository access and a junior engineer waiting for a database account face different delays. Include engineers who joined remotely and those who joined an existing cohort. Test the unit definition on two recent onboarding records before collection begins.
Define access delay as the time from the approved request to the first successful use of the tool. Define environment setup as the time until the engineer can run the application and its tests locally or in a preview environment. Define domain learning as time spent with documentation, walkthroughs, and supervised ticket work. Define first independent ticket as a reviewed change that the engineer completed without taking over someone else's branch.
Do not count waiting for a scheduled orientation as access delay unless the orientation was required before the tool could be used. Do not count a test that passed on someone else's machine as environment setup. A ticket that was reassigned is not a completed first ticket. Each definition should include one positive example and one boundary example so two reviewers classify the same record consistently.
For each engineer, capture the start date, role, prior experience band, mentor, and time-zone overlap. Add the request and approval times for each tool, the first successful command, the first passing test, and the first reviewed ticket. Record the reviewer and the review wait separately. Keep the timeline with the onboarding record so a second reviewer can rebuild it. Use one timeline format for every engineer.
Practical application
Also capture the number of questions the engineer asked and the number that required a client answer. These fields help explain a delay that looks like slow learning but is actually an unanswered dependency. If a question was answered in a call, record the call time and the person who answered. A second reviewer should be able to classify the delay from the timeline.
Draw the sample from the onboarding roster rather than from a list of successful hires. Record the export date, the filters, and the number of engineers excluded. Include every lane and every mentor so the result is not dominated by one supportive manager. If the cohort is ordered by start date, include all engineers in the window rather than a convenience sample.
Collect timestamps from the access system, the repository, and the ticket tracker as they existed on the day. If a mentor recorded a walkthrough in a private note, ask for the date and the topic rather than the note itself. Do not reconstruct a missing timestamp from memory. Note the collection date separately from the onboarding date so the reader can see how much of the record has aged.
A useful additional measure is the share of onboarding time that the mentor spent answering questions that the documentation should have answered. Record the question topic and whether the answer was added to the guide. That view separates a documentation gap from a genuinely complex domain. The owner can then decide whether to fix the guide or change the first ticket.
Report the median and range for each stage: access, environment, domain learning, first ticket, and review. Show the counts by prior experience, mentor, and time-zone overlap. Present the share of engineers who reached a first reviewed ticket within the plan and the share with an unresolved access request. Use the same denominator for every rate and show incomplete records. Show the raw stage times beside the medians.
Inspect the slowest cases and describe which stage dominated without naming the engineer. A delay concentrated in access may point to provisioning, while a delay after the first ticket may point to review capacity. Compare the result with the mentor's other work and the time-zone overlap. Report engineers who left early separately so their partial timelines do not distort the stages.
A useful additional view is the time from the first question to the first written answer. An engineer who waits two days for a domain answer loses more than the answer itself, because the next ticket also stalls. Show the question wait beside the stage times. That view helps the owner decide whether to add office hours, a written FAQ, or a named domain contact.
Operating controls
The review should separate onboarding work from productive work. A first ticket that takes three weeks because it is a critical migration is not a fair measure of onboarding speed. Record the ticket's risk and scope, then compare the engineer's next two tickets. That context prevents the first assignment from becoming a misleading benchmark. A first ticket is a sample, not a verdict.
The record cannot show whether the engineer understood the domain or whether the mentor was effective. It can show only the recorded requests, commands, questions, and reviews. A fast setup is not proof of readiness, and a slow first ticket is not proof of poor ability. The protocol also cannot capture informal help that left no written trace. It measures the recorded process, not the person.
Access systems can omit requests made in chat, and repository logs can miss a local setup that never reached the shared environment. A mentor may have answered questions in a call and recorded nothing. Record those gaps and their treatment instead of dropping them silently. If the mentor also reviewed the first ticket, note the independence limitation and analyze that pair separately.
A useful check is whether the engineer could repeat the setup from the written guide without help. Ask them to follow the guide on a second machine or a clean profile and record where it failed. That test measures the artifact, not the person. A guide that only works with a mentor beside the engineer is not yet an onboarding asset.
Give the result to the engineering lead and the onboarding owner and ask them to choose one observable change. The change might be a pre-provisioned access bundle, a recorded environment walkthrough, a shorter first ticket, or a named domain contact. Record the owner, the effective date, and the measure that will show whether the change worked. Avoid changing the checklist and the first ticket at the same time.
Repeat the protocol with the same definitions for the next cohort and compare the same fields. If access time fell but first-ticket time did not, the bottleneck may have moved to review or domain learning. If first-ticket time fell but rework rose, the first assignment may have become too easy. Close the review when the owner accepts the finding and the next cohort is scheduled.
The final view is the engineer's own estimate of where the time went. Ask for a short ranking at day thirty and compare it with the recorded timeline. A mismatch is useful evidence about what the engineer could not see, not proof that one account is wrong. Record the estimate with the timeline. That comparison helps the owner improve the next onboarding conversation.
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?