The default onboarding for a senior data hire at a $100M+ company runs about six months before the person produces work that anyone outside their manager would recognize as load-bearing. That’s a tax — paid in salary, in opportunity cost, and in the quiet erosion of confidence on both sides. It’s also avoidable. The plan below assumes a competent hire, a manager who can clear blockers, and a willingness to swap “ramp” for “production with scaffolding.”
The premise
Onboarding fails in three ways: too much reading and not enough doing, no clear definition of “done” for the first 90 days, and ambiguity about whose problems the new hire actually owns. The fix is to pre-commit to specific deliverables on a calendar, then back-fill the context needed to ship them. Context-on-demand beats context-up-front.
Week 1: access, map, first commit
Day 1 is access. Every system, every channel, every shared drive — provisioned before the person walks in. If they spend day 2 chasing IT, you’ve already lost a week. Day 2 through 4 is shadowing: one ride-along per day with a different stakeholder (sales ops, finance, a product manager, an engineering lead), 60 minutes each, with a shared note template the new hire fills in live. By Friday they’ve heard four different versions of “what data is broken here,” and the patterns will already be visible.
The week 1 deliverable is non-negotiable: one merged PR. It can be a typo fix in a dbt model description, a renamed column in a staging view, or a corrected unit in a dashboard tooltip. Triviality is the point. The goal is to exercise the full path — branch, change, review, merge, deploy — while it’s still cheap to be confused.
Week 2: a real but bounded ticket
Pick a ticket that’s been sitting in the backlog for at least a quarter. Something a senior analyst could finish in two days but nobody has prioritized. Hand it over with the original requester’s contact info and a single sentence of context. The new hire’s job is to ship it end-to-end: clarify the requirement with the requester, write the query or model, validate against a known answer, document, deploy, close the ticket. By end of week 2 the requester should be saying “thanks, finally.”
This is also the week the new hire should attend their first incident retro or post-mortem, even as a silent observer. They learn more from one real failure walkthrough than from a week of architecture diagrams.
Weeks 3–4: a domain takeover
Choose one analytical domain — pipeline forecasting, churn, marketing attribution, supply-chain working capital, whatever the company most needs the new hire to own — and assign it. Not “help with,” not “shadow,” own. By end of week 4 the new hire is the named directly-responsible individual for that domain in the team’s RACI, and they’ve delivered one measurable improvement: a model with a documented accuracy gain, a dashboard the business actually uses, a query that runs in 30 seconds instead of 30 minutes. The improvement gets written up in a 200-word internal post.
Day 30 checkpoint
Three artifacts on the table: the week-1 PR, the week-2 ticket, the week-4 domain takeover writeup. The manager and the new hire sit together for 60 minutes and answer one question: do we have the right person in the right seat? If yes, the next 60 days are aggressive. If no, the conversation happens now, not at month five.
Days 31–60: ship something the executive team sees
Pick a deliverable that will be presented in a leadership forum within the next 30 days — a quarterly business review, a board prep deck, an exec offsite read-ahead. The new hire produces the analytical backbone for one section of it. Not all of it; one section, with a senior partner sponsoring the work and reviewing every figure. The bar is correctness under scrutiny: every number traceable to a source, every methodological choice defensible in writing, every caveat surfaced before someone else finds it.
Parallel track: by day 45 the new hire should have led one technical interview loop for an open role on the team. Hiring is a forcing function for clarifying what “good” looks like, and it embeds the new hire in the team’s identity faster than any team-building exercise.
By day 60 the deliverable has been presented, the feedback loop has run, and the new hire has either gained or lost trust with the executive audience. Both outcomes are useful — the second tells you what to invest in next.
Days 61–90: own a strategic project end-to-end
A strategic project is one with a named business sponsor outside the data team, a defined success metric, a budget (even if just headcount-time), and a deadline more than 30 days out. The new hire is the project lead. They scope, staff (likely just themselves plus partial allocations from one or two teammates), execute, and present results. The manager’s job from day 61 onward is to remove blockers, not direct the work.
Day 90 checkpoint
By day 90 the new hire has shipped one PR, closed one stale ticket, owned one domain, contributed to one executive-visible deliverable, run one interview loop, and led one strategic project. Six concrete artifacts. Compare that to the typical six-month ramp where the artifact list is “completed onboarding.” The conversation at day 90 isn’t “are you ramping” — it’s “what’s the next strategic project, and how does it ladder to the team’s annual plan.”
What this requires from the manager
Pre-staged tickets. A real domain to hand over. A leadership forum slot pre-booked for day 60. An interview loop in the calendar by day 45. Strategic-project candidates with named sponsors waiting on day 60. None of this materializes on its own. If the manager hasn’t built the runway, the plan collapses to wishful thinking — and the new hire absorbs the cost.
The 30/60/90 isn’t a ramp curve. It’s a contract.