Template and Guide
30-60-90 Day Plan for Software Engineers
A developer-specific 30-60-90 plan with real engineering milestones, not generic HR goals. Includes seniority-specific templates, manager checkpoints, and red flags to watch for.
Why this works: Developers with a clear 30-60-90 plan ramp 20-30% faster than those without one. The structure reduces ambiguity, provides measurable milestones, and gives both the new hire and manager a shared definition of success.
Day 1-30: Learn
Goal: Build context and make first contributions
Junior Engineer
- Development environment fully operational by day 3
- First PR merged (documentation, test, or small bug fix) by day 5
- Architecture overview completed, high-level understanding of 3+ core modules
- Attended all team ceremonies (standup, retro, planning) at least twice
- Submitted 3-5 PRs with progressively increasing scope
- Identified personal knowledge gaps and created a learning plan with buddy
Mid-Level Engineer
- Development environment operational by day 2, first PR merged by day 3
- Architecture deep-dive on 5+ modules with tech lead
- First feature-level PR merged by end of week 2
- Sprint commitments started (reduced scope: 50-60% of team average)
- Code review quality approaching team standard
- Data model and deployment pipeline independently understood
Senior Engineer
- First PR merged by day 2, feature work starting by day 4
- Architecture fully understood at system level, deep knowledge of 3+ subsystems
- Independently deploying to staging by end of week 1
- Contributing to architectural discussions by week 2
- Identified 2-3 improvement opportunities in codebase or process
- Established working relationships with key stakeholders outside the team
Staff Engineer
- First code contribution by day 3 (signal, not goal)
- Met with 8-10 stakeholders across engineering and product
- Reviewed all active RFCs and architecture decision records
- Attended leadership meetings and understood strategic priorities
- Identified cross-team dependencies and friction points
- Drafted initial observations document (private, shared with manager)
Manager Checkpoint
Are they blocked on anything? Do they have a buddy who is responsive? Have they merged at least one PR? Are they attending ceremonies? Any early red flags (isolation, frustration, excessive hand-holding)?
Red Flags
- No PR submitted by end of week 2
- Not asking questions (may indicate confusion or disengagement)
- Environment still not working by day 5
- Buddy relationship not established
Day 31-60: Build
Goal: Deliver features and build team trust
Junior Engineer
- First full feature owned end-to-end (with guidance)
- Sprint velocity at 40-50% of team average
- Rework rate dropped below 20% on PRs
- Writing tests alongside all feature work
- Able to debug basic production issues with support
- 60-day check-in completed with manager
Mid-Level Engineer
- Multiple features delivered end-to-end
- Sprint velocity at 60-75% of team average
- Code review quality meeting team standard
- Independently debugging production issues
- Contributing to technical design discussions
- Starting to identify and propose improvements
Senior Engineer
- Leading feature delivery with minimal oversight
- Sprint velocity at 80-90% of team average
- Technical design contributions driving team decisions
- Mentoring junior team members informally
- On-call rotation active (with backup initially)
- First process or architecture improvement proposed
Staff Engineer
- First cross-team initiative proposed or joined
- Technical strategy document drafted for one key area
- Established as a trusted voice in architecture discussions
- Building relationships with product and platform counterparts
- Coaching one or more team members on technical topics
- Impact area clearly defined and agreed with engineering leadership
Manager Checkpoint
Is velocity trending upward? Are they getting positive code review feedback? Do they seem engaged and motivated? Any concerns from the buddy or team? Are 30-day milestones met?
Red Flags
- Velocity flat or declining
- Consistently missing sprint commitments
- Not participating in discussions (passive)
- Quality not improving despite feedback
Day 61-90: Lead
Goal: Reach full velocity and own outcomes
Junior Engineer
- Sprint velocity at 70-85% of team average
- End-to-end feature ownership without daily guidance
- Contributing meaningfully to code reviews
- Knowledge sharing: documented at least one process or system
- 90-day review completed and onboarding marked complete
- Continued learning plan agreed for next quarter
Mid-Level Engineer
- Sprint velocity at 85-95% of team average
- Owning complex features end-to-end
- Driving technical decisions within their scope
- On-call rotation fully active
- 90-day review completed and onboarding marked complete
- Career development goals discussed with manager
Senior Engineer
- Full velocity: delivering at team average or above
- Leading technical design for new features
- Proactively improving code quality, testing, and documentation
- Mentoring team members, participating in hiring if relevant
- Cross-team collaboration established
- Onboarding complete, focus shifts to long-term impact
Staff Engineer
- Cross-team initiative showing early results
- Recognised as technical authority in their area
- Influencing engineering roadmap and technical direction
- Established regular sync with VP/Director of Engineering
- Full organisational context: understands why things are the way they are
- Long-term impact plan (6-12 month horizon) drafted and agreed
Manager Checkpoint
Are they meeting the 90% velocity target? Are they engaged beyond just ticket work? Any retention risks? Is the team better for having them? Formal 90-day review must happen this week.
Red Flags
- Velocity still below 70% at day 90
- Disengagement signals (declining participation, withdrawn)
- Quality concerns not addressed despite feedback
- No feature ownership demonstrated
Common 30-60-90 Plan Mistakes
Too vague
Goals like 'get familiar with the codebase' are not measurable. Replace with 'merge 3 PRs and complete architecture walkthrough for 5 modules by day 30.'
No success criteria
Each milestone needs a definition of done. 'Feature work started' is ambiguous. 'First feature PR approved by two reviewers and merged to main' is concrete.
No regular check-ins
Without structured 30, 60, and 90-day reviews, problems go undetected until it is too late to course-correct. Calendar these on day one.
One-size-fits-all across seniority
A junior developer and a staff engineer need fundamentally different plans. Using the same template for both leads to either overwhelming juniors or under-challenging seniors.
Ignoring the buddy role
The plan should define what the buddy does, not just what the new hire does. Without buddy accountability, the plan becomes a solo assignment.