Developer Onboarding Plan Template (2026)
The first 90 days define whether a new developer thrives or quietly disengages. A structured onboarding plan removes the anxiety of not knowing what's expected, gives managers clear milestones to check against, and cuts time-to-first-contribution from weeks to days. This template follows the proven 30-60-90 day framework used by engineering teams at scale — covering environment setup, codebase exploration, first PR, independent contribution, and full team integration. Adapt it for senior engineers (compress the timeline), junior developers (extend the exploration phase), or contractors (add an access expiry and handoff plan).
2-minute setup • No credit card required
When to use this template
Share this plan with the new developer on their first day — ideally by their manager, not HR. Walk through it together in the first 1-on-1 and update it as context changes. The document should live in your team wiki (Notion, Confluence, or GitHub wiki) so the developer can reference it async.
Template Variations
Pick the format that fits your context.
Before Day 1 — Manager Checklist
The biggest mistake in onboarding is waiting until the developer starts to prepare. Equipment, access, accounts, and a buddy assignment should all be done before they arrive. A developer who can't access the repo on day one loses trust immediately.
# Before [Developer Name] Starts ## Access & Accounts (complete 3+ days before start) - [ ] Laptop ordered and configured (OS, security policies, MDM enrolled) - [ ] GitHub/GitLab/Bitbucket organization invite sent - [ ] Slack/Teams workspace invite sent - [ ] Jira/Linear project access granted - [ ] AWS/GCP/Azure console access provisioned (least privilege) - [ ] VPN access configured - [ ] 1Password / Bitwarden team vault invite - [ ] Google Workspace / Microsoft 365 account created - [ ] Confluence/Notion space access granted - [ ] Datadog / Sentry / PagerDuty observer access - [ ] PagerDuty schedule added (after 30 days) ## Team Setup - [ ] Buddy/onboarding mentor assigned: [@buddy-name] - [ ] First-week calendar blocked: 1-on-1 with manager (Day 1, Day 3, Day 5) - [ ] Team intro meeting scheduled (Day 2) - [ ] Architecture walkthrough scheduled (Day 3-5) - [ ] First good-first-issue labeled and reserved in Jira/Linear ## Documentation Prep - [ ] README.md is accurate and setup instructions work on a fresh machine - [ ] Architecture decision records (ADRs) are accessible - [ ] Team working agreements / norms doc shared - [ ] On-call runbook location shared
Week 1 — Orientation and Environment
The goal of week one is simple: get the developer to a working local environment and understand the shape of the codebase. Nothing else. Don't expect code shipped in week one — expect a developer who can run the app locally, understands the team structure, and knows who to ask for what.
# Week 1: Orientation & Setup **Developer:** [Name] **Start date:** [Date] **Manager:** [Name] | **Buddy:** [@buddy-name] ## Day 1 — First Day - [ ] 1-on-1 with manager (30 min): walk through this 30-60-90 plan together - [ ] Team intro call: meet the team, share backgrounds - [ ] Complete HR paperwork and security training - [ ] Set up workstation: install required tools (see setup guide: [link]) - [ ] Clone the main repository and follow the README setup steps - [ ] Join all Slack/Teams channels: #engineering, #[team-channel], #incidents, #deployments ## Day 2-3 — Environment Deep Dive - [ ] Get the application running locally (backend + frontend) - [ ] Run the test suite — confirm all tests pass - [ ] Read the README, CONTRIBUTING.md, and Architecture Overview docs - [ ] Architecture walkthrough with buddy or senior engineer (60 min) - [ ] Explore the repo structure: understand how code is organized - [ ] Shadow a CI/CD pipeline run — understand what happens when code merges ## Day 4-5 — First Code Touch - [ ] Open your first pull request: a typo fix, doc update, or test addition - [ ] Go through the full PR review cycle (submit → get reviewed → address comments → merge) - [ ] Attend sprint standup and sprint planning/review if timing aligns - [ ] End-of-week 1-on-1 with manager: blockers? questions? what's unclear? **Week 1 Success Criteria:** ✅ Local environment running ✅ First PR submitted and merged ✅ Team members known by name
Days 8-30 — Codebase Exploration and First Feature
In weeks 2-4, the developer transitions from learner to contributor. They should own and ship one real feature or meaningful bug fix by end of day 30. Pair programming and code review are your best tools here.
# Days 8-30: First Contribution ## Week 2 Goals - [ ] Pick up the reserved 'good first issue' from Jira/Linear - [ ] Pair program with buddy on the first real task (at least one session) - [ ] Read through the top 3-5 most complex modules in the codebase - [ ] Understand the deployment process: how does code go from PR to production? - [ ] Shadow an on-call engineer for one day (observer mode only) - [ ] Map out: who owns what? (teams, services, domains) ## Week 3-4 Goals - [ ] Complete and ship the first real feature or bug fix - [ ] Give a 10-minute 'show and tell' of what you shipped to the team - [ ] Submit a PR large enough to require a real review cycle - [ ] Start attending architecture / design discussions as an observer - [ ] Write or update at least one piece of documentation (README, ADR, or runbook) ## 30-Day Check-In (with manager) Schedule a 45-minute 1-on-1. Cover: - What have you shipped? - What parts of the codebase are still unclear? - How is the team dynamic? Any friction? - What would have made your first 30 days better? - What are your goals for the next 30 days? **30-Day Success Criteria:** ✅ One real feature or bug fix shipped and in production ✅ Full understanding of the deployment pipeline ✅ Code review given to at least 2 other team members' PRs ✅ Documentation improved in at least one area
Days 31-60 — Independent Contributor
By day 60, the developer should be working independently on medium-complexity tasks, participating actively in team discussions, and requiring minimal hand-holding. The buddy relationship becomes more peer-like.
# Days 31-60: Independent Contributor ## Goals for This Period - [ ] Own and deliver a medium-complexity feature from requirements to production - [ ] Lead a technical design discussion or spike independently - [ ] Join the on-call rotation (shadow first week, primary responder second week) - [ ] Participate actively in sprint planning — estimate and propose scope - [ ] Give structured feedback in at least 3 code reviews - [ ] Identify one area of technical debt and propose a solution ## Autonomy Milestones - [ ] Can merge PRs to staging without buddy review - [ ] Can respond to non-critical incidents independently using the runbook - [ ] Owns at least one service or domain in the CODEOWNERS file - [ ] Has merged at least 10 PRs to the main branch ## 60-Day Check-In (with manager) - Current vs expected ramp-up: are they ahead, on track, or behind? - Technical strengths identified so far - Areas needing development (specific, actionable) - Team integration: peer relationships, communication style - Updated 90-day goals based on business priorities **60-Day Success Criteria:** ✅ Working independently on medium-complexity tasks ✅ Active on-call participant ✅ Owns at least one area of the codebase ✅ Has reviewed and merged PRs from other team members
Days 61-90 — Full Team Member
By day 90, the developer should be indistinguishable from the rest of the team in terms of process and expectations. They may still be learning the deeper parts of the system, but they are a full contributor.
# Days 61-90: Full Team Member ## Goals for This Period - [ ] Lead delivery of a sprint story end-to-end without significant guidance - [ ] Mentor the next new hire or intern on something they've learned - [ ] Propose and implement a meaningful improvement (tooling, process, or code quality) - [ ] Contribute to technical roadmap discussion or architecture review - [ ] Complete any required compliance or security training ## Full Parity Milestones - [ ] Works at full velocity (contributing to sprint velocity as a full point) - [ ] On-call primary responder independently - [ ] Participates in hiring (resume review or interview panel) - [ ] Has proposed and had merged at least one self-initiated improvement ## 90-Day Review (formal) This is a formal performance conversation: 1. Reflect on the 30-60-90 plan: what was achieved, what wasn't, and why 2. Technical assessment: where are they strong? where do they need to grow? 3. Career goals conversation: what does the developer want to work on in the next 6 months? 4. Promotion/leveling conversation if appropriate 5. Updated development plan for the next quarter **90-Day Success Criteria:** ✅ Full sprint contributor at expected velocity ✅ Has led at least one feature end-to-end ✅ Has contributed an improvement unprompted ✅ Is a full participant in hiring and team processes
Expert advice
The most common onboarding failure is under-communication, not over-communication. New developers interpret silence as 'I'm doing fine' — but they're usually confused and too afraid to ask. Schedule daily 15-minute check-ins for the first two weeks, then taper to weekly. Make it normal to not know things.
Fix your README before the new developer starts. Ask someone who hasn't set up the project recently to follow it on a fresh machine. Every place they get stuck is a documentation gap. New developers are the perfect people to improve setup docs — their fresh eyes catch every assumption the team stopped noticing.
Give real work in week one. A 'good first issue' that is actually meaningful builds more confidence than 5 tutorial tasks. The developer should feel like a contributor from day three, not day thirty.
Use Gitmore to passively track new developer ramp-up. You can see commit frequency, PR size, and cycle time in your daily reports without interrupting the developer with status check-ins. A developer whose PR count is zero in week two needs support — you'll see it in the data before they tell you.
The 30-day check-in question that reveals the most: 'What did you wish you had known on day one?' The answers expose gaps in your onboarding process that the rest of the team no longer notices. Update the plan every time you onboard someone new.
Assign CODEOWNERS ownership by day 45, not day 90. Responsibility for a real part of the codebase accelerates learning faster than any documentation. The developer who owns a service learns it deeply because they have to review every PR that touches it.
Common questions
How long should developer onboarding take?
Expect 60-90 days to reach full independent contribution for a mid-level engineer in a moderately complex codebase. Senior engineers with relevant domain experience can reach independence in 30-45 days. Junior engineers may need 90-120 days. The key metric isn't time — it's whether the developer can own and ship features without daily guidance. Rushing past 30 days rarely saves time; it usually creates hidden technical debt and silent confusion that surfaces much later.
What makes a 'good first issue' for a new developer?
A good first issue is scoped, well-defined, touches a real part of the codebase, and has a clear definition of done. It should require the developer to set up their environment, write a test, go through code review, and deploy — giving them the full workflow experience. It should NOT be a tutorial task invented for onboarding, a task so trivial it doesn't count, or a task so complex that it requires days of architecture explanation before starting. Bug fixes with a clear reproduction path are often ideal.
Should new developers join the on-call rotation immediately?
No. Shadow first, then primary. In weeks 3-4, pair the new developer with an experienced engineer who is the primary responder — the new developer observes and documents. In weeks 5-6, the new developer is primary while the experienced engineer is secondary (available to assist). Full independent on-call participation after 45-60 days is appropriate for most teams. Adding someone to on-call before they understand the system well enough to respond is unfair and produces poor incident response.
How do I track developer onboarding progress without micromanaging?
Use the 30-60-90 milestones as a structured conversation guide rather than a surveillance tool. The check-in questions ('what did you ship?', 'what's still unclear?') surface progress naturally. Gitmore provides an additional signal: you can see the developer's commit frequency, PR count, and cycle time in your team's daily reports. If week two shows zero commits, that's a flag worth addressing in a supportive 1-on-1 — without the developer feeling watched.
Should the onboarding plan be the same for contractors and full-time employees?
No. Contractors typically have shorter engagements, so time-to-contribution matters even more. Compress the timeline aggressively, skip the 90-day culture integration milestones, and focus on access setup, codebase orientation, and the specific task scope. Add two things full-time plans often skip: an explicit access expiry date with a deprovisioning checklist, and a handoff document template for when the contract ends. Document what the contractor builds more rigorously than you would for a full-time employee — knowledge transfer is your responsibility, not theirs.
More free templates
Copy-paste templates for every stage of the engineering workflow.
Weekly Sprint Report Template
Sprint goals, completed work, carry-over, metrics, blockers, and next sprint preview.
View template📋Product Changelog Template
Keep-a-Changelog format for public releases, internal builds, and GitHub releases.
View template💼Freelance Developer Weekly Report Template
Professional weekly reports for freelance developers to send to clients.
View templateAutomate Your Git Reporting
Stop filling in templates manually. Connect your git provider and let Gitmore generate reports automatically — daily, weekly, or on demand.
Get Started FreeNo credit card • No sales call • Reports in 2 minutes