Your First 90 Days as a New Engineer

The first ninety days at a new engineering job have three goals, in order: ship something small early, build an accurate map of how the team actually works, and earn the standing to have opinions. Engineers who struggle in new roles usually invert the order, arriving with opinions and deferring the shipping. This is the 30/60/90 plan from your side of the desk.

Your manager may have their own version of this document (what good onboarding looks like is the employer mirror of this article); if they share written ramp expectations, those override any generic plan, and their absence is itself information: you will need to propose your own.

Days 1–30: ship small, ask everything

Ship inside week one if at all possible. Any real change: a bugfix, a docs correction, a test. The size is irrelevant; the loop is everything. Shipping forces you through environment setup, code review norms, and deploy process while expectations are at their lowest, and it quietly answers the team’s unspoken question about you.

Spend your question budget while it is unlimited. For about a month, no question costs you anything; the same question at month six costs more. Ask, then write the answers somewhere durable. Two questions worth asking early and verbatim: “what does success look like for me at ninety days?” (get it concrete, ideally written) and “what should I absolutely not break?”

Map the informal org. Who actually reviews fastest, who owns the deploy system in practice, whose design opinions move decisions, where decisions get made (meetings? docs? DMs?). The org chart is the fiction; build the real map. Managing up starts with knowing how your manager processes information.

Calibrate before you evaluate. You will see things that look wrong: strange architecture, odd processes. Log them in a “fresh eyes” list with dates, and mostly say nothing yet. Half will make sense by day 60 (context you lacked); the other half becomes your best material later, and the list itself is valuable to a good manager, who knows new hires see process debt exactly once.

Days 31–60: real work, first opinions

Take a meaty task and own it end to end, including the parts that are new to you; asking for the task slightly above your comfort is the right move now, not in week one. Start giving code reviews, not just receiving them: reviewing is the fastest way to learn a codebase’s norms, and thoughtful questions in reviews build credibility faster than confident assertions. Effective code review practices covers tone and technique.

This is also when your first opinions are ready. The formula that lands: observation, context-check, then suggestion. “I noticed deploys need three manual steps; is there history there, or would automating it be welcome?” respects that you might be missing something, and the answer teaches you either way. Opinions that skip the context-check read as arrogance at day 40 even when correct; see influence and how to be heard.

Check yourself against the ninety-day success definition from week one. Halfway is when a quiet misalignment is still cheaply fixable: raise it in a 1:1 directly (“here’s what I think you’re expecting; am I aiming right?”).

Days 61–90: ownership and a durable reputation

By now you want one area where you are the default: the person who reviews changes there, answers questions there, and thinks about its future. Volunteer for it explicitly if it has not landed on you; unowned corners exist on every team.

Take your first on-call or incident rotation if the team has one; nothing builds systems knowledge or trust faster, and being visibly calm and honest in your first incident is worth months of good PRs. Participate in planning with your own estimates, and deliver the fresh-eyes list’s survivors as proposals, now backed by sixty days of context.

Then close the loop on your own ramp: a short 1:1 agenda at day 90 covering what you shipped, what you own, what you want next. Managers remember engineers who arrive with that summary; it is showcasing self-management in its most natural form. Your growth conversation (skill development roadmap, is a management path right for you?) starts from the standing you just built.

If something is off

Sometimes day 60 arrives and the role is not the one described in the interviews, or the ninety-day expectations were never made concrete despite asking, or feedback is nonexistent. Address it directly and early, in writing after the conversation: misalignments compound silently, and ninety days is when both sides can still fix them cheaply. If the gap is real and unfixable, it is better known now; assessing the situation objectively applies to jobs you hold, not just offers, and work-life balance norms set in the first quarter tend to stick. Set them like you mean to keep them.