Day 12 · 2026.06.01

Onboarding: Designing a New Hire's First 90 Days

Topic: Onboarding·4 Principles
"The actions you take during your first 90 days will largely determine whether you succeed or fail." — Michael Watkins
This week's premise: A new hire's first 90 days decide whether you'll spend the next two years regretting this hire. Onboarding is not HR's process — issue a laptop, add them to a channel, drop a wiki link. It's a path from stranger to contributor that you personally design. Michael Watkins calculated that an external hire takes on average 6 months to reach the breakeven point (net contribution turns positive). Design it well and you pull that point forward to 90 days; design it badly and on day 100 they're still guessing "who do I report to, and what counts as done?" Four principles this week: the 30/60/90 map, the first-30-days early win, transmitting the network and tacit culture, and using the new hire's "outsider eyes" to diagnose your own team.
PRINCIPLE 01

The 30/60/90 Map: Replace Guessing With a Map Set expectations in writing before Day 1

Onboarding PlanClear ExpectationsRamp
Before the new hire's Day 1, you should already have a written 30/60/90 doc: Learn at 30, Contribute at 60, Own at 90. Put expectations in writing so they don't have to read the air to know whether they're doing well.
"The actions you take during your first three months in a new role will largely determine whether you succeed or fail." — Michael Watkins,《The First 90 Days》Introduction
Day 1-30 · Learn Build a baseline · Set up environment · Ship first PR · Read 3 core service design docs · Meet 8 key people Day 30-60 · Contribute Deliver solo · Own a mid-sized feature · Design to launch · Start reviewing others' code Day 60-90 · Own Take responsibility · Own a subsystem · Join on-call rotation · Decide small calls independently
Context: A new senior engineer on Day 1, and you haven't prepared any onboarding material.
✗ Common move

"Just get familiar with the code, set up your environment, ask me anytime, take your time."
→ Three weeks later they still don't know what counts as "ramped," anxious every day that they're too slow — yet afraid to ask.

✓ Better move

Hand over a shared doc with the three milestone stages (see diagram above). Open with: "This is a draft — we'll tune it together in week one. Its purpose is so you always know 'am I on track?' instead of finding out at a review three months from now."

Key: milestones must be verifiable ("ship your first PR"), not vague words like "get familiar with the business" that no one can mark as done.

  • Are accounts, access, and env setup docs ready before Day 1? (Don't make them wait on IT all week.)
  • Is the 30/60/90 doc written, with verifiable milestones rather than "get familiar with the business"?
  • Is the first task chosen — scoped small enough to ship within two weeks?
  • Have you assigned an onboarding buddy? (Not you — a peer.)
  • "Take your time" is a trap. "Take your time" with no milestones = making the new hire carry the anxiety alone.
  • Expectations live only in your head. You assume "they should be ramped by 30 days" but never say it; at 60 days you're disappointed and they're shocked.
  • Outsourcing all of onboarding to HR / the wiki. The procedural parts can be outsourced; "what good looks like" only you can define.
This week's exercise: Write a 30/60/90 draft for a report who's about to join, or is within their first 30 days.
Reflection: Your last new hire — what day did they first truly "ship and contribute"? Was it the plan's fault, or the person's?
PRINCIPLE 02

The First-30-Days Early Win: Trade One Ship for Trust Secure an Early Win

Early WinCognitive LoadConfidence
In the first 30 days, what a new hire most needs isn't "full understanding of the system" — it's one small, real launch. One ship gives the new hire confidence and gives the team the signal: "this person can deliver."
"Early wins build your credibility and create momentum. They create virtuous cycles that leverage the energy you are putting into your work." — Michael Watkins,《The First 90 Days》Ch. "Secure Early Wins"
Context: You want the new hire to "really understand the system," so you're picking their first task.
✗ Common move

Throw them into refactoring the most complex legacy billing module — "this is the hardest part; crack it and you'll understand everything."
→ Three weeks, zero output, they start doubting themselves, and the team sees no signal.

✓ Better move

Give a good first issue: small in scope, but it traverses the entire pipeline (change code → test → review → deploy → watch monitoring). They learn "how we ship" in one pass and have something live by week two.

Tell the team: "This is X's first PR — give extra context in review." Turn the early win into a ritual of team acceptance.

  • Can this task actually ship within 1-2 weeks?
  • Will it walk the new hire through the full dev → deploy flow?
  • Is it a real need, or a "practice problem"? (Practice problems lack the satisfaction of shipping.)
  • If it fails, is the blast radius contained? (The first task shouldn't be able to take down production.)
  • Treating the hardest bone as a rite of passage. You think it's trust; the new hire feels thrown in to drown.
  • The win becomes a "fake win." A toy project that never ships gives no real confidence.
  • Withdrawing support after the win. On the first ship, the buddy should be alongside — don't make them navigate the pipeline blind.
This week's exercise: Reserve a well-scoped good-first-issue for your next new hire.
Reflection: Does your team have a class of deploy steps "only the veterans know how to do"? That's exactly the documentation debt a new hire's early win can expose.
PRINCIPLE 03

The Relationship Map & Tacit Culture: Onboarding Isn't Only Technical Wiring the Network & Transmitting Culture

NetworkBuddyTacit Rules
New hires rarely fail on technical grounds; more often they fail because they never figured out "how things actually get done here" — who decides, how to dissent, what counts as done. Teach these tacit rules deliberately, or they'll spend six months learning them by stepping on landmines.
"Culture is a pattern of shared basic assumptions learned by a group as it solved its problems… taught to new members as the correct way to perceive, think, and feel." — Edgar Schein,《Organizational Culture and Leadership》
Context: Your onboarding doc is all technical setup; no one explains "how things get done."
✗ The cost of not transmitting tacit rules

No one tells the new hire: "At this company, cross-team matters get aligned in a Slack DM first; pulling a meeting straight away reads as aggressive."
→ Three weeks in, an overly blunt email quietly earns them a grudge from a staff engineer — and they have no idea they stepped on a mine.

✓ Better move

Give a "people to meet + why" list: "Alice — billing owner; she must sign off before your feature ships." Assign a peer buddy dedicated to fielding "dumb questions." Then verbally cover 2-3 rules that don't fit in a wiki: how to dissent, who really decides, what counts as done.

  • Did I give a "8 people to meet + why" list?
  • Did I assign a peer buddy (not me) to field dumb questions?
  • Did I verbally cover 2-3 tacit rules that don't fit in the wiki?
  • Did I arrange for them to sit in on one core decision meeting (even just to listen)?
  • Assuming "smart people will figure it out." They will — in six months, after a few mines.
  • The buddy is you. New hires won't ask their manager dumb questions. A peer buddy is the safe outlet.
Female Leader's Note The onboarding period is a high-risk window for glue work / office housework assignments to calcify: women and underrepresented new hires are more easily, "naturally," nudged into taking notes, ordering lunch, organizing team-building in the first few weeks. Once it sticks, it's hard to shed. Counter: during onboarding, deliberately give her the first task with technical visibility, rather than letting her start from the role of "the team's caretaker."
This week's exercise: Write a "people to meet + why" list for your next new hire.
Reflection: Which tacit rule on your team did you yourself learn only by stepping on a landmine?
PRINCIPLE 04

30/60/90 Two-Way Check-ins: Harvest "Outsider Eyes" During the Honeymoon Two-Way Check-ins & Fresh Eyes

Feedback LoopFresh EyesFit Call
In their first 90 days a new hire has a pair of eyes your team has lost — they aren't yet numb to your broken processes. This window closes fast. While they still ask "why do you do it this way?", harvest the signal.
"In the beginner's mind there are many possibilities, but in the expert's mind there are few." — Shunryu Suzuki,《Zen Mind, Beginner's Mind》
Breakeven (net contribution = 0) Good ramp ≈ 90 days Bad ramp ≈ 6 months+ Time → Net contribution →
Context: The new hire is 30 days in; you run the first formal check-in.
✗ Failed phrasing

"How's it going? Settling in okay?" → "All good, everyone's been great." (You received nothing.)

✓ Harvest fresh eyes

"You're 30 days in, still carrying an outside perspective — eyes our team no longer has. Three questions:
(1) What do we do as if it's obvious that strikes you as strange?
(2) What's one thing your last place did better?
(3) What still confuses you but you're embarrassed to ask?"

And it's two-way: you also give them their first directional feedback — 30 days is too early to rate performance, but not too early for "keep / adjust."

  • Day 30: Did I ask "what feels strange/confusing" to harvest fresh eyes?
  • Day 30: Did I give first directional feedback (not a rating — "keep / adjust")?
  • Day 60: Did we align on "what to own next"?
  • Day 90: Do I have an honest call on "was this hire right"?
  • Waiting for perf review to give first feedback. By then the window is long closed and problems have set.
  • Treating fresh-eyes feedback as an insult. The new hire says "this process is weird" and you get defensive — next time they go silent, and you lose your last free audit.
  • Dragging out a known no-fit at 90 days. No sugar-coating: some onboarding failures are hiring mismatches, not something effort can fix. Dragging it to month 6 is crueler to them, the team, and you.
This week's exercise: Run a fresh-eyes check-in with someone within their first 30 days; note the first "you all do this so weirdly" point they raise.
Reflection: Which process do new hires always ask "why?" about, and you always answer "historical reasons"? That's the debt.

Deeper Questions

How should 30/60/90 change across seniority levels?
A one-size-fits-all template will simultaneously crush a junior and underuse a senior. A staff+ ramp should, by 90 days, begin to influence direction (write a tech vision, drive a cross-team alignment); "deliver a mid-sized task solo" is an insultingly low bar for them. For a new grad, delivering one mid-sized task under guidance by 90 days, without hand-holding, is already good. Get the standard's direction wrong and the senior feels like a cog while the junior feels thrown in the deep end.
Where does onboarding break most easily on remote / distributed teams?
Culture transmission that happens automatically by osmosis in an office drops to near-zero remotely: tacit rules, offhand context, hallway conversations all vanish — the new hire only sees what's explicitly written down. Remote onboarding must force the invisible into the explicit — write the tacit rules into docs, record key decisions, deliberately schedule the "people to meet" 1:1s, rather than hoping they soak it up in the channels. Remote, a buddy system and high-frequency check-ins aren't bonuses — they're the floor.
Big company vs. startup onboarding? Where's the real risk for BigCat?
Big companies have "process in place, people not": the new hire is drowned by onboarding systems, compliance training, and dozens of tools, yet no single person truly owns their ramp. Startups have no process and rely on the manager firefighting in real time. At a big company, BigCat's biggest risk is equating onboarding with the company's program and neglecting the team-level, manager-level layer — yet that layer (30/60/90, first task, tacit rules) is exactly what sets ramp speed. The company process handles "compliantly onboarded"; you handle "when do they start truly contributing."
Does the "early win" create a false early impression?
It can. A carefully chosen easy win makes the new hire look strong, and if real difficulty then jumps sharply, the team feels a gap and the new hire may misjudge their own ramp progress. The honest move is to hand over the expectation alongside it: "This is a warm-up to get you through the pipeline; the real complexity is that Q3 project, and we'll break it down together then." The early win's purpose is to build momentum and process familiarity, not to manufacture a "genius" persona. Position it accurately and it won't backfire.
Where's the boundary on onboarding investment? When is it "over-parenting"?
You can't invest equally in every new hire; the key is matching to need, not spreading effort evenly. A senior wants context and autonomy — too much hand-holding reads as distrust; a new grad wants structure and frequent check-ins — too much freedom is abandonment. Signals: if the new hire keeps asking "can I decide this myself?", you're managing too much; if they keep stalling on small decisions and reworking, you've given too little structure. The boundary isn't fixed — it expands and contracts dynamically along their capability curve.