What a 30 60 90 day plan should deliver

A 30 60 90 day plan organizes onboarding into three focused windows so engineers learn the codebase, ship meaningful work, and assume ownership without guesswork. The plan aligns new hire priorities with manager expectations, makes progress visible, and reduces lost time caused by unclear goals or missing access.

How to use this plan

Share a written plan on day one and review it during weekly check ins. Treat it as a living document. The new engineer owns updates to personal learning goals. The manager owns removing blockers, giving feedback, and validating ramp signals.

Core principles before the timeline

Prioritize small wins early to build confidence and collect context for larger work. Keep responsibilities narrow in the first 30 days to avoid overwhelm. Measure learning with outcomes rather than hours spent. Outcomes can be building, shipping, explaining, or teaching.

Detailed 30 60 90 day timeline

Days 1 to 30: Learn, connect, and ship a first change

Goals in this window focus on environment setup, team integration, and the first shipped contribution.

• Get operational: Confirm all accounts and permissions, set up local development environment, learn CI and deploy flows, and confirm ability to run tests and deploy to a staging environment.
• Build context: Read the architecture overview, key service READMEs, recent incident reports, and a prioritized list of relevant tickets.
• Connect to people: Meet the buddy, primary reviewer, product partner, and the person responsible for the largest dependent system.
• Ship a first change: Deliver a small but real contribution such as a bug fix, test improvements, documentation correction, or a tiny feature. The goal is shipping through the full pipeline and following the team flow including code review and release notes.
• Manager actions: Provide a starter ticket, ensure reviewer availability, schedule brief daily or alternate day check ins, and confirm access to observability and alerting dashboards.

Days 31 to 60: Increase scope and reduce guidance

This window emphasizes taking on larger tasks, owning parts of a feature, and improving collaboration skills.

• Tackle a medium scoped feature or refactor: Work on a task that touches multiple files or systems with a clear spec and acceptance criteria. Lead one code review and respond to feedback in a timely way.
• Understand product intent: Attend product planning or roadmap sessions, discuss trade offs with product, and explain how the work you did affects users.
• Increase testing and observability work: Add or improve tests, add basic monitoring or logging, and confirm you can interpret metrics for the services you touched.
• Contribute to team practices: Share one suggestion for improving the onboarding docs, CI pipeline, or runbook. Pair with another engineer on a design or debugging session.
• Manager actions: Start transitioning ticket selection to the engineer, reduce the frequency of guided check ins to weekly, and give feedback oriented to career growth not only immediate tasks.

Days 61 to 90: Own a meaningful area and demonstrate autonomy

The final window expects reliable, independent work and visible preparation to take on recurring responsibilities.

• Own a component or backlog slice: Be responsible for scoping, delivering, and maintaining a small but meaningful area. This includes monitoring and handling follow up incident tasks if they arise.
• Lead a cross functional task: Drive a design review, coordinate with product and QA, and shepherd the work to completion.
• Show operational readiness: Respond to a simulated page or perform an on call shadow session. Update or create a runbook for the area you now own.
• Share learning: Give a short walkthrough or document a post implementation note that explains architecture, trade offs, and common pitfalls.
• Manager actions: Conduct a formal 90 day review focused on demonstrated outcomes, set medium term goals for the next six months, and confirm career path interests.

Sample measurable ramp signals

Use concrete evidence rather than impressions to decide readiness. Examples of ramp signals are practical and observable.

1. Successfully built, tested, and deployed at least one change from development to staging or production using the normal team pipeline.
2. Completed code review cycles as author and reviewer with comments addressed within agreed SLAs.
3. Explained the main data flows and failure modes for the area in a design walkthrough to peers.
4. Taken ownership of at least one bug or operational alert and followed through to resolution with a postmortem note or learning item.
5. Contributed a concrete improvement to documentation, tests, or CI that reduced friction for future contributors.

Templates you can copy

Below are concise templates for manager and engineer to agree on during week one. Keep entries short and measurable.

• Week one manager to do: Provide access and a starter ticket that should be review ready inside two weeks.
• Engineer personal goals: Set three goals such as environment setup, ship first change, and document a learning topic. State acceptance criteria for each goal.
• Weekly check in agenda: Blockers, progress on outcomes, code review feedback, next week focus, and any support needed from manager or team.

Common pitfalls and how to avoid them

New hire ramp slows when managers leave goals vague or when the team dumps chaotic work into the new engineer queue. Prevent common failures with these actions.

• Pitfall New hire is given only vague tasks. Fix Always attach acceptance criteria and expected stakeholders for every ticket assigned.
• Pitfall Access problems block progress. Fix Pre onboard by ensuring accounts are provisioned before day one and verify essential access in a checklist.
• Pitfall New hire is isolated. Fix Schedule recurring pairing sessions and introduce them to cross functional partners in the first two weeks.
• Pitfall Manager does not give feedback. Fix Commit to weekly 30 minute check ins and a 90 day review with written notes and next steps.

Adapting the plan for seniority and remote hires

Adjust scope and speed based on experience. More senior engineers should get larger early tickets and faster ownership targets. Junior engineers need more guided tasks and frequent feedback. For remote hires, increase synchronous onboarding touch points during the first two weeks and provide a richer set of recorded orientation materials.

People Also Ask style questions

How do you measure success at 30 60 90 days?

Measure success using the ramp signals above. Focus on shipped changes, ability to navigate the codebase and systems, participation in team processes, and the ability to resolve or escalate operational issues.

What should a software engineer accomplish in the first 90 days?

By 90 days a healthy expectation is that the engineer can independently deliver medium sized work, own a component or backlog slice, participate constructively in design and code review, and respond to operational incidents for their area.

Who should own the 30 60 90 day plan?

The plan is a shared artifact. The manager owns providing context and removing blockers. The engineer owns updating progress and raising realistic timelines. The buddy or mentor supports day to day learning and quick answers.

Checklist for managers to run a low friction onboarding

• Pre onboard: accounts, access, and a ready starter ticket.
• Day one: review the 30 60 90 plan together and confirm buddy assignment.
• Weekly: short structured check ins using the same agenda so progress is visible.
• At 90 days: hold a written review rooted in outcomes and set next milestones.

Next steps after 90 days

Move from onboarding goals to medium term objectives such as owning a service, contributing to architectural decisions, mentoring others, or leading a cross functional initiative. Translate outcomes into a 6 month plan aligned to the engineer career path and team priorities.

Practical example: first 30 day ticket list for a backend engineer

• Set up local environment and run test suite within one hour of first try or note blockers.
• Fix a high value non critical bug and get it merged following the standard review flow.
• Improve a README that trips new contributors and link it to the onboarding doc.

How to scale this across a hiring wave

When several hires start at once, appoint shared buddies, run cohort onboarding sessions for common topics, and track ramp signals in a simple spreadsheet so managers can compare evidence and share learnings for faster improvements to the onboarding system.

Frequently used artifacts to maintain

• Starter ticket template
• Access checklist
• 90 day review template
• Runbook ownership tracker

Where to begin today

Write a brief 30 60 90 plan for your next new hire before their start date. Keep it one page. Make two items measurable. Schedule the first weekly check in and assign a buddy. Small, early structure yields the fastest ramp.