The first 90 days on a new team set a trajectory that's disproportionately hard to correct later. Move too cautiously and you get read as low-impact past the point where that read is easy to shake. Move too fast and you ship a change that breaks something because you didn't yet understand why the code was written that way, and that becomes the story people tell about you. The engineers who handle this well aren't necessarily the most technically skilled — they're the ones who sequence their first three months deliberately instead of defaulting to whatever felt urgent that week.
Weeks 1-3: map before you touch
Resist the pull to start fixing things immediately, even when you spot something that looks obviously wrong — it usually isn't as obvious as it looks, and being visibly wrong about your first opinion costs more credibility than staying quiet would have. Spend the early weeks building a real map: read the incident history to learn what's actually broken versus what just looks ugly, sit in on planning and standups as an observer, and have one-on-ones with everyone on the team asking what's working, what's frustrating, and what they'd fix if they had the time. That last question is worth asking of every person individually — the answers reveal both the real problems and where opinions diverge, which tells you a lot about the team's dynamics before you've said anything that could be held against you.
Weeks 4-8: ship something small and real
The first shipped change should be small enough to be low-risk but real enough to prove you can navigate the codebase, the review process, and the deploy pipeline end to end. This is where you start building the credibility that later, bigger changes will draw on. Pick something with a visible, bounded outcome — a bug with a clear repro, a small feature with a defined spec — rather than a big refactor, even if the refactor is the more interesting problem. Refactors invite second-guessing from people who don't yet trust your judgment; a well-executed small fix builds the trust that makes the refactor possible later.
This is also the window to learn the team's real process, not the documented one. Every team has an official code review policy and an actual one — who really needs to approve a database migration, which CI failures people ignore and which ones block everything, who to loop in before touching the payments code even if the ownership docs don't say so. You learn this by paying attention and asking, not by assuming the wiki is current.
Weeks 9-12: start contributing opinions
By the third month you should have enough context to weigh in on decisions, not just execute them. This is the point to raise the thing you noticed in week one that still looks wrong, now backed by three months of understanding why it might have been built that way, or confirmation that it genuinely is a problem worth fixing. Bring a specific proposal, not just a complaint — "I think we should change X, here's why, here's roughly what it'd take" lands very differently from "why do we do it this way."
The trust curve underneath all of it
Every team calibrates trust based on evidence, and in the first 90 days you have almost none banked. Each well-scoped, well-executed contribution deposits a little; each overconfident misstep withdraws a lot more than it should, because early impressions carry disproportionate weight. The pace that feels frustratingly slow in week two is usually exactly what's needed to be moving fast and trusted by week twelve, and skipping that sequencing to look productive sooner almost always costs more time later than it saves.