Read this first: this is a design study — a concept I designed to show how I would approach R&D onboarding. It is not a delivered program, it was not built or approved by any employer, and no results are claimed for it. The design is the deliverable.
The Design Problem
A new R&D scientist's first 90 days usually fail in predictable ways: access and systems setup drag on, regulatory foundations arrive as a pile of documents with no sequence, and nobody checks what the new hire actually understands until they're already doing the work. This design treats onboarding as one blended journey with a deliberate order — get them equipped, build the regulatory base, connect them to people, and verify learning as it happens.
The Path at a Glance
1 · Get EquippedSystems access & setup, accounts, tools, workspace — sequenced before day one where possible
→
2 · Build FoundationsRegulatory foundations in paced, self-directed modules matched to the scientist's function
→
3 · ConnectAssigned mentor, scheduled checkpoints, team introductions with a purpose
→
4 · VerifyKnowledge checks at each stage — gaps caught while they're still cheap to fix
→
5 · ContributeFirst real assignments sized to current capability, with mentor review
The 90 Days, in Phases
| Phase | Learning & Setup | People & Proof |
|---|---|---|
| Days 1–30 · Settle in | Systems access and setup completed; core regulatory foundations started; role essentials and team context | Mentor assigned and first checkpoints held; knowledge check on foundations covered so far; manager confirms access blockers are cleared |
| Days 31–60 · Build depth | Deeper function-specific learning; shadowing real work; first supervised contributions | Mentor checkpoints shift from logistics to judgment questions; knowledge check on applied concepts, not just recall |
| Days 61–90 · Work independently | Full participation in team work; remaining foundations completed; learning gaps closed with targeted refreshers | Final 90-day review against the path; new hire and manager both assess readiness; feedback on the path itself collected |
Design Decisions Worth Noting
- Access is a learning problem: every day spent waiting on systems is a day of onboarding that didn't happen, so setup is sequenced into the journey and tracked like coursework.
- Mentor checkpoints are scheduled, not hoped for: the mentor relationship carries the tacit knowledge no module holds — the design gives it calendar time and a purpose at each phase.
- Knowledge checks gate progress, kindly: checks exist to find gaps early and route the learner back to exactly the content they missed — feedback, not judgment.
- Blended on purpose: self-paced content for foundations, people for context and judgment, real work for application — each channel doing what it's best at.
Measurement Plan — Kirkpatrick Style
A design that can't say how it would be judged isn't finished. This concept would be evaluated at all four Kirkpatrick levels:
| Level | Question | How it would be measured |
|---|---|---|
| 1 · Reaction | Did new hires find the path useful and well-paced? | Short pulse surveys at days 30, 60, and 90, plus structured feedback at the final review |
| 2 · Learning | Did they actually learn the foundations? | Knowledge check results by stage — completion, scores, and which concepts needed re-teaching |
| 3 · Behavior | Are they working the way the role requires? | Manager and mentor observation at checkpoints: independent task handling, correct process use, quality of first deliverables |
| 4 · Results | Did onboarding get faster and better? | Time-to-productivity against the prior baseline, early-tenure error and rework rates, and 90-day retention of new scientists |
What this study shows: how I sequence a blended journey, where I put human support, and how I'd prove the program worked. Turning it into a real program would start the way all my real work starts — with a stakeholder needs analysis.