The first 90 days: onboarding without overpromising

A question that feels embarrassingly basic in week two becomes genuinely expensive to ask in month eight, once you're expected to already know the answer. Early on, almost every question is reasonable — "why does this service exist," "who actually owns this part of the system," "what happened the last time someone tried to change this" — and asking them upfront is far cheaper than guessing wrong and having to undo the consequences later. Treat the first weeks as a legitimate, time-limited license to ask things you won't be able to ask as freely once that window closes.

Comparing the new team unfavorably to a previous one, especially in the first weeks, reads as dismissive of context you don't have yet — there is almost always a reason things are the way they are, even when that reason is "nobody's gotten around to fixing it," and it's worth understanding the actual reason before proposing a change. A more effective version of the same instinct: "At my last job we handled this differently — can you help me understand why it's set up this way here?" This gets the same useful comparison across without the implicit judgment.

Trying to overhaul a process or ship something highly visible in the first two weeks, before you understand the team's actual constraints, is a common way new hires damage trust rather than build it — the fix often ignores a constraint an established team member would have known about. A smaller, correctly-scoped early win (fixing a real, minor bug well; shipping one clean, well-reviewed feature) builds credibility for larger scope later far more reliably than a big swing that misses because of missing context.

Waiting for a formal 30/60/90 check-in to learn what's actually expected of you wastes weeks that could have been used well. A direct early conversation — "what does success look like for me in the first 90 days, concretely?" — surfaces a manager's real priorities (which are often more specific and different than the job posting suggested) and gives you a clear target instead of guessing at one.

Starting a running, private log of what you shipped, learned, and helped with — even briefly, from week one — pays off directly at review time (lesson 12), when trying to reconstruct six months of work from memory alone is far harder and far less complete than it needs to be. This habit costs a few minutes a week and consistently produces a stronger performance review than starting the reconstruction cold, right before the deadline.

A new hire suggesting "we should switch to Kanban" in week three, before understanding why the team chose its current process, tends to land poorly regardless of whether the suggestion is technically sound — it signals unfamiliarity with context more than it signals expertise. The same suggestion, made in month four with specific examples from having actually worked inside the current process, lands as informed rather than presumptuous.