Why a 30 60 90 onboarding plan matters

New software engineers need a clear line of sight from day one to what success looks like. A practical 30 60 90 plan gives a shared set of expectations for the engineer, their manager, and a mentor so early work delivers value, knowledge transfer happens deliberately, and risks are contained while the engineer learns the codebase and the product domain.

How to use this plan

This plan separates goals into three windows: first 30 days for orientation and small contributions, days 31 to 60 for ownership of a modest area, and days 61 to 90 for independent delivery and forward planning. The engineer, manager, and mentor should use the same checklist during weekly check ins and the formal 30 day and 60 day reviews. Adjust scope to match experience level, codebase size, and business risk.

Roles and expectations

• New engineer: learn the product, fix small bugs, submit a first pull request, and document where decisions are made.
• Manager: set priority outcomes, remove blockers, give timely feedback, and run the formal 30 60 90 reviews.
• Mentor or buddy: provide context, pair on tasks, review code with a focus on learning, and point to useful docs and tests.

First 30 days focus

Primary objective is safe orientation. The engineer should be able to run the app locally, ship a small change, and understand release and incident processes.

Core activities

• Complete account and tool access for source control, CI, ticketing, and chat.
• Run the development environment locally and validate a minimal end to end workflow.
• Read architecture overview and recent design docs for the code areas assigned.
• Pair on a small bug or documentation change and submit the first pull request.
• Attend onboarding sessions for product, security, testing, and release processes.

Success signals

• Can build and run the product locally without blocking others.
• First pull request merged following team standards and code review.
• Demonstrates awareness of the release pipeline and how to trace a production issue.

Days 31 to 60 focus

Primary objective is deeper ownership. The engineer should deliver a small but meaningful feature or a set of bug fixes and begin contributing to design discussions.

Core activities

• Own an end to end ticket that includes design, implementation, tests, and release notes.
• Increase participation in code reviews by both requesting and providing feedback.
• Pair regularly with teammates on onboarding tasks that expose cross team knowledge.
• Write or update documentation where gaps were discovered during the first 30 days.

Success signals

• Delivers a complete change that passed CI and went through the normal release process.
• Receives specific, actionable feedback in code review and iterates quickly.
• Starts to answer basic domain questions from other new hires or interns.

Days 61 to 90 focus

Primary objective is independent contribution and forward planning. The engineer should be trusted to scope work, make trade offs within agreed constraints, and suggest improvements to team practices.

Core activities

• Lead a small project or a significant component of a larger feature from design to release.
• Proactively identify one aspect of the onboarding experience or documentation to improve and deliver that improvement.
• Participate in prioritization and grooming conversations with clear trade off reasoning.
• Demonstrate reliable time to complete typical tickets for the assigned area.

Success signals

• Completes a non trivial feature or set of improvements with minimal managerial hand holding.
• Can explain the system design choices and trade offs for the owned area to peers.
• Receives recognition from teammates for consistent review quality and collaboration.

Sample week by week timeline for the first 30 days

1. Week 1 Focus on access, dev environment, orientation sessions, meet the team, and a first small pairing session.
2. Week 2 Tackle a small bug, submit first pull request, attend product and release walkthroughs, and have a 30 day expectations check in.
3. Week 3 Rotate through code review, add unit or integration tests, and shadow on call handoff or incident readout if appropriate.
4. Week 4 Finish a slightly larger ticket, update a doc page, and prepare for a 30 day review with concrete ramp signals and blockers.

Meeting and review structure

Scheduled touch points make progress visible and reduce uncertainty. Keep meetings time boxed and outcome oriented.

Weekly check in

• Time box 30 minutes.
• Engineer shares progress, blockers, and next week plan.
• Manager and mentor surface resources and remove blockers.

30 day review

• Document what the engineer completed, remaining gaps, and updated 60 day goals.
• Agree on measurable acceptance criteria for the next window.

60 day review

• Assess ownership of a service or feature, review code quality and testing practices, and set 90 day outcomes focused on independent delivery.

Onboarding checklists for manager and mentor

Manager checklist

• Set clear priority outcomes for each window and share them with the engineer.
• Arrange a mentor and schedule regular pairing sessions.
• Ensure access to tools and necessary documents before day one where possible.
• Hold the 30 day and 60 day alignment reviews and adjust goals based on reality.

Mentor checklist

• Run an architecture tour and point to the most important code paths and tests.
• Pair on the engineer’s first pull requests and provide review guidance focused on learning.
• Keep a running list of suggested bite sized tasks that increase ownership safely.

Common pitfalls and how to avoid them

• Assigning too large a project too early. Avoid by breaking work into end to end pieces and pairing first.
• Assuming environment setup will be smooth. Provide a verified, documented checklist and a quick escalation path for access issues.
• Focusing only on code without product context. Schedule product walkthroughs that explain customer value and common failure modes.

Ramp metrics and signals to watch

Quantitative metrics can complement qualitative feedback but avoid using them in isolation. Consider these indicators to judge progress.

• Time to first merged pull request.
• Number of meaningful code reviews completed and reviews authored.
• Frequency of builds and passing CI for the engineer’s changes.
• Time to resolve assigned tickets in the owned area compared to team baseline.
• Confidence in on call or rollback procedures demonstrated via shadowing or drills.

Templates you can copy quickly

30 day goals template

1. Environment setup and validation checklist completed.
2. One bug fix or doc change merged with passing CI.
3. Attended product and release walkthroughs and can explain the release process.

60 day goals template

1. Own one end to end ticket including tests and release notes.
2. Contribute at least three code reviews and respond to review feedback promptly.
3. Update or add documentation for common developer tasks in the owned area.

90 day goals template

1. Lead a small feature or significant component and shepherd it to production.
2. Improve one onboarding artifact or test to reduce future ramp time.
3. Participate in prioritization discussions with clear trade offs and estimates.

Practical tips to shorten ramp time

• Automate environment setup and provide a minimal working example that exercises the full path from code change to production deploy.
• Create a curated list of three high value pull requests to read that illustrate team conventions and typical patterns.
• Use short lived pairing sessions focused on one learning objective rather than open ended reviews.

When to extend the plan

Not every engineer will hit the same milestones at the same pace. Extend goals when the engineer needs more time to understand the domain, when the codebase is unusually large, or when business risk is high for the assigned area. Recalibrate expectations during the formal reviews and document the new milestones.

Begin using this plan with the next new hire by scheduling a mentor in advance, preparing the environment checklist, and agreeing the first 30 day ticket before the new engineer starts.