A 30/60/90 day onboarding plan for software developers

You spent weeks screening, interviewing, and negotiating to hire a developer. Then, on day one, they sit waiting for a laptop, a repo invite, and someone to tell them what to work on. Weeks two and three pass in a fog of half-granted access and ticket scraps. By month three they are quietly interviewing elsewhere.

Onboarding is where hiring wins get thrown away. It is also cheap to fix, because it responds to preparation, not budget. Here is a complete plan.

Before day one: provision everything

The strongest onboarding signal you can send costs nothing: when the developer opens their laptop on day one, everything already works. That takes a checklist run the week before they start.

• Hardware ordered and delivered (for remote hires, shipped early enough to arrive with margin)
• Accounts created: email, Slack or Teams, GitHub or GitLab org, issue tracker, CI, cloud console with least-privilege roles, password manager, VPN
• Calendar populated for week one: kickoff with the manager, buddy intro, architecture walkthrough, one-on-ones already scheduled
• A written onboarding document with the plan for days 1 through 90, their first task identified, and links to the key docs
• The team told who is starting, what they will own, and who the buddy is

Assign one owner for this checklist. When access is “mostly ready,” the new hire spends day one discovering which parts are not.

The first week: environment, context, and a merged commit

Week one has three jobs: a working development environment, enough context to navigate, and one real commit merged to the main branch.

The commit matters more than it looks. It can be tiny: a typo fix, a lint cleanup, a missing null check. The point is that shipping it forces a full pass through your actual workflow: clone, branch, run locally, open a pull request, pass CI, get reviewed, merge, deploy. Every broken step in that chain surfaces in week one instead of week four, while fixing it is still clearly onboarding work and not a personal failing.

A useful side effect: ask the new hire to fix the setup documentation as they follow it. They are the only person on the team who can see the gaps, and their first pull request can literally be a better README.

Round out the week with an architecture walkthrough from a senior engineer (recorded, if remote), a product demo from the perspective of a user, and a short meeting on how work flows: how tickets get scoped, how deploys happen, what an incident looks like.

The first meaningful task

After the week-one warm-up commit, the first real task sets the tone for everything after it. Pick it deliberately, before the start date, against four criteria:

• Real. It ships to production and a user or teammate benefits. No sandboxes, no throwaway exercises.
• Scoped. Completable in three to seven days by someone new to the codebase. If your estimate for a team veteran is two days, it is about right.
• Central. It touches the main codebase and the normal workflow, not an isolated side repo nobody reviews.
• Non-blocking. Nothing on the critical path depends on it, so a slow first attempt costs nothing but time.

Good examples: a reported bug with clear reproduction steps, a small feature behind a flag, adding validation and a decent error message to a form, instrumenting an endpoint that lacks metrics, extending an existing API with one well-specified field. Bad examples: “improve test coverage” (unscoped), a greenfield microservice (isolated), or the gnarly refactor nobody else wants (a hazing ritual, not a first task).

The 30/60/90 plan

Three phases, each with a distinct goal: context, then ownership, then full contribution. Here is what each looks like when it is going well.

Days 1 to 30: context and small wins

The first month is about building an accurate mental model of the system, the product, and the team, demonstrated through a steady stream of small shipped changes.

By day 30, a well-onboarded developer has:

• A fully working local environment and the documentation fixes to prove it
• Five to ten merged pull requests of increasing size
• One meaningful task shipped to production
• Reviewed at least a couple of teammates’ pull requests, even if only with questions
• Met everyone they will work with, including the product and support people who feed the roadmap
• Sat in on the team’s recurring rituals long enough to know how decisions get made

What they should not have by day 30: sole ownership of anything critical, on-call duty, or a large project. Loading those early just converts confusion into risk.

Days 31 to 60: ownership and independence

The second month shifts from guided work to independent delivery: the developer takes a medium-sized feature from ticket to production with normal review but no special supervision.

By day 60, look for:

• One medium feature delivered end to end, including the unglamorous parts (tests, migration, docs, release notes)
• Code reviews that catch real issues, not just style
• Questions that shift from “how does this work” to “why is it this way,” which signals the mental model is formed
• A first on-call shadow shift, paired with a veteran, if your team runs on-call
• Participation in scoping and estimation with the rest of the team

This is also the month where mismatches surface honestly. If by day 60 the developer still cannot move without step-by-step direction, act on it now; it is far cheaper than at month six.

Days 61 to 90: full contribution

By the end of the first quarter, the goal is simple to state: the team would notice if this person left. Concretely, by day 90:

• They own a defined area: a service, a feature domain, or a workstream, with the team knowing they own it
• They take a normal share of on-call, incidents, and support escalations
• They contribute to technical direction: proposing changes, challenging designs, writing at least one design doc or proposal
• They can onboard the next hire in their area, which is the cleanest test of whether they actually absorbed the context
• The manager can answer “was this hire a success” with evidence rather than a feeling

Close the quarter with an explicit conversation: what the first 90 days looked like from both sides, what the next quarter’s goals are, and what growth path is on the table. Developers rarely quit companies where someone laid out their next chapter three months in.

The buddy system that actually works

A buddy is a peer assigned to be the new hire’s default human: the person for the questions that feel too small for a meeting and too dumb for a public channel. It works when four conditions hold.

The buddy is not the manager, because “is this question stupid” calculations change when the listener writes your performance review. The buddy works in the same codebase, so answers are concrete. The buddy volunteered, because a conscripted buddy answers in monosyllables. And the buddy’s time is budgeted: two to four hours a week for the first month, counted as real work in their sprint capacity, not squeezed out of their evenings.

Give the buddy a light structure: a 30 minute check-in daily for the first week, then twice weekly through the first month. Their private channel with the new hire is a pressure valve; things said there surface to the manager only as themes, never as quotes.

Documentation and access as an onboarding product

Every onboarding exposes the same truth: your documentation is worse than you think, and access granted on an “ask when blocked” basis turns every new hire’s first month into a scavenger hunt.

Treat both as products with owners. The minimum documentation set: a setup guide a new hire can follow unassisted, an architecture overview with a diagram that matches reality, a glossary of internal terms, a “how we work” doc (branching, review norms, deploy process, incident process), and a decision log for the choices people will otherwise re-litigate.

For access, maintain a role-based checklist (“backend developer gets these twelve accounts with these permission levels”) and grant it all before day one. The alternative is the new hire discovering missing access at the exact moment they need it, which is always the worst moment.

Feedback checkpoints: what to ask at 30, 60, and 90

Weekly one-on-ones run through the whole quarter, but three checkpoints deserve structure. Ask questions that surface problems while they are still cheap.

At 30 days: What has been more confusing than expected? Where did documentation lie to you? What do you know now that you wish someone had told you in week one? Is the work harder, easier, or different than what you expected from the interviews?

At 60 days: What is slowing you down that should not be? What would you change about how this team works? Do you have what you need to own your area? What have you seen us do that seems wrong, now that you still have outsider eyes?

At 90 days: What should the next quarter look like? What do you want to own that you do not yet? What almost made you regret joining, if anything did? What should we change about onboarding before the next hire?

The 90 day question about onboarding itself is not a courtesy. Feed the answers back into the checklist, and onboarding compounds instead of resetting with every hire.

Remote onboarding: make the implicit explicit

Remote onboarding is the same plan with one added rule: nothing can be absorbed by proximity, so everything must be written or scheduled.

• Ship hardware at least a week early, and have a fallback if it is late
• Record the architecture walkthrough and product demo, then keep them current; they become assets for every future hire
• Schedule more deliberate human contact in weeks one and two: short one-on-ones with each teammate, not just a group call
• Set the norm that questions go in public channels by default, and have seniors model it
• Have the buddy do a daily video check-in for the first two weeks; silence is ambiguous in an office and invisible remotely
• Watch working hours in the first month; new remote hires overwork to prove themselves until they burn out

The written onboarding document matters double here: a remote hire with a clear plan feels supported, and one without feels abandoned by day three.

The shortcut

None of this can be skipped, but part of it can be pre-paid. A big share of first-quarter anxiety, on both sides, is competence verification: the manager watching for proof the hire can really do the job, the hire performing for an audience. When a developer arrives from a vetted network like turnkey.dev, skill screening already happened before you saw a profile, so your 90 days can concentrate on what only you can teach: your codebase, your product, your customers, and your way of working. That is what onboarding is actually for. Whichever way you hire, the plan above is the difference between a hire who ships in month one and a hire who quits in month four.