The first 90 days for a new engineer look something like this:
- Week 1-2: Set up laptop, get access, read the README (if it exists), stare at the codebase.
- Week 3-6: Ask senior engineers questions constantly. Interrupt their flow. Get partial answers. Build an incomplete mental model.
- Week 7-12: Start shipping small features. Still can't answer architecture questions. Still interrupting people. Still finding "surprises" in the codebase.
- Month 4+: Finally productive. But the seniors you interrupted for 3 months are now behind on their own work.
This is the industry standard. It doesn't have to be.
After watching this cycle repeat across dozens of teams, I've developed a playbook that cuts onboarding from 3 months to roughly 1 day of active learning. Not 1 day to be fully senior — 1 day to be productive enough to ship a small feature without interrupting anyone.
Here's how it works.
The old way: knowledge transfer by interruption
The traditional onboarding model relies on human-to-human knowledge transfer. The new hire asks a question, a senior engineer answers it. This is the most expensive possible way to transfer knowledge:
- It burns two people's time. Every 15-minute question costs 30 minutes of company time.
- It's lossy. The senior engineer's mental model is compressed into a verbal explanation. The new hire decompresses it differently. Information is lost.
- It doesn't scale. You can't onboard 5 people simultaneously if the knowledge lives in 2 people's heads.
- It's not asynchronous. The new hire can only learn when the senior engineer is available. Timezone differences make this worse.
The average new hire asks 23 questions per week during their first month (Plug and Play Tech Center, 2025). Each question interrupts a senior engineer for 10-15 minutes. That's 4-6 hours per week of senior engineer time spent answering questions.
The new way: documentation-first onboarding
The documentation-first model flips this: the new hire gets answers from documentation and AI chat, not from humans. Senior engineers only get interrupted for genuinely novel questions that require a decision, not a fact.
Here's the 4-step playbook:
Step 1: Generate comprehensive, per-component docs (2 minutes)
Before the new hire starts, connect the repo to ShipDocs. The indexer reads every file, classifies components (backend, frontend, workers, CLI, migrations, etc.), and writes one Markdown doc per component.
This takes about 2 minutes per repo. You don't write anything. You don't fill out a template. The docs are generated from the actual source code.
What the new hire gets:
- Overview doc: What the project is, what stack it uses, how to run it.
- Per-component docs: Backend architecture, frontend component structure, worker pipeline, CLI commands, database migrations — each documented with the real file references and the real module boundaries.
Step 2: Set up the AI chat as the "first responder" (5 minutes)
ShipDocs includes an AI chat that's grounded in the generated documentation. When the new hire asks "where do we validate incoming requests?", the chat doesn't hallucinate — it searches the docs, finds the relevant section, and cites the file path.
Configure the chat as the first thing the new hire sees in the project. Make it clear: ask the chat first, ask a human second. This single rule eliminates 80% of interruptions.
What the new hire can ask:
- "Where is the authentication middleware?"
- "What does the payment processing pipeline look like?"
- "How do I run the test suite for the backend?"
- "What environment variables does the worker need?"
Each answer comes with a file citation. The new hire can click through to the actual source and verify for themselves.
Step 3: Create a self-service onboarding checklist (30 minutes)
Write a short checklist that the new hire can follow without any human help. Here's a template:
Day 1 Onboarding Checklist
────────────────────────────
□ Clone the repo and run `npm install` (or `bun install`)
□ Read the "Overview" doc in ShipDocs
□ Run the project locally (instructions in the Overview doc)
□ Ask ShipDocs chat: "What are the main components of this codebase?"
□ Read the component doc for the area you'll be working on
□ Ask ShipDocs chat: "How do I add a new API endpoint?"
□ Find and read one test file
□ Make a trivial change (fix a typo, update a comment) and submit a PR
□ Ask ShipDocs chat any 5 questions you have about the codebase
□ Ship your first real feature (from the issue assigned to you)
The key insight: every item on this list can be completed without asking a human. The docs and the chat handle the knowledge transfer. The senior engineers review PRs asynchronously, which is what they should be doing anyway.
Step 4: Schedule one 30-minute architecture walkthrough (Day 2)
After the new hire has spent a day reading docs and chatting with the AI, schedule a single 30-minute call with a senior engineer. But this isn't a "let me explain the codebase" call. It's a "here's what I understood, is this right?" call.
The new hire comes prepared with specific questions that the docs and chat couldn't answer. The senior engineer clarifies design decisions, trade-offs, and tribal knowledge. Thirty minutes. Done.
Compare this to the traditional model where the senior engineer spends 4-6 hours per week for 12 weeks answering questions. That's 48-72 hours of senior engineer time. The documentation-first model uses 0.5 hours.
The results we've seen
Teams using ShipDocs for onboarding report:
- Time to first PR: 1-2 days (vs. 2-4 weeks industry average)
- Senior engineer interruptions: Down 85% during the first month
- New hire confidence: Higher, because they can find answers independently
- Documentation coverage: 100% of repos documented (vs. 20-30% with manual processes)
One team of 12 engineers told us they went from onboarding 1 person at a time to onboarding 3 simultaneously — with the same number of interruptions. The docs and the chat absorbed the repetitive questions.
Why this works (the psychology)
Developers don't actually want to interrupt senior engineers. They do it because it's the fastest path to an answer. When you provide a faster path — the AI chat that answers in seconds with cited file paths — they take it.
The key is speed and accuracy. If the chat is slow or wrong, developers go back to interrupting humans. ShipDocs works because:
- Answers are fast (under 5 seconds for most questions)
- Answers are cited (file paths, not hand-waving)
- Answers are accurate (grounded in the generated docs, not training data)
When the chat is faster and as reliable as asking a senior engineer, people use the chat. When the chat is slower or less reliable, they go back to humans. It's that simple.
The cost of NOT doing this
Let's go back to the math. If a senior engineer spends 5 hours/week answering onboarding questions for the first 3 months:
- 5 hours × 12 weeks = 60 hours per new hire
- At $101/hour fully loaded = $6,060 per new hire in senior engineer time
- If you hire 10 people this year: $60,600
ShipDocs Advanced costs $29/month. For a team of 12 sharing one Advanced plan: $29/month or $468/year.
You're paying $60,600/year in interruption costs to save $3,336/year in tooling. That's an 18x overpayment.
Start now
- Connect your repos. Two minutes per repo. No manual writing.
- Enable the chat. Make it the default landing page for new hires.
- Update your onboarding doc. Add the checklist above.
- Stop answering repetitive questions. Point people to the chat.
Your senior engineers will thank you. Your new hires will thank you. Your bottom line will thank you.
ShipDocs auto-generates encrypted, chat-ready documentation from any codebase. Start for free → — no credit card, no setup, 2 minutes to first docs.