Levels and expectations
The first 90 days
Agree 30/60/90 outcomes with your manager so ramp is visible, not a vibe.
The first three months set a reputation that is hard to rewrite. People form a quiet model of you: do they get unstuck, ship, and leave things clearer? Ramping up is building enough mental model to change the system safely — not finishing an onboarding checklist.
Agree a 30/60/90 plan with your manager in week one. Named outcomes become a coaching conversation. Vague "ramp up well" becomes negotiable disappointment.
Walking through the windows
Timelines flex with codebase size and seniority. The shape stays stable.
| Window | Primary goal | Concrete signals |
|---|---|---|
| Days 1–30 | Orientation + first ship | Local env works; you can explain the main request path; one real change merged and deployed; you know owners for adjacent systems |
| Days 31–60 | Independent contribution | Normal-sized tasks with decreasing help; fewer "where does this live?" review comments; you have shadowed on-call or read recent incidents |
| Days 61–90 | Owned slice | A small feature end to end; you can debug in this stack; your onboarding notes help the next hire |
Senior hires compress the calendar. Juniors may stretch exploration. The non-negotiable is the same: do not stay invisible. Silence reads as stuckness even when you are learning hard.
Write the goals in a shared doc. In 1:1s, report what you can now explain, what you shipped, where you are blocked, and what you will try next week. That habit later becomes normal project status.
If after 60 days you still cannot run the main app or deploy, escalate as a systems problem — access, broken docs, missing buddy time — not as personal shame. Good teams fix onboarding when newcomers show specific blockers.
Common mistakes
- Optimizing for vibes. "I think it is going well" is not a signal. Named outcomes are.
- Staying quiet while learning. People cannot see your notes. They can see PRs and written updates.
- Never updating the 30/60/90 doc when reality diverges. Adjust it explicitly with your manager.
Check yourself
Day 25, you have read a lot and opened zero PRs. What is missing?
A first production change — and a written update that you are stuck finding one.
After 60 days the app still will not run locally. Is that your failure?
Treat it as a systems problem: access, docs, or buddy time. Escalate with specifics.
Key takeaways
- Align on 30/60/90 outcomes in week one; write them down.
- Days 1–30: first ship. Days 31–60: independent tasks. Days 61–90: an owned slice.
- Silence reads as stuckness. Make ramp observable.
- Broken onboarding is a team problem once you can name the blocker.
Further learning
Related
Ramping up on a new team and codebase
Your first 90 days: read code by tracing paths, ask well, ship early, and map people as well as systems.
Reading an unfamiliar codebase
Trace one request from an entry point. Tests and git history beat reading src/ top to bottom.
What the levels mean
Junior, SDE2, SDE3 and staff: scope, autonomy, impact and influence at each level.