The best way to approach onboarding software developers is to treat the first 90 days as a sequence. Get access and equipment ready before day one, get a small change into production in week one, and raise the difficulty of the work in 30-day steps against written goals. Pair every hire with a buddy, keep the setup guide in the repo, and ask each new developer to fix whatever in it is wrong.
Most teams do the opposite. The laptop arrives late, repository access takes three tickets, the README is two years old, and the new hire spends a week reading and waiting. Developers feel this quickly because their work depends on tools, environments and context that a general HR orientation never covers. A slow start creates early doubt, and early doubt is how teams lose people in their first year.
This guide walks you through the process in four steps, with an access checklist, a copy-paste onboarding doc template, a 30-60-90 table and a set of metrics. At Atrixware we build Axis LMS, a learning management system, so we also cover the part of onboarding that is training rather than code: policies, security and compliance courses.
Why developers need their own onboarding plan
Developer onboarding takes a new engineer from signed offer to trusted, independent contributor. It needs its own plan because the work depends on environments, access and codebase knowledge that general onboarding never touches.
What developer onboarding has to achieve
Your plan has two milestones: a first production change in week one and independent work by day 90. Everything else supports those two. Culture, introductions and policy matter, but a developer who ships something small in the first days gains confidence that no welcome lunch can match.
If you can only fix one thing, make sure the new hire ships something real in week one.
Timing varies by person. A senior engineer who knows your stack can contribute within a few weeks, while a junior hire or a large legacy codebase can stretch full ramp-up to several months. Plan 90 days of structured support for everyone, and let strong hires skip stages instead of leaving weaker hires without them.
What to line up before you start
Five things should exist before the start date:
- An owner, usually the hiring manager, who is accountable for the plan.
- A buddy with time blocked on their calendar, roughly an hour or two a day in week one.
- A setup guide that someone has tested on a clean machine.
- A list of starter tickets, each sized at a few hours to two days.
- A written 30-60-90 plan with goals for each stage.
If one of these is missing, build it first. An untested setup guide alone can eat most of a new hire’s first week, and a buddy with no spare time is only a name on a slide.
Step 1. Prepare access and equipment before day one
Start the clock when the offer is accepted, not on the first day. The aim of this step is simple: the new developer opens the laptop on day one and everything works.
Order hardware and request access early
Order and ship equipment at least two weeks before the start date. For remote hires, confirm delivery a few days ahead, so a courier delay does not become a lost week. Create accounts the week before, using least privilege with a clear path to more. The hire gets what the first project needs now, and wider rights follow after their first reviewed deploy.
Use this access checklist:
- Source control, with permissions on the repos for the first project
- CI/CD pipeline and issue tracker
- Chat, email, calendar and video
- Staging or cloud environments, with limited roles
- Password manager, SSO and VPN
- Monitoring and logging dashboards, read-only at first
- Development API keys and sample data, never production secrets
Day one goes well only when access was granted the day before.
Clear paperwork and required training early
Send contracts and HR forms for e-signature before the start date, so the first morning goes to the team and the codebase. Then list the required non-code training: security awareness, data handling, your code of conduct, and any regulatory courses that apply to your industry.
Schedule that training in short slots during week one rather than as a single block on day one. If you hire often, a learning management system can assign these courses automatically, track completion and report on it. Axis LMS, for example, is built to create, manage and track online training for employees, which keeps engineering managers out of the spreadsheet business.
Step 2. Run a first week built around a first commit
A good first week has one goal: a merged pull request by Friday. Everything in the schedule should make that goal easier, including setup, introductions and pairing.
Give day one a plan the hire can follow alone
Write the plan down in one onboarding document that lives in the repo or your wiki. This template works for most teams:
# Onboarding: [Team name]
## Before you start
- Laptop and accounts checklist: [link]
- Setup guide: [link]
## Day 1
- 9:30 Welcome with [manager]
- 10:30 Environment setup with [buddy]
- 13:00 Team lunch or video hangout
- 14:00 Architecture overview (45 min)
- Goal: the app runs locally and the tests pass
## Week 1
- Goal: first pull request merged
- Starter tickets: [link to "good first ticket" label]
- Daily 15-minute check-in with [buddy]
## Who to ask
- Buddy: [name, handle]
- Manager: [name, handle]
- Access or tooling problems: [channel]
## Reading list
- Architecture diagram: [link]
- Coding standards: [link]
- Deployment process: [link]
Tell the new hire that this document is theirs to improve. Every broken setup step they fix is a pull request, and a documentation fix is a perfectly good first contribution.
Pair them with a buddy and a real starter ticket
Pick a buddy who joined in the last year or two rather than your busiest senior. Recent joiners remember what was confusing, and they are more likely to have time. Use pair programming for the first sessions so the buddy shows how work actually flows, instead of fixing problems on the hire’s behalf.
The starter ticket matters as much as the buddy. Choose something small and well defined that travels the full path through review, CI and deployment. Label these tickets so you always have a few ready. A real deploy in week one removes the fear of pushing code that many new hires carry.
Adjust the first week for remote developers
Remote hires need the same plan with more written structure. Define core overlap hours, state where questions go, and keep the daily buddy check-in short and on video. Put recorded architecture walkthroughs in the doc so a hire in another time zone is not waiting on a live session. Silence is the main risk in remote onboarding, so ask direct questions and do not wait for the hire to speak up.
Step 3. Ramp up the work in 30, 60 and 90 days
Increase scope in three stages and write the goals for each stage down. A new developer who knows what success looks like at day 30 will spend far less energy guessing. The table below is a template you can adapt.
| Period | Focus | Example goal | Check-in |
|---|---|---|---|
| Days 1 to 30 | Learn the workflow and codebase | Several small tickets merged, one production deploy | Weekly 1:1, buddy feedback |
| Days 31 to 60 | Own a small feature | Delivers a scoped feature with normal review turnaround, shadows on-call | Mid-point review |
| Days 61 to 90 | Work independently | Estimates and delivers a medium task, contributes in planning | 90-day review, feedback from the hire |
Written goals at 30, 60 and 90 days turn "how am I doing?" into a conversation instead of a worry.
Teach the codebase in layers
Start with the big picture: a diagram of services, data stores and deploy targets. Next, have the buddy trace one real request from the browser to the database. After that, point the hire to the tests, which often document behavior better than the prose does.
Use code review as teaching. Explain the reasoning in review comments, link to your standards, and note which team conventions are habit and which are rules. For role-specific depth, give frontend hires the design system and component library, backend hires the API and data model guides, and mobile hires the release process for each platform.
Skill gaps will show up around day 30. If several hires need the same background, a course collection can fill the gap faster than ad hoc mentoring. Atrixware’s Tech and Digital Skills collection has 20 courses and integrates with Axis LMS, so check its course list against your stack before you build your own.
Keep one-on-ones and feedback regular
Hold a weekly one-on-one for the first 90 days. Use the same three questions each time: what is blocking you, what was confusing this week, and what do you want to learn next. Keep a running note, because patterns appear fast.
Run a more formal mid-point review around day 45 to 60. Compare progress to the written goals, say plainly where the hire is ahead or behind, and agree on the next steps. Early honest feedback prevents the surprise at day 90 that damages trust.
Step 4. Measure results and fix the process
Track a few numbers, ask the hire for feedback at fixed points, and fix the biggest friction first. Onboarding that is never measured slowly rots as tools and team members change.
Track a short list of metrics
These metrics are easy to pull from tools you already use:
| Metric | How to measure it | What a bad number tells you |
|---|---|---|
| Time to first merged PR | Days from start date to first merge | Setup or starter tickets are broken |
| Time to first production deploy | Days from start date to first release | Access or release process is too slow |
| Time to independent task | Days until a medium task ships without hand-holding | The codebase is not being explained well |
| Review feedback themes | Recurring comments on early PRs | A standard is undocumented |
| New hire satisfaction | Short survey at 2 weeks, 30 and 90 days | Support or clarity is missing |
| Retention | Share of hires still present at 6 and 12 months | Onboarding or role fit is failing |
Set your own targets from your first few hires. Time to first merged PR is the most useful early signal, because a long delay almost always points to a fixable setup problem.
Treat a slow first pull request as a bug in your onboarding, not a flaw in the hire.
Review the process after every hire
Hold a short retrospective with the new developer at day 30 and again at day 90. Ask what slowed them down, which document was wrong, and what they would cut. Then assign one owner to make the changes within a week, so feedback visibly leads to action.
Watch for the usual mistakes:
- Filling week one with meetings and leaving no time to code
- Choosing the busiest senior as buddy
- Giving production access with no guardrails
- Letting the setup guide go stale between hires
- Skipping the 30 and 60 day check-ins once the hire "seems fine"
Start with the first week
Good developer onboarding comes down to four moves. Prepare access before day one, build week one around a first merged pull request, raise the scope in written 30-60-90 stages, and measure what happened so the next hire has an easier start. None of it requires a big budget, only an owner, a buddy with time and a document that stays current.
The non-code part of onboarding, such as security, policy and compliance training, is the easiest to automate. If you want to see how much of your training process a learning platform could take over, take the LMS readiness quiz to find out where you are in the process.
