Developer Onboarding Checklist: 14-Day Playbook

Gallup research on onboarding finds only 12% of employees say their company does the job well, and the productivity gap shows up fastest in engineering hires. When a senior developer joins on day one but doesn't ship anything useful until day 30, you've paid $20K+ for ramp-up time and lost a sprint cycle the roadmap can't recover.

Most of that delay is preventable. The mechanics of getting a developer from contract signature to first merged PR are well understood; teams just don't run the checklist. This guide is that checklist: a 14-day onboarding playbook covering access provisioning, codebase ramp-up, first sprint deliverables, and the outstaffing-specific steps that catch most teams off guard.

The framework works for any developer hire. It's most useful for outstaffed engineers, where the legal, contractual, and security layers add complexity that in-house onboarding skips. For broader context on engagement models, our outstaffing vs outsourcing guide covers the model-choice decision; this article picks up where that one ends.

Why Onboarding Decides the First Sprint

The first sprint of a new hire predicts retention better than the interview. Developers who ship a meaningful commit in week one feel like they belong. Developers who spend week one chasing access credentials, broken local builds, and unanswered Slack pings start looking at job boards by week three.

Bad onboarding costs the business twice. Once in lost sprint capacity: the developer is paid but not productive. Twice in opportunity cost: a senior backend hire idle for 30 days is roughly $20–30K of compounded delay on roadmap velocity. SHRM's onboarding research links structured onboarding to 50% higher retention and 62% higher productivity in the first year. For the broader hiring frame, see our remote developers guide.

The fix isn't more onboarding meetings. It's a tight, written checklist with owners assigned before the developer's start date.

The 14-Day Onboarding Playbook

The playbook breaks into four phases. Each has a clear deliverable.

Pre-Day 1 (the week before start). Hardware shipped or accounts provisioned for BYOD. SSH keys exchanged. GitHub or GitLab repo access requested. Slack, Linear, or Jira accounts created. NDA and IP assignment signed. Buddy assigned. First-sprint scope drafted, not finalized.

Days 1–3. Day 1 is intro day: team meet-and-greet, codebase tour from the tech lead, environment setup, first local build. Day 2: read the last 30 commits, attend standup as observer, get the buddy walkthrough of the architecture diagram. Day 3: pick up a documentation-style ticket (fix a comment, update a README, write a missing test). Goal: first PR opened by end of day 3.

Days 4–7. First PR merged. Pick up a small bug-fix ticket. Attend sprint review. Have the buddy review the diff before submission. By end of day 7, the developer should have 2–3 small PRs merged and feel comfortable with codebase navigation.

Days 8–14. Take on a real feature ticket sized for one sprint week. Pair with the buddy for the first 1–2 days, then work independently. Submit for code review by day 13. Merge by day 14. By end of week 2, the developer should be a full sprint contributor. Use DORA's four key metrics (deployment frequency, lead time, change failure rate, MTTR) to track whether the new hire is reaching team baseline.

‍

‍

What's Different About Onboarding Outstaffed Developers

An outstaffed developer is legally employed by a vendor but works inside your team. That structure adds five onboarding steps in-house hires skip:

Per-contractor IP assignment. Master Service Agreement (MSA) with the vendor isn't enough. Each engineer should sign an individual IP assignment specific to your project. Without it, ownership of the code they write can be contested.

Individual NDAs. Same logic. The vendor's blanket NDA covers vendor staff at the corporate level; the engineer's individual NDA covers them at the personal level. Both should be in place before day one access.

Vendor escalation path. Defined upfront: who do you contact at the vendor if the engineer is underperforming, unavailable for a critical sprint, or needs to be replaced. The vendor should have a single point of contact for delivery issues, not just a sales rep.

Payroll and invoicing handoff. The engineer is on the vendor's payroll, not yours. Monthly invoicing flows through the MSA, not through internal HR. This sounds trivial but is the #1 source of friction in the first month if not pre-configured.

Security clearance for regulated environments. If your codebase touches PHI (healthcare), PCI data (payments), or other regulated information, the engineer needs documented access permission from your compliance officer before any access is granted. The IBM Cost of a Data Breach Report puts the average breach at $4.45M and rising; access provisioning is where many of those incidents start. Don't skip this step to save time. The audit later costs more than the delay now. For regulated-industry context, see our healthcare app development guide.

Access Provisioning Without Security Risks

Access is the #1 onboarding bottleneck. It's also the #1 source of security incidents. Get this right and the developer ships fast; get it wrong and you're explaining a credential leak to legal six months later.

Use least-privilege from day one. The new developer doesn't need admin on the production database. They need read access to the staging environment, write access to one feature branch, and the ability to deploy to a sandbox. Promote permissions as the developer proves judgement.

Time-bound credentials. Every credential issued should have an expiration date matching the contract term. Vendor-managed engineers should never have indefinite admin tokens. Tokens lapse, get rotated, get re-issued. Tools like Vault, AWS SSO, or 1Password Business make this easy.

Audit trail. Log who provisioned what, when, and why. The log lives in your offboarding playbook too. When the engagement ends, the same log is the offboarding checklist.

No shared accounts. Each developer gets their own credentials on every system. Shared admin accounts are how breaches happen and how attribution becomes impossible after one.

Communication and Sprint-Cadence Setup

Onboarding is half access, half communication norms. Engineers default to whatever pattern they learned at their last job. If you don't set the norms, the team inherits whatever theirs were.

Async standup format. Slack thread, Linear update, or async video. Pick one. The new developer posts daily by 11 AM local time: yesterday's work, today's plan, blockers. The buddy is responsible for closing the loop on any blockers within 2 hours. The Stack Overflow 2024 Developer Survey shows async-first teams report higher productivity than sync-heavy ones, but only when the cadence is enforced.

Sprint cadence. One-week sprints work for MVP scale. Two-week sprints work for standard production. Pick one, don't switch mid-quarter. Sprint planning is Monday, retro is Friday. The new developer attends both from week one.

Doc-first culture. If a decision happens on a call, someone writes it down in Notion or Confluence within 24 hours. The LinkedIn Workplace Learning Report flags self-service documentation as one of the highest-ROI learning investments a team can make. The new developer learns the system by reading the doc trail, not by asking the same question three times.

Code review SLA. A new developer's PR sits in review queue longer than a senior's because reviewers want to be thorough. Set an SLA: PRs are reviewed within 4 business hours, even if the review is "looks good, let's pair on the next one." Velocity dies in review queues.

Red Flags That Tell You Onboarding Is Failing

By day 7, you should see clear signals. If you don't, intervene.

No PR by day 5. Either the developer is stuck and not asking, or the buddy isn't unblocking them. Talk to both. If it persists past day 10, the engagement isn't going to work.

Repeated environment issues. "I can't run the tests locally" on day 8 is a setup problem the team should have fixed by day 3. If the developer is still fighting setup at week two, the team's documentation is failing.

Ghost on standups. Missed standups in week one is a red flag. Address it on day 2, not day 14.

No questions asked. Counterintuitive but real. New developers who don't ask any questions in the first week aren't confident, they're disengaged. The buddy should be answering 5–10 questions a day for the first two weeks.

Buddy disengagement. The buddy is the make-or-break role. If they're "too busy" to onboard, the developer fails by default. Pick the buddy carefully and protect their calendar for the first two weeks.

How Empat Onboards Outstaffed Developers

At Empat, we onboard outstaffed engineers into client teams in 1–2 weeks on average. The mechanics are the same as the 14-day playbook above, with two specifics worth knowing:

The first sprint is scoped before contract signature. By the time the engineer's first day starts, the buddy is identified, the ticket is sized, and the IP assignment is signed. No waiting room.

Vendor-side delivery management. A senior PM on our side coordinates with your engineering lead, handles invoicing, and escalates blockers without consuming your management time. This is the cost-efficient half of the hybrid team model.

To see how this works on your project, see our outstaffing services, browse staff augmentation for shorter engagements, or book a free 30-minute consultation. For the broader hiring framework, our remote developers guide covers sourcing and vetting; this playbook covers what happens after the hire. If you're still picking an engagement model, outstaffing vs outsourcing and software outsourcing compare the options.

The first sprint is the test

Onboarding doesn't end on day 14. But by then, you know whether the engagement will work. The developer who has shipped 3+ merged PRs and contributed to sprint review is going to be a full team member. The developer still fighting environment setup needs a different kind of help, or a different engagement.

Run the checklist. Assign owners before day one. Protect the buddy's calendar. The cost of doing this well is two hours of planning. The cost of skipping it is two months of lost sprint capacity. The math is honest.

FAQ

How long should developer onboarding take?

For a senior developer joining a working team, two weeks is the realistic target for full sprint contribution. The first PR should land by end of day 3. By day 14, the developer should be sized for a full sprint ticket and shipping it independently. Anything longer signals a documentation or buddy-assignment problem, not a developer problem.

What's different about onboarding an outstaffed developer vs an in-house hire?

Five things: per-contractor IP assignment (not just MSA), individual NDA, vendor-side escalation path, payroll handoff through the vendor's invoicing, and security clearance for regulated codebases. The technical onboarding is identical; the legal and contractual onboarding adds about a day of paperwork that needs to happen before day one.

When should I replace a developer who's onboarding slowly?

If the developer hasn't shipped a PR by day 5, intervene immediately. If they still haven't by day 10, the engagement isn't going to work. Move fast. The cost of a slow-ramp replacement at week two is lower than the cost of a misfit engineer dragging on sprint velocity for two months.

What should an outstaffed developer be onboarded on first?

The codebase, in this order: read the last 30 commits, run the tests locally, ship a documentation fix (first PR by day 3), then a small bug fix, then a feature ticket. Architecture deep-dive and product context come second. Code-first onboarding gets the developer productive; product-first onboarding stalls them at week one.