The engineering onboarding ramp decision record: why the ramp model you chose determines your time-to-first-contribution floor and your early-tenure retention surface

A 22-person developer tools company building a CI pipeline observability platform hired a senior backend engineer through a rigorous technical process. The engineer had 9 years of distributed systems experience, came from a company the team recognized as having strong engineering culture, had cleared the technical bar by a clear margin on all four dimensions the CTO assessed informally, and had impressed two senior engineers during the interview loop with a system design discussion that produced the most thorough failure mode analysis either engineer had seen from an external candidate. The offer was accepted within two days of issue. The engineering team was growing and under pressure: two senior engineers were each carrying more than their target sprint load, and the new hire was expected to relieve the pressure on the backend infrastructure work within six to eight weeks.

The new engineer's first week involved four introduction meetings, a repository access walk-through by the on-call engineer that week, a brief architecture diagram overview from the tech lead, and assignment to a "starter task" identified by the engineering manager as a good first contribution: a monitoring endpoint enhancement that had been in the backlog for six weeks. The starter task had no written specification — it had been added to the backlog by a senior engineer who understood the surrounding context and had assumed the work would be taken by a team member already familiar with the codebase. The new engineer spent the first week reading code. The second week involved three pairing sessions with different team members on different subsystems, none coordinated into a coherent context transfer arc. By the third week, the new engineer had submitted a pull request on the starter task. It was returned with seventeen review comments that were not quality issues but context issues: the approach had made assumptions about the instrumentation pipeline that were incorrect given how the pipeline had evolved over the prior quarter, and the fix required understanding a refactor the senior engineer had done six weeks before the new hire started, which was not documented anywhere other than in the commit history.

At the six-week mark, the engineering manager's informal assessment was that the ramp was slower than expected. At twelve weeks, the manager had a conversation with the new engineer that framed the pace as a concern. The engineer, who had never received an explanation for why their pace was below the team's expectation or a benchmark for what the expected pace actually was, had spent the preceding six weeks concluding that the role's context complexity was higher than what they could handle independently — a caliber mismatch narrative they had constructed from the absence of explicit ramp structure and the absence of any signal that their pace was context-driven rather than capability-driven. By month five, the engineer had accepted another role. By month six, they had left. The post-mortem discussion framed the departure as a hire that did not work out — the engineer had not met the team's contribution expectations. No member of the team identified the ramp model as a variable. The CTO later described the hire as "a case where someone strong on paper didn't have the right instincts for our systems." The engineer, interviewed at their new company eight months later in a reference check for a different role, described their time at the first company as "the first role where I was set up to fail from the first week and spent six months trying to figure out why." Connect this to the engineering hiring bar decision record: the hiring bar assessed the engineer's capability across four dimensions at an above-threshold level; the ramp model's failure was not visible in the hiring process data and was not visible in the sprint velocity data because "not contributing independently" looks identical whether the cause is a context gap the ramp failed to close or a capability gap the bar failed to detect; an organization without an explicit ramp model that separates context gaps from capability gaps will systematically misattribute ramp failures to hire quality, recalibrate the hiring bar toward a higher threshold that produces stronger on-paper candidates, and continue to lose those candidates to the same ramp model failure — an escalating cycle of bar tightening that selects for candidates increasingly likely to identify the ramp problem and leave faster when they encounter it.

A 31-person B2B SaaS building a contract analytics platform had identified onboarding quality as a growth risk after two sequential new hires in the same year had required more than 4 months to reach independent sprint contribution. The engineering director designed a formal onboarding program: an assigned buddy for the first 6 weeks (a senior engineer rotated quarterly), a first-week orientation series covering the tech stack, architecture, deployment process, and team norms, a 30-60-90 day plan template with goals specified for each 30-day window, a slack onboarding channel where the new engineer could ask questions without interrupt-cost to team members, and a completion checklist that the engineering manager verified at the end of week 4 and week 8. The program was consistently applied across the next 8 hires over 18 months. Checklist completion rate was 100% across all 8 hires — every item in the first-month and second-month checklist was completed on schedule. Buddy assignment was 100%. Every new engineer had a documented 30-60-90 plan within 5 business days of their start date.

At the 18-month mark, the engineering director analyzed time-to-independent-contribution for the 8 hires under the program. Independent contribution was defined as the first 2-week sprint where the engineer closed at least 75% of their committed sprint points without requiring a senior engineer unblock to complete any item. The director had expected a median of 75 days based on the program's 30-60-90 structure and the 2-month target in the program's design rationale. The actual median was 107 days. Four of the eight engineers had not reached independent contribution at 120 days. Two of those four had left within 18 months of hire, both citing "slow start" and "unclear expectations" in exit interviews. The program's 100% checklist completion rate was accurate and simultaneously invisible to the underlying problem: the checklist measured whether the orientation activities had occurred, not whether the orientation activities had produced the context required to work independently. The 30-day checklist included "attended architecture overview session" and "merged first PR with buddy assistance" — both of which could be completed by an engineer with no usable codebase context, because the architecture overview session was a one-hour slide deck that provided a map of the services without the reasoning behind the service boundaries or the operational constraints that governed how they interacted, and the first PR with buddy assistance was assistance-dependent by design, not a signal of independent readiness.

A retrospective analysis of the 4 slowest ramps identified three failure patterns common across all four. First, the architecture overview session provided structural context without decision context: the engineer knew what services existed and how they communicated but not why the service boundaries were where they were, which meant that every task touching a service boundary required discovering the boundary's constraints through trial-and-error rather than consulting documented rationale. Second, the buddy's role was undefined beyond "answer questions" — the buddy did not have a context transfer checklist of their own, did not have explicit sessions on the team's conventions and tacit knowledge, and answered questions reactively rather than proactively surfacing the context the new engineer did not yet know they needed. Third, the 30-60-90 plan's 30-day goals were activity goals ("complete the onboarding checklist items, explore the codebase, attend team ceremonies") rather than contribution goals ("own and close one issue independently, identify one codebase area where the documentation is missing and add it, participate as a reviewer in two code reviews with written comments that the review author finds useful"), which meant the engineer arrived at day 31 having completed the 30-day goals with no practice at the independent contribution mode the day-31 to day-60 goals assumed. The program was redesigned: the architecture overview was replaced with three 45-minute decision-context sessions (why the service boundaries are where they are, what the top-three operational constraints are that govern the team's design choices, and what the top-three codebase areas are where the documentation does not match the current implementation); the buddy role was given an explicit context transfer checklist with 12 specific topics to cover proactively across the first 4 weeks; and the 30-60-90 plan's goals were rewritten as contribution milestones. Connect this to the developer onboarding program decision record: the onboarding program's structure is the delivery mechanism for the ramp; the program can be formally complete and the ramp structurally incomplete if the program's success metrics are activity completion rates rather than ramp outcome measures; the most important design decision in the onboarding program is what the program measures as success — a program optimized for checklist completion will produce 100% checklist completion and variable ramp outcomes, while a program optimized for time-to-independent-contribution will produce lower activity completion rates (because the contribution milestone will sometimes require additional time and sessions not on the original checklist) and a higher fraction of engineers reaching independent contribution within the target timeline.

A 48-person enterprise SaaS building a financial reporting platform had a mature onboarding program for its product engineering teams. The program had been developed over two years and refined through five cohort retrospectives. The milestone structure was concrete and measurable: first independent PR merged in week 1, first issue owned end-to-end without senior engineer involvement by week 3, sprint velocity at 70% of a calibrated senior engineer by week 8, sprint velocity at 90% by week 12. The milestones had been calibrated against the prior 12 engineers' actual ramp trajectories on the product feature teams, and the calibrated benchmarks reflected what was achievable at each milestone with good context transfer — not aspirational targets but measured medians. The program produced consistent ramp outcomes on the product teams: 9 of the last 11 product team engineers reached the week-8 milestone within one week of the target date.

The infrastructure team, which had been growing separately as the company's data processing requirements scaled, needed to onboard two senior platform engineers in the same quarter. The engineering director, who owned the onboarding program, applied the same program to the infrastructure team without modification. The milestone structure was identical. The first independent PR milestone was week 1. The first independent issue ownership milestone was week 3. The infrastructure team's primary surface was a custom data pipeline orchestration system the team had built over 3 years — roughly 40,000 lines of internal tooling for scheduling, monitoring, and recovering distributed batch jobs, with a deployment and testing model that required understanding the orchestration system's state machine before any change could be safely committed. A new infrastructure engineer who had not yet built a mental model of the state machine's transition semantics could not safely produce a first PR in week 1 — not because they lacked the capability to produce a PR, but because any PR in the infrastructure codebase required understanding constraints that typically took 3 weeks to acquire through observation and guided context transfer sessions.

The first infrastructure engineer missed the week-1 first-PR milestone. The ramp check-in at week 2 documented the miss. By week 4, having not yet reached the week-3 independent issue ownership milestone, the engineer received a message from the engineering director describing the ramp trajectory as "significantly behind expectations" and initiating an early-tenure review with a 30-day target to demonstrate sprint independence. The engineer — who was performing at a level fully consistent with what an experienced platform engineer would deliver given 4 weeks of context transfer on an unfamiliar orchestration system — received the review as a performance signal incompatible with how they assessed their own caliber. They escalated to the engineering director's manager. The subsequent investigation revealed that the week-1 milestone had been calibrated against a product engineer's first PR, which was a UI component or API endpoint requiring one to two hours of codebase familiarization, not an infrastructure change requiring three weeks of orchestration system orientation. The two infrastructure engineers completed their ramps successfully after the milestones were recalibrated with a 3-week first-PR target and a 6-week first-independent-issue target. One of the two engineers, having been placed in an early-tenure review that they experienced as a misjudgment of their capability, declined a retention offer 8 months later and left to join a company whose infrastructure team had hired them directly. The departure was logged as a retention miss. The post-mortem attributed the departure to compensation. Connect this to the code review policy decision record: the first-PR milestone is the ramp's earliest concrete contribution signal, and the code review process is what determines whether the first PR produces a useful contribution or a documentation exercise; a code review process that provides explanatory context for review comments — the reviewer explains why the approach is wrong, not only that it is wrong, and where the correct approach is documented or can be learned — accelerates the ramp by converting every review comment into a context transfer event rather than a correction that the new engineer must investigate independently; a code review process that optimizes for comment density or approval speed without explanatory context extends the ramp because the new engineer must reconstruct the reasoning behind each comment through exploration of the codebase rather than receiving it directly from the reviewer who holds the context.

Structural properties set by the engineering onboarding ramp decision

Two structural properties are determined by the founding decisions about ramp model type, milestone structure, context transfer ownership, and ramp variant design. Neither is visible in the sprint velocity data or the checklist completion metrics that onboarding programs typically report until early-tenure attrition rates or senior engineer utilization data reveal that the ramp model's context transfer quality is setting a floor on new hire productivity that the hiring bar's selection quality cannot overcome.

Property 1: Time-to-first-contribution floor. The ramp model determines how quickly a new hire can produce work that requires no ramp support — the threshold below which no ramp investment can push the time-to-contribution regardless of how strong the hire is. A ramp model without explicit context transfer sessions on the team's tacit knowledge — the codebase conventions that are not documented, the architectural decisions that are not in any ADR, the operational constraints that every existing team member holds implicitly and that every new engineer must rediscover through incident or review comment — sets a floor on time-to-contribution that is determined by how quickly a new engineer can reconstruct that tacit knowledge through observation and error. A strong hire with a poor ramp model will reach independent contribution at the same time as a moderate hire with a poor ramp model, because the limiting factor is the context transfer rate, not the engineer's raw capability; the strong hire's advantage over the moderate hire only materializes after the ramp is complete, when the strong hire's problem decomposition depth and operational mindset produce better independent decisions. This means that the cost of a poor ramp model is borne disproportionately on the first 90 days for all hires: the senior engineer support time consumed per new hire during the ramp period — the hours of senior engineers answering context questions, unblocking tasks where the new engineer hit a tacit-knowledge constraint, reviewing PRs where the context gap produced an incorrect approach, and conducting the additional pairing sessions that substitute for structured context transfer when the ramp model doesn't provide it — is the primary measurable cost of the ramp model's design quality, and it is a cost that falls on the senior engineers most constrained by their own sprint commitments. An organization that spends 6 weeks of senior engineer unblock time per new hire on a ramp that should require 2 weeks of structured context transfer is not making a 4-week investment decision — it is making a 4-week per-hire ongoing allocation from its senior engineers' productive capacity, repeated for every hire, compounding as the team grows. Connect this to the engineering career ladder decision record: the career ladder specifies the capability level at which a senior engineer operates independently; the ramp model's first-contribution milestone should be defined in terms of the career ladder's mid-level or senior contribution expectations rather than in terms of an arbitrary week number, so that the milestone is measuring whether the new engineer can operate at the career ladder's expected independent contribution level rather than whether they have been in the role for a specified number of days; an engineer who reaches mid-level independent contribution capacity in 30 days has a faster ramp than the model predicted, while an engineer who reaches it in 90 days has a slower ramp, and the difference between 30 and 90 days is almost always a function of context transfer quality rather than hire quality when the hiring bar is functioning correctly.

Property 2: Early-tenure retention surface. The ramp model is the organization's primary mechanism for establishing whether a new engineer will stay through the first 12 months. Early-tenure attrition — departure in the first year of employment — is structurally different from mid-tenure attrition: mid-tenure attrition is driven by compensation, growth trajectory, and management quality, factors the engineer can evaluate after accumulating enough organizational context to assess objectively. Early-tenure attrition is driven by the ramp experience: whether the engineer felt productively useful and structurally supported during the period before they had enough organizational context to evaluate the longer-term opportunity. An engineer who is unproductive for the first three months with no explanation for why they are unproductive, no concrete milestone toward when they will be productive, and no visible organizational mechanism for distinguishing their situation from a caliber mismatch will attribute their unproductivity to themselves or to the organization's dysfunction by month three — both attributions produce departure intent that arrives before the engineer has built enough organizational attachment to weigh it against the cost of searching for and transitioning to a new role. The departure intent that forms in month three will produce an exit in months five through eight, after the engineer has quietly initiated a job search and found an alternative, but the root cause — the ramp model's failure to convert a capable engineer into a productively supported contributor — will be invisible in the exit interview because the engineer by month five will attribute their departure to the job opportunity rather than to the ramp model failure they experienced in months one through three. Early-tenure attrition is therefore systematically misdiagnosed: it is recorded as a retention problem solved by compensation improvement or growth opportunity clarity, when the actual root cause — a ramp model that does not convert the hiring bar's selection quality into early productive contribution — is addressed by ramp model redesign, not by retention offer adjustment after the departure intent is already formed. Connect this to the developer onboarding program decision record: the onboarding program's structure must include explicit mechanisms for surfacing departure intent during the ramp period rather than after it; a weekly ramp check-in that explicitly asks "what about this role and this team has exceeded your expectations and what has disappointed you" is not a performance review — it is an early-warning system for departure intent that gives the organization a window to address the ramp failure before the engineer's job search is already in progress; an onboarding program without this mechanism is blind to early-tenure departure intent until the resignation letter arrives, at which point the organization is responding to a retention failure rather than preventing one.

The engineering onboarding ramp ADR: five sections

Section 1: Ramp model type and milestone structure. The ramp model type specifies the structural approach to context transfer: a mentor-ramp model assigns a single senior engineer as the primary context owner for the ramp period, with explicit sessions on a defined context transfer curriculum; a program-ramp model delivers context through structured group sessions — architecture overviews, onboarding presentations, documentation tours — that are consistent across all new hires; a task-ramp model delivers context through progressively more complex task assignments, relying on the task selection and the code review feedback to build context incrementally. Each model has distinct failure modes. The mentor-ramp model's failure mode is mentor availability: if the assigned mentor is pulled onto a production incident, a high-priority feature sprint, or an extended personal leave during the ramp period, the ramp stalls because the context transfer is concentrated in a single person whose availability is not protected for the ramp. The program-ramp model's failure mode is passive context: group sessions deliver information efficiently to many people and deliver understanding poorly to any individual, because understanding requires active reconstruction — applying the information to a specific task, getting it wrong, receiving the correction, and updating the model — which group sessions do not provide. The task-ramp model's failure mode is context blindness: a new engineer on a progressively complex task sequence will encounter the tacit-knowledge constraints the team holds implicitly through the tasks' review comments rather than through proactive context transfer, which means the ramp's speed is limited by the frequency of review cycles rather than by the speed at which context can be transferred through targeted explanation. An effective ramp model is typically a hybrid: structured proactive context transfer sessions (mentor-model) delivered against a curriculum that specifies the tacit knowledge the ramp must transfer (program-model), with task assignments that give the new engineer opportunities to apply the context immediately after it is transferred (task-model) so that understanding is produced through application rather than through passive receipt. Milestone structure: ramp milestones must be defined as contribution outcomes rather than as activity completions. Activity milestones — "attended the architecture overview session," "completed the security training module," "had a coffee chat with each team member" — are completable by an engineer with no usable codebase understanding. Contribution milestones — "owns and closes one issue end-to-end without an unblock request," "produces a code review comment that the review author finds useful and acts on," "correctly diagnoses the cause of a failing test without assistance" — require the engineer to apply the context they have received, and their completion is evidence that the context transfer is working rather than evidence that the orientation calendar was executed. For each milestone, the milestone owner is specified: the ramp owner (not the new engineer) is accountable for ensuring that the context required to reach the milestone has been transferred before the milestone window opens, and a milestone miss triggers a context transfer review before it triggers any assessment of the engineer's performance.

Section 2: Context transfer ownership model. The context transfer ownership model specifies who is responsible for the ramp's context transfer quality — not who the new engineer can ask questions to, but who is accountable for ensuring that the new engineer has received the context they need before they need it, proactively rather than reactively. Distributed ownership — where context transfer is the whole team's responsibility and any team member can be asked questions — is the default in most engineering teams and is the primary source of ramp model failures in teams that have never explicitly designed a context transfer model. Distributed ownership produces reactive context transfer: the new engineer encounters a constraint, asks a question, receives an answer, and increments their context model. This is less efficient than proactive context transfer by a significant factor: proactive transfer of a context item takes one five-minute explanation; reactive transfer of the same item takes one blocking task, one escalation, one asynchronous explanation, one follow-up question, and typically one incorrect implementation that produces the review comment that motivates the transfer. The cumulative cost of reactive context transfer across a 90-day ramp is the senior engineer support time that a proactive ramp model eliminates. Assigning a single ramp owner — the context buddy — does not solve the distributed ownership problem unless the buddy role is defined explicitly: the buddy is not an on-call question answerer; the buddy is responsible for proactively transferring the 12 to 20 context items that are most likely to block the new engineer in the first 6 weeks, identifying those items from their own experience of what questions they had when they joined or what questions previous new engineers asked, and delivering them in scheduled sessions before the new engineer hits the relevant constraint in a task. The context transfer curriculum specifies what those items are: the three most important architectural decisions the team made in the last 2 years and why, the two codebase areas where the documentation is most misleading, the three operational constraints that govern how the team designs its services, the deployment process gotchas that are not in the runbook, the team's code review conventions that are not in the style guide. A curriculum of this type can be documented in one to two hours by a senior engineer who knows the codebase, and it converts the buddy's role from reactive availability to proactive knowledge transfer — a significantly more efficient model. Connect this to the engineering hiring bar decision record: the hiring bar selects for engineers who can produce strong outcomes given adequate context; the context transfer ownership model determines whether adequate context is provided in a predictable timeframe; a team that consistently produces strong hires who ramp slowly is almost always experiencing a context transfer ownership failure rather than a hiring bar failure, and the correct diagnosis changes the intervention from raising the hiring bar — which increases candidate pipeline cost without improving ramp outcomes — to designing a proactive context transfer curriculum that converts the team's tacit knowledge into an explicit ramp asset.

Section 3: Ramp velocity tracking and milestone check-in protocol. Ramp velocity tracking is the mechanism by which the ramp owner and the new engineer's manager maintain shared visibility into whether the ramp is on trajectory before it produces an early-tenure departure. The check-in protocol specifies the frequency, format, and decision criteria for ramp velocity reviews. Frequency: weekly for the first 8 weeks, biweekly from week 9 through the ramp completion milestone. Weekly frequency is necessary in the first 8 weeks because a context gap that is not identified until the biweekly check-in has cost 2 weeks of blocked or reduced-velocity work; at 1 hour per week, the ramp check-in is a low-cost intervention that prevents a high-cost ramp extension. Format: the check-in has three sections, conducted in order. First, context transfer review: what context transfer sessions occurred in the prior week, what did the engineer learn from each, and what context gaps did the engineer identify — blockers they hit where they did not know something they needed to know? The ramp owner is responsible for the first section's content: if no context transfer sessions occurred, that is a ramp model failure, not a new engineer failure. Second, milestone progress: which milestones were targeted this week, were they reached, and if not, what was the specific blocker? For each missed milestone, the classification is made explicit: was the miss a context gap (the engineer lacked information required to complete the milestone), a codebase complexity underestimate (the milestone assumed a simpler codebase than the actual one), or a capability concern (the engineer had adequate context and time but did not produce the milestone outcome)? The first two classifications are ramp model failures requiring ramp acceleration or milestone recalibration; the third classification is a hire quality signal requiring a separate conversation, and it should be reached only after the first two are explicitly evaluated and ruled out. Third, early departure signal: one direct question — "What about this role and this team has been better than you expected, and what has been worse than you expected?" — asked weekly for the first 8 weeks. An answer to the second half of the question that references unproductivity, unclear expectations, or feeling unsupported is an early departure intent signal that should produce an immediate ramp intervention, not a performance conversation. The question is not a satisfaction survey; it is an early-warning system for the ramp experience producing a departure intent that will cost more to reverse in month five than to address in week three. Connect this to the engineering career ladder decision record: the ramp's contribution milestones must be anchored to career ladder level definitions to be meaningful; a milestone that says "contributes independently at the expected level" is not operationalizable without a career ladder that defines what the expected level for a senior engineer's contribution looks like at 8 weeks, 12 weeks, and 6 months; the career ladder's seniority definitions are the reference against which the ramp milestone's "expected level" must be specified, and an organization without an explicit career ladder cannot specify contribution milestones with enough precision to distinguish a context gap miss from a caliber miss — it can only observe that the engineer is "behind" without a frame of reference for what "on track" looks like.

Section 4: Role-specific ramp variants. The ramp model's milestone structure and context transfer curriculum must be designed for each engineering role type rather than applied uniformly across the engineering organization. The failure mode of a uniform ramp model is milestone calibration error: milestones that are achievable in the target window for one role type are not achievable in the same window for a role type with a different context complexity profile, and applying the same milestone timelines across both role types produces systematic milestone failures in the higher-context-complexity roles that are ramp design failures rather than engineer performance failures. The primary dimension of role-specific variation is context complexity at first contribution: a product feature engineer whose first contribution is a UI component or API endpoint backed by well-understood domain logic requires two to four days of codebase orientation before first-PR readiness; a platform engineer whose first contribution touches a custom orchestration system with a complex state machine requires three to five weeks of orchestration system familiarization before first-PR readiness; a staff engineer whose first contribution is an architectural recommendation requires two to three months of organizational and codebase context accumulation before the recommendation is credible. Role-specific ramp variants must specify four things for each role type. First, the ramp timeline: the target dates for each milestone calibrated against the actual time-to-contribution distribution for prior hires in that role, not against a universal organizational standard. Second, the context transfer curriculum: the specific tacit knowledge items that are most likely to block a new engineer in that role, ordered by likelihood of being a first-30-day blocker, so that the buddy can prioritize context transfer across a list rather than covering general-purpose orientation in sequence. Third, the ramp prerequisites: what context must be in place before the first-contribution milestone window opens — for the infrastructure engineer, the orchestration system state machine must be covered in the curriculum before the first-PR milestone is expected, because a PR without that context will be context-incorrect and the review correction cycle will add 2 weeks to the ramp for no benefit to either party. Fourth, the role-specific early signals: what are the leading indicators, specific to that role type, that the ramp is on track versus off track in the first 30 days? For a product engineer, on-track signals include: reading the codebase for the relevant service independently rather than asking for every entry point, identifying code review comments as belonging to a specific convention rather than as arbitrary feedback, and asking questions that reference the architecture overview's service boundaries correctly. For an infrastructure engineer, on-track signals include: describing the orchestration system's state transitions correctly in a casual conversation, identifying which changes require a state machine diagram review versus which are safe to infer from existing patterns, and asking questions about the system's design rationale rather than only about its current behavior. Role-specific on-track signals allow the ramp owner to identify a ramp that is building context correctly versus one that is accumulating surface knowledge without the structural understanding required for independent contribution, weeks before the distinction appears in milestone completion data.

Section 5: Ramp retrospective and onboarding effectiveness review. The ramp retrospective is the mechanism by which the ramp model's calibration is improved across hiring cohorts and the ramp's structural failures are diagnosed before they produce another early-tenure departure. The retrospective must answer four questions using data from the prior 12 months. First, what is the cohort-level time-to-first-contribution distribution by role type? For each engineer hired in the prior 12 months, the time from start date to the first sprint where the engineer closed at least 75% of committed sprint points without a senior engineer unblock, broken down by role type. A consistent gap between the median time-to-first-contribution and the milestone target date for a role type indicates that the milestone timeline is miscalibrated, the context transfer curriculum is incomplete, or the ramp ownership model is producing reactive rather than proactive context transfer. A high variance in time-to-first-contribution within a role type indicates that the ramp outcome is sensitive to individual buddy quality rather than to the ramp model's design — a structural signal that the curriculum is underspecified and the buddy role is relying too heavily on individual senior engineer judgment rather than on a documented context transfer list. Second, what is the senior engineer support time consumed per ramp by role type? Across the first 90 days of each hire, the total hours of senior engineer time spent on context transfer sessions, unblocking tasks, reviewing PRs with context correction comments, and pairing sessions that substituted for structured context transfer. An organization that does not measure this does not have a ramp cost model; it has a salary cost model that misses the largest variable in the true cost of each hire. A median ramp that consumes 40 hours of senior engineer time is a ramp that cost one engineer-week of senior capacity per hire — at $200/hour for a senior engineer's fully-loaded time, a $8,000 hidden cost per hire that a well-designed ramp model can reduce to 15 to 20 hours without any change to the hiring bar or the sprint allocation model. Third, what fraction of early-tenure departures in the prior 12 months occurred in engineers whose exit interviews cited reasons that could reflect ramp model failures — "slow start," "unclear expectations," "felt unsupported," "took too long to feel productive"? An organization where more than 30% of first-year departures cite these reasons is experiencing a ramp model retention failure that compensation and growth opportunity improvements cannot address, because the departure intent forms during the ramp period when the engineer does not yet have enough organizational context to evaluate compensation and growth opportunity accurately. Fourth, what is the ramp miss rate by milestone type and role type in the prior year, and what is the proportion of misses classified as context gap versus capability concern? An organization where more than 60% of milestone misses are classified as capability concerns has either a hiring bar problem or a misclassification problem — most milestone misses in a well-calibrated hiring process are context gaps, and a high capability-concern classification rate usually reflects a ramp check-in protocol that defaults to capability concern rather than investigating context gap causes. Design sessions in ChatGPT or Claude that produced the current ramp model — the session where the team debated whether the buddy role should be defined as question answering or proactive context delivery, why the first-PR milestone was set at week 1 rather than week 2, and what the context transfer curriculum should prioritize for the infrastructure team's orchestration system — should be run through the open-source extractor before the annual ramp retrospective to recover the explicit reasoning behind each ramp design choice, so the retrospective reviewer can evaluate whether a proposed revision addresses a genuine ramp design gap or undoes a deliberate constraint that was built in response to a prior cohort's specific failure pattern rather than as a universal policy, and can distinguish between a ramp model that needs to be redesigned and a ramp owner who needs to be coached on the model the organization already has.

FAQ

Further reading

• Developer onboarding program decision record — the onboarding program is the delivery mechanism for the ramp; its structure determines what context transfer activities occur and in what sequence, but the program's design is only effective if its success metrics are tied to ramp outcomes rather than program completion rates; a program optimized for checklist completion will produce 100% completion and variable ramp outcomes, while a program optimized for time-to-independent-contribution will surface context gaps and context complexity underestimates early enough to correct them within the ramp window rather than after the engineer's departure intent has already formed.
• Engineering career ladder decision record — the ramp's contribution milestones must be anchored to career ladder level definitions to be measurable rather than subjective; a milestone that requires a senior engineer to assess whether the new engineer is "contributing at the expected level" without a career ladder's definition of what that level looks like at 8 weeks and 12 weeks produces high inter-assessor variance and conflates ramp velocity with career level assessment; the career ladder's capability definitions are the reference against which the ramp milestone's "expected level" is specified, and an organization without an explicit career ladder cannot distinguish a context gap milestone miss from a caliber milestone miss with any structural reliability.
• Engineering hiring bar decision record — the hiring bar and the onboarding ramp are sequential stages of the same quality assurance system; the hiring bar selects for engineers who can produce strong outcomes given adequate context, and the ramp model determines whether adequate context is provided in a predictable timeframe; a team that consistently produces strong hires who ramp slowly is almost always experiencing a ramp model failure rather than a hiring bar failure, and the correct diagnosis changes the intervention from raising the bar to designing a proactive context transfer curriculum — raising the bar in response to a ramp failure increases candidate pipeline cost and time-to-fill without changing the ramp outcome, because the ramp failure is in the context transfer model, not in the engineer's capability level.
• Code review policy decision record — the code review process is the ramp's most frequent context transfer surface during the task-assignment phase; a code review process that provides explanatory context for comments converts every review into a context transfer event, while a process that provides only correction without explanation requires the new engineer to reconstruct the reasoning behind each comment independently through codebase exploration, adding days to the ramp for every significant review cycle; the review policy's conventions for how comments are written — whether reviewers are expected to explain why an approach is problematic and where the correct approach is documented, or only to flag that the approach requires change — is a ramp design decision as much as a code quality design decision.
• Open-source extractor — ramp model design sessions in ChatGPT or Claude contain more explicit reasoning about context transfer trade-offs than most onboarding documentation: the session where the team debated whether the first-PR milestone should be in week one or week two, why the buddy role was defined as proactive curriculum delivery rather than reactive question answering, and what specific tacit knowledge items the infrastructure team's context transfer curriculum should cover first contains the incident history and reasoning that motivated each design choice; running those design session exports through the extractor before the annual ramp retrospective retrieves the explicit reasoning from the design conversation — including the failure patterns that motivated each safeguard — so the review team can evaluate whether a proposed revision addresses a genuine ramp design gap or undoes a deliberate constraint the prior team built in response to a specific cohort's departure pattern; the distinction between a gap and a deliberate design choice is most reliably available in the original design conversation, not in the reviewer's recall of a planning discussion from two years earlier.