30-60-90 day plan for software engineers

A 30-60-90 day plan for a software engineer should be checkable against the pull request history and the on-call schedule, not against a subjective sense of whether someone "seems to be picking it up." Below is a plan built around shipped code, review quality and on-call readiness, with a filled example and what the team owes a new engineer at each phase.

For the general new-hire version of this template across roles, see the 30-60-90 day plan template for new hires.

Why "learn the codebase" is not a milestone

Every new engineer's plan says some version of "get familiar with the codebase," and it means nothing on its own because there is no way to check it. What can be checked is what someone did with that familiarity: a merged pull request, a bug fixed, a runbook followed correctly during an incident. The plan below replaces "get familiar with X" everywhere it can with an artifact — a PR link, a ticket closed, a doc written — because artifacts are the only version of "learned it" a manager can verify without just trusting a feeling.

The 30-60-90 day plan

30-60-90 day plan — [Name], [team], [stack]
Manager: [name]        Start date: [date]        Onboarding buddy: [name]

DAYS 1-30 — Ship small, reviewed changes; learn the system by touching it
Owns:
- Local dev environment fully working by end of day 2, verified with a test deploy
- 3-5 small merged pull requests (bug fixes, small features, test coverage) with real code review
- Read and comment on 5+ teammates' pull requests, even before feeling ready to
- One documented gap found in onboarding docs, fixed in the docs themselves
Produces by day 30:
- A short written note on how the system fits together, in the new engineer's own words
- At least one merged PR per week from week two onward
Manager/team owes:
- A working dev environment on day one, or a same-day fix if it is not
- An onboarding buddy who answers questions same-day, no matter how basic
- Real code review, not rubber-stamp approvals, on every PR

DAYS 31-60 — Own a scoped feature end to end; start shadowing on-call
Owns:
- Take one feature or project from ticket to shipped, including its tests and rollout
- Shadow the on-call rotation for at least one full cycle
- Give code review comments that catch a real issue on someone else's PR, not just style notes
- Present the shipped feature at a team demo or review
Produces by day 60:
- One feature in production that the engineer can explain end to end: design, tradeoffs, tests
- Familiarity with the incident runbook, checked by walking through one past incident with a mentor
Manager/team owes:
- Scoped, well-defined work for the first owned feature, not an ambiguous, wide-open ticket
- A named on-call shadow partner and a walkthrough of the runbook before the shadow shift
- Feedback on code review comments, not just on code

DAYS 61-90 — Join the on-call rotation; take on a harder, less-scoped project
Owns:
- Join the on-call rotation as a secondary responder, with an escalation path to a senior engineer
- Take on a project with real ambiguity: unclear scope, a design decision to make, a tradeoff to own
- Unblock at least one other engineer on something the new hire now knows better than most
Produces by day 90:
- A second shipped project, this one requiring a design decision the engineer owned
- A written 90-day self-assessment: what they'd do differently, what surprised them about the system

Review cadence: weekly 1:1 with the manager; a lightweight check-in with the onboarding
buddy at day 15; formal reviews at day 30, 60 and 90 using this plan as the agenda.

A filled example: an invented backend engineer

Code review as the real signal, in both directions

What a new engineer writes in code review comments on other people's pull requests is one of the clearest early signals available, and most plans ignore it because it happens outside any ticket system. In the first 30 days, comments are mostly questions, which is correct. By day 60, a useful comment catches something real — a missing edge case, an inconsistency with how the rest of the codebase handles a similar problem — and that shift from asking to catching is worth naming explicitly in the day-60 check-in, because it usually happens before the engineer notices it themselves.

On-call readiness: a ramp, not a switch

Putting a new engineer straight onto primary on-call is a common shortcut when a team is understaffed, and it produces a bad first experience of the job: an unfamiliar system, a three a.m. page, and a runbook they have never used under real pressure. The ramp above — shadow a full cycle around day 30 to 60, join as secondary with a named escalation partner by day 90 — costs a few weeks of coverage from someone more senior, and buys a new engineer who actually trusts the runbook the first time they need it for real.

What the team owes, beyond the manager

Adapting the plan by seniority and stack

• Junior or new-grad hires: extend the shadowing and code-review-reading phase, and treat one well-scoped, independently shipped feature by day 90 as a strong result rather than the floor.
• Senior hires: the day-90 bar should include unblocking others and influencing a design decision beyond their own project, not just shipping more code faster.
• Unfamiliar stack or language: add an explicit day-15 checkpoint on basic fluency (can write and debug small programs unassisted) before layering on the system-specific milestones.
• Remote-first teams: replace "team demo" with a recorded walkthrough or a written design doc reviewed asynchronously, and shorten the async response-time expectations in the plan itself so the new hire knows what "same day" means across time zones.
• Platform or infrastructure teams: "shipped a feature" may not fit; replace it with a concrete reliability or tooling improvement other engineers can point to, such as a build time reduction or a new internal tool that removes a manual step.

Whichever variation applies, write the adapted milestones down in the plan itself rather than keeping the adjustment in the manager's head. A new hire comparing notes with a peer on a different team, under a different version of the same plan, should be able to see why their bar is different rather than assume the difference is about them personally.

Common mistakes that stall a new engineer

The most common mistake is a broken or incomplete dev environment that eats the first week and never gets fully fixed, because everyone assumes someone else is handling it. Ask directly on day one whether the environment actually works end to end, including a real deploy to a test environment, rather than trusting a checklist that says setup is done. A close second is handing a new hire's first project with no clear scope, on the theory that ambiguity is realistic and good practice. It is realistic, but a new hire has no context yet to resolve it, and a month spent guessing at requirements looks like slow progress when it is really a scoping failure on the manager's side.

A third mistake is silent code review: approving pull requests with no comments at all, either to be polite or because reviewing carefully takes time nobody budgeted for onboarding. A new engineer whose early PRs sail through without real feedback learns nothing about the team's actual standards until a much later PR gets rejected for reasons that were true all along and simply never said out loud.

Reviewing the plan without turning it into a scorecard

The day 30, 60 and 90 conversations work best as a walk through the artifacts — the merged PRs, the shipped feature, the on-call shadow log — rather than a rating exercise. Ask the engineer to pick the PR or decision they are proudest of and the one they would redo differently; both answers tell a manager more about judgment and self-awareness than a checklist of completed tasks does, and they turn the review into a conversation the engineer has a stake in rather than a report card handed down.