Levels and expectations
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.
The first three months set a reputation that is hard to rewrite. People form a quiet model: Do they get unstuck? Do they ship? Can I give them something ambiguous? Ramping up is not finishing the onboarding checklist. It is building enough mental model to change the system safely, learning how work actually moves, and becoming someone the team trusts with real tickets.
Code is only half the map. The other half is who owns what when it breaks. In the first two weeks, draw an ugly personal diagram: your team's services and data stores, upstream and downstream dependencies, on-call and Slack channels, PM and partner contacts, and where decisions happen. Ask your buddy or manager to correct it. Wrong labels early are cheap. Wrong ownership during an incident is expensive.
Concept
On-call is the rotation of engineers who respond to production alerts for a service. Even before you hold the pager alone, reading recent pages teaches failure modes faster than happy-path tutorials.
| Artifact | Where to look |
|---|---|
| Service ownership | Catalog, CODEOWNERS, team wiki |
| Deploy path | CI config, release channel, feature-flag tool |
| Truth for prod | Dashboards, SLO docs, last three postmortems |
| Product intent | Recent PRDs, roadmap, customer tickets |
Technical onboarding without social onboarding leaves you blocked on people you have never met. In the first month, schedule short 1:1s (15–25 minutes) with every engineer on your immediate team, your PM and designer, and at least one person on each neighboring team you will touch. Ask what they own, what is fragile, what they wish newcomers knew, and how they like to get questions. You are building a routing table for future blockers.
Concepts in this section
Read them in order. Each one builds on the one before.
| Step | Concept | What it answers |
|---|---|---|
| 1 | The first 90 days | What good looks like at day 30, 60, and 90? |
| 2 | Reading an unfamiliar codebase | How do you learn a repo without reading every file? |
| 3 | Asking good questions | How do you get help without burning goodwill? |
| 4 | Ship something small in week one | Why does a tiny production change beat a tutorial app? |
Also learn the team's communication norms — where decisions are written, what belongs in Slack versus docs. See communication.
Common mistakes
- Invisible learner. No PRs, vague status. Force a week-one ship and daily written updates.
- Question flood. Time-box, batch, show attempts.
- Only befriending seniors. Meet the people who will review your PRs.
- Perfecting tools instead of shipping. Cap setup time.
Key takeaways
- Align on 30/60/90 outcomes. Do not optimize for vibes.
- Trace entry points and one request. Draw systems and owners.
- Ask well, then ship a small real change in week one.
- Relationships and a better onboarding doc are part of the job.
Further learning
How to ask good questions (Julia Evans)How to ask good questionsJulia EvansPatricia Aas on reading other people's code with curiosity instead of contempt:
Related
What the levels mean
Junior, SDE2, SDE3 and staff: scope, autonomy, impact and influence at each level.
Debugging
A scientific loop for finding bugs fast — reproduce, hypothesize, bisect, instrument — from local failures to production incidents without making things worse.
Written and verbal communication
Lead with the point, write for skimmers, and adjust depth for engineers, PMs and executives.