The first job — 90 days, 6 months, 2 years

Most engineers’ first two years on the job are run on autopilot. They show up, work on what’s assigned, do it competently, get an “exceeds expectations” review, and assume that’s the loop. Two years in, they look around and notice that the engineers who are pulling away are the ones who quietly did something different in those first 90 days, those first six months, and those first two years. The work was the same. What they did with the work was not.

This module is the explicit version of “what they did differently.” None of it is exotic. Some of it is uncomfortable. All of it is more controllable than students assume — far more than the genetic-lottery model of career progression that gets passed around. The reason most engineers don’t do these things isn’t that they don’t know. It’s that nobody told them they were supposed to.

Set up — the weekly self-review habit

Before reading further, decide where your weekly self-review will live. A paper notebook, a single Apple Note, a private Notion page. Anywhere. Friday afternoon, 15 minutes:

• What did I ship this week?
• What did I learn this week?
• What’s blocking me?
• What did I see this week that I should follow up on?
• What did I commit to next week?

That’s it. The whole habit. Most engineers don’t do it. The ones who do are dramatically more legible to their managers, dramatically faster to spot patterns in their own performance, and dramatically less anxious about whether their job is going well. Set a recurring Friday calendar block right now.

Read these first

Three sources, in this order, then act:

1. Michael Watkins — The First 90 Days (chapter 1 only). book · 30 min · written for managers but the orientation framework generalises perfectly to ICs.
2. Will Larson — An Elegant Puzzle (chapters on scope and learning). book · 60 min · the most useful career book by an engineer for engineers.
3. Charity Majors — The Engineer/Manager Pendulum. post · 25 min · the long-arc framing that makes the “pick a depth” decisions later easier.
4. StaffEng.com — interview archives — read 3 stories. Notice that nobody’s path is straight. Notice what was deliberate.

Stop. Don’t read self-help framed as career advice. The book whose subtitle is “10 Habits Of Highly Successful Engineers” is wasting your time.

Days 0-90 — orient, don’t pitch

The single most common new-grad mistake is treating the first 90 days as a chance to demonstrate value. They lobby for big projects in week 2. They critique architecture decisions in standup. They suggest that the deployment pipeline could be replaced with one they’d seen in a blog post. The intent is good. The result is that everyone tags them “junior, doesn’t know yet, talks more than they listen.”

The right move in days 0-90 is the opposite. Optimise for understanding the system you’ve joined.

Specifically:

• Read code more than you write. The repos. The PRs from the last 3 months. The team’s design docs. The Slack channel scrollback. There is years of context already there; consume it.
• Run the test suite end-to-end on your machine. Build, deploy, smoke-test in staging. If you can’t do this by day 5, it’s the first thing you ask for help with — but don’t go silent for 3 weeks struggling with it.
• In every 1:1 in the first month, ask: “What context am I missing? What would surprise me about how this team works?” Managers love this question. It signals you’re trying to learn the team, not just the codebase.
• Ship one tiny PR by day 7. A typo, a dependency bump, a small refactor. The point is the loop — building, reviewing, merging, deploying — not the impact.
• Write down everyone’s name and what they own. A simple file on your laptop. By day 30 you should be able to name every person on adjacent teams and what they’re responsible for.

What not to do in days 0-90:

• Don’t pitch architecture. You don’t have the constraints. The “why is it this way” almost always has a reason you haven’t discovered yet.
• Don’t criticise the codebase publicly. “Why was this written like this?” said in standup is a review-killer. Save it for your 1:1, framed as “help me understand X.”
• Don’t disappear. Stuck for a day, fine. Stuck silently for a week, you’ve just told the team you don’t ask for help.

The implicit promise of these 90 days is: by day 90, I will have demonstrated I can be trusted with a real piece of work. Not a heroic launch. A clean track record of small, completed things, and the social capital that comes with being someone who shows up and ships.

Days 90-180 — own a small thing

By month 3 your manager should be able to point to a “thing that’s yours.” A specific feature, a tool, a part of the codebase. Not “you helped with X.” Yours.

What to optimise for:

• Pick the small thing carefully. Ideal: something the team needed but nobody had time for. A tool that would speed up everyone’s dev loop. A flaky test suite that needs unflaking. A part of the codebase that’s been on the “we should clean that up” list for a year. These are gold because finishing them earns disproportionate goodwill.
• Drive it end-to-end. Design doc, implementation, tests, rollout, doc. Not just the code part.
• Build relationships outside your immediate team. A coffee with the PM, a Slack DM to the SRE who unblocked you, a thank-you to the senior who reviewed your PR. Most ICs do none of this. The ones who do, by year 2, have a network at the company.
• Find one senior to learn from. Not your manager — a senior engineer whose code you respect. Schedule a recurring 30-min coffee. Ask what they’re working on. Send them links to things you found interesting. Don’t make it a “mentor me” ask; make it a real intellectual friendship.

The trap to avoid: scope creep on your own project. You start with “a small dashboard for the on-call team” and 3 months later you’re building a generic observability platform. Resist. Ship the small one, learn from it, then earn the next bigger thing.

Months 6-24 — own a real project, get into the rooms

This is the inflection where most new grads either pull ahead or quietly stall. The pull-ahead pattern:

• Own a real project. “Real” means: more than one person uses it, has deadlines that matter, and the failure modes are visible. Lead the design doc. Write it, share it, present it. This is the first time your name is associated with an outcome the org tracks.
• Get into the meetings that matter. The roadmap planning. The architecture review. The post-mortem. Most new grads aren’t invited; the ones who pull ahead notice the meetings exist and ask. “Could I sit in on roadmap planning even just to listen this quarter?” The answer is almost always yes.
• Pick the one or two things you want to be known for. Not “I’m a generalist.” Specific: “the person on this team who knows how the rate limiter works inside and out.” “The one who knows the deployment system.” A reputation for one thing is more valuable than mild competence at five.
• Start writing. Internal docs. A post-mortem after every incident you touch. A team blog post if your company has one. The pattern from module 06.3 applies inside the company too — public proof is public proof, even if “public” is just your engineering org.

The “stay 18-30 months, then decide” rule: most engineering careers compound by you staying long enough to ship one substantial thing, then evaluating. Job-hopping every 12 months means nothing ever matures, references are thin, and the depth of context that makes year 2 productive never accumulates. Staying 5 years at a place that stopped being right also costs you. The 18-30 month window is the right default. Past 30 months without growth, look.

The four autopilot mistakes new grads make

These quietly compound for years. None of them is dramatic. All of them are common.

Mistake	What it actually looks like	Cost
Waiting for direction	”My manager hasn’t told me what to work on next.”	The senior engineer who’s nominated themselves to own thing X just got the project you should have asked for.
Hiding mistakes	Found a bug you caused, fixed it quietly	You miss the chance to be known as someone who handles mistakes well. Worse, when it surfaces later, you look evasive.
Optimizing for ratings	Picking the safe project, the one that maps cleanly to “exceeds expectations”	Two years of safe projects = no growth. Ratings catch up to lack of growth eventually.
Refusing to ask	”I don’t want to seem dumb”	You stay stuck on things a senior could have unblocked in 3 minutes. Engineers around you notice.

The fix for all four is the same: explicit communication with your manager, weekly. Bring them the list of things you’re considering. Bring them the bug you caused, before they hear about it elsewhere. Bring them the question you’ve been afraid to ask. Almost no senior is annoyed by an honest report; almost all are annoyed by a junior who’s silently spinning.

How to actually run a 1:1

A bad 1:1 is your manager asking “how’s it going?”, you saying “good,” and then 25 minutes of small talk. A good 1:1 is structured, fast, and mostly driven by you. The format that works:

1. Status (5 min) — what shipped, what's blocked, what's next.
2. Decisions (5 min) — anything you need their input on.
3. Feedback (10 min) — alternate weeks:
     odd weeks: "How am I doing? What should I do differently?"
     even weeks: "Here's something I'd like to give you feedback on."
4. Career (5 min) — once a month: where am I going, am I on track,
   what should I be working on next quarter to grow.
5. Personal (5 min) — they're a human, you're a human. Ask about
   their weekend. Brief, real.

A few specifics that change the quality:

• Bring data. “I shipped X, here’s the metric.” Not “I think it went okay.”
• Ask explicitly for feedback. “Where am I underperforming?” Most managers won’t volunteer hard feedback; you have to ask. Then thank them for the feedback even if it stings.
• Take notes during the 1:1. A shared doc with rolling agenda is the gold standard. Manager sees their items get followed up on, you don’t forget.

The “your manager is not your career counselor” warning: your manager wants you to be productive for the team, not necessarily for your career. The two often align. They sometimes don’t. When they don’t, the manager will not be the one to tell you. Get a separate sounding board — a senior in another org, a former teammate, a mentor outside the company — for career-direction questions.

Promotion mechanics at most companies

Roughly the same everywhere, despite different rubrics:

• Promotions to senior (L4→L5, or equivalent) require sustained scope at the next level for 6-12 months before the promo. You don’t get promoted into the new level; you get promoted because you’ve already been operating at it.
• Your manager writes the case. Your manager’s manager and a calibration committee decide. You should know what the case looks like. Ask: “What would my promo case look like if you had to write it today?”
• “Senior” is the first level where the bar is meaningfully different from the prior. New grad → senior is mostly time + competence. Senior → staff is a real jump, and many engineers stop there permanently.

The system rewards visibility along with competence. Two engineers shipping equivalent work, the more legible one (writes design docs, presents at reviews, writes incident retros) gets promoted first. This isn’t unfair — promo committees can only act on signal they can see. Be legible.

Signals you should leave

Most new grads stay too long when the role isn’t right. The signals to take seriously, in roughly increasing order:

• The work has stopped being interesting and the team isn’t going to change that. Six months of “I’m coasting” is a year you don’t get back.
• Your manager is not advocating for you. You can tell when they are: they nominate you for visible projects, they share positive feedback explicitly, they show up to bat for you in calibration. When none of that is happening for two cycles, the issue is them, not you.
• You’re learning nothing from the people around you. Not necessarily their fault — sometimes you’ve outgrown a team. Real signal: when was the last time someone reviewed your code and you went “huh, I hadn’t thought of that”?
• The company’s trajectory has changed. Layoffs. Strategy pivots that hollow out your team. Senior engineers leaving in clusters. By the time you’re sure, you should have been gone six months ago.

Leaving is a skill. The exit conversation: short, gracious, no burned bridges. You’ll see these people again in 5 years. Always.

Going deeper

When you have specific questions, in this order:

1. Will Larson — Staff Engineer. staffeng.com · the long arc beyond senior. Read the stories early.
2. Marc Brooker — On scoping. post · 20 min · how to pick projects worth doing. Generalises down to year 1.
3. Tanya Reilly — The Staff Engineer’s Path. book · the technical leadership track without managing.
4. Camille Fournier — The Manager’s Path. book · read it even if you’re not going into management. Helps you read your own manager.

Skip “Tech career roadmap in 2026” YouTube. The career is yours, not the algorithm’s.

Checkpoints

If any one wobbles, the corresponding section above is what to reread.

1. What’s the implicit promise of your first 90 days? Why is “pitch architecture” the wrong move?
2. By month 6, what should “yours” look like, and what’s the trap of scope creep on your own project?
3. List the four autopilot mistakes new grads make. Which one are you most at risk of?
4. Walk through the 1:1 structure that works. Why does asking explicitly for feedback matter?
5. Name three signals that you should leave. Which is the strongest one?

If you can answer all five, you’ve earned 07.3. Next is 07.4 — the negotiation conversation that’s about to determine the next decade of your earnings.