Understanding the Role and First 90-Day Plans Questions

Bottom line

Prioritize by what actually blocks someone from getting oriented fastest, not by what's most satisfying to produce, and validate the priority order against real new-hire pain rather than guessing.

What I'd write, in order

First, a runbook-bearing README (one that covers not just setup but also "what do I do when this breaks"): what the service does, how to run it locally, who owns it. Second, a component diagram showing the major pieces and how they relate. Third, a sequence diagram for the one or two most common request flows through the system. Fourth, a deployment topology diagram showing where this actually runs in production and what it depends on there.

How I'd find the real priority order

Interview the last person who onboarded onto this service, or shadow a new engineer's actual first-week questions, rather than assuming what will be most useful. The gaps people actually hit are often more mundane than they look from the outside.

How I'd know it helped

Time a new engineer's path to their first shipped change against the old baseline, even informally, and watch whether the same three questions stop recurring in Slack, the ones that used to come up every single time someone joined.

Worked example

Inheriting a payments-adjacent service, the last new hire mentions their biggest blocker wasn't architecture, it was not knowing which of three similarly-named internal services actually handled retries. That distinction goes into the README first, before drawing the more visually impressive full architecture diagram.

Trade-offs and pitfalls

The common mistake is starting with the most comprehensive artifact, like a full architecture diagram, because it's satisfying to produce, while the actual blocker was something mundane like local environment setup. Documentation that isn't tied to a named owner also decays immediately once the onboarding push that produced it ends.

Direct answer

Stabilize before optimizing: spend the early weeks genuinely listening to find the real, specific reasons people are leaving or disengaged, since they're rarely what leadership assumes, put a small number of visible, credible stabilizers in place fast, and track leading indicators of morale rather than only the lagging turnover number, since that number won't move for months either way.

Listening, stabilizers, and metrics

Early listening, weeks one through three: one-on-ones with every team member, and recent exits if you can reach them, asking specifically what's actually driving people out, workload, a management relationship, lack of growth, pay, being blamed for things outside their control, rather than assuming.

Immediate stabilizers, weeks two through six: fix the single most commonly cited, genuinely fixable issue fast and visibly. If on-call load is the top complaint, adjust the rotation even before a full redesign; if it's a specific management relationship, address that directly. Credibility comes from one real, fast fix, not a long list of promises.

Metrics to track, ongoing: a short pulse survey score, the count of voluntary regretted departures (people you genuinely didn't want to lose) versus total departures, and qualitative signal from stay interviews, asking the people who are staying why. These move well before the lagging 90-day turnover rate does.

Worked example

Exit interviews and one-on-ones reveal the top complaint is an on-call rotation of four people covering a service that pages more than 15 times a week, meaning each person eats a brutal week every month. Immediate stabilizer: bring in two more rotation members from an adjacent team within three weeks, taking the rotation from four people to six and cutting each person's on-call share from one week in four to one week in six, a reduction of roughly a third, while separately starting a longer root-cause fix to reduce false-positive pages. Track the weekly pulse survey score and monthly regretted-departure count as the leading signal, while being explicit with leadership that the annual turnover number itself won't visibly move inside 90 days.

Trade-offs and pitfalls

Chasing the lagging turnover metric inside 90 days sets you up to either fudge the read or look like you failed regardless of real progress. The genuine 90-day win is stabilization and trust, which shows up in leading indicators first. Promising fixes before actually delivering one erodes trust further if delivery slips.

Direct answer

I'd separate this into three horizons: find the real root cause with data, not just exit-interview impressions; stabilize the people currently ramping right now before they leave too; and then redesign onboarding so it scales with hiring volume instead of quietly degrading under it.

Investigating what's actually going wrong

Exit interviews alone are unreliable here: they're self-selected (only people who left gave them), retrospective, and people often soften the real reason on the way out. I'd triangulate:

• Pull ramp-time data (time to first merged change, time to being on-call ready) segmented by start date, and check it against hiring velocity over the same window, for example whether the mentor pool stayed flat while the number of new hires per mentor doubled or tripled.
• Survey current junior engineers, not just people who left, since the people still struggling haven't quit yet and are the closest thing to a live signal.
• Look for a specific mechanism rather than a vague "onboarding was bad": a mentor-to-mentee ratio that quietly blew past a sustainable level, or onboarding docs that assumed a growth rate the org no longer had.

Stopping the bleeding, in weeks

• Identify who's currently within their first ninety days and give them a real, actively-available mentor right now, even if that means temporarily pulling a senior engineer off other work.
• Reduce load on new hires immediately: pause non-critical process changes that would otherwise land on them, and move check-ins to weekly instead of monthly for anyone currently ramping.
• Have direct, honest conversations with at-risk juniors so they hear the org has noticed and is acting, rather than finding out later that leadership only responded via a survey.

Deeper changes over the next year

• Decouple onboarding capacity from ad hoc goodwill: a formal mentor pool with a capped number of concurrent mentees per mentor, funded as real allocated time, not volunteered time.
• A standardized ramp curriculum with checkpoints tied to actual access and ownership milestones, not just tenure.
• Ongoing instrumentation of ramp-time metrics so the next hiring surge trips an early warning before attrition does, rather than being diagnosed after the fact.
• Gate future aggressive hiring pushes on whether onboarding capacity can actually absorb them, not just on recruiting throughput.

Worked example

Say the org has four senior engineers acting as mentors and hired twenty-five juniors across two quarters. Before the surge, each mentor supported roughly two mentees. What happens after depends on how long a junior actually stays in a mentoring relationship, so it's worth stating that assumption rather than waving at a single number. If mentoring runs for most of a year, the two quarters of intake overlap instead of clearing, and twenty-five mentees across four mentors is a little over six each at the same time, a bit more than a tripling of the load. If the relationship genuinely ends at ninety days, only about half the intake is live at any moment, which is closer to three each, still a fifty percent increase. Either reading is a real capacity problem and either one is visible in headcount math well before you'd need to read a single exit interview transcript. What the math buys you is a strong hypothesis, not a verdict. Before I told leadership the capacity collapse caused the attrition, I'd check that the juniors who actually left were attached to the most overloaded mentors rather than spread evenly, because a reorg, a comp change or a bad project landing in those same two quarters would move the identical headline attrition number without touching mentor capacity at all.

Trade-offs and pitfalls

A single "assign everyone a buddy" fix looks responsive but doesn't address a capacity problem. A redesign that's too centralized ignores real differences between teams. And it's worth being honest that the immediate fixes cost real senior engineering time, that cost is the price of stopping the bleeding, not a side effect to hide from leadership.

Bottom line

Onboarding several new product managers (PMs) across six time zones at once means designing a repeatable cohort program, not copying one person's ramp plan several times, because the goal is an equivalent experience across regions, not an identical schedule that quietly favors whichever region is closest to headquarters.

Before day one

Send standardized async setup, accounts, docs, calendar holds, before anyone's actual start date, so basic access never depends on someone being awake in the "right" time zone.

First 30 days, as a cohort

The cohort ramps together, but the one shared live meeting rotates its time week to week between US-, EU-, and APAC-friendly slots, so no single region always sacrifices sleep for it. Pair each new PM with a same-region buddy for daily unblocking, plus a different-region buddy for cross-timezone context.

Days 30 to 60

A structured async project, for example critiquing an existing roadmap in writing, reviewed through recorded video walkthroughs instead of live meetings, so nobody's feedback quality depends on which time zone they're in.

Days 60 to 90

A first real deliverable, owned solo, closed out with a written 30/60/90 self-assessment (tied to the day 30, 60, and 90 milestones above) shared asynchronously, plus one live cross-timezone retro to close the cohort program together.

Worked example

A cohort of four new PMs in the US, UK, India, and Australia. Do the clock arithmetic explicitly rather than by feel, because feel is exactly where these designs go wrong. A daily 9am US Pacific standup is 5pm in London, 9:30pm in India, and 2am in Sydney during northern summer, and 5pm, 10:30pm and 4am once the clocks have moved. So the region that call actually punishes is Australia, not India: an evening call is unpleasant, a 2am call is not attendable at all. A design that checks only the India offset will happily ship a meeting nobody in Sydney can join awake.

Rotating fixes this only if you check both ends of the rotation. A 7am Pacific slot is 3pm London, 7:30pm India, midnight Sydney. A 4pm Pacific slot is midnight London, 4:30am India, 9am Sydney. A two-slot rotation between those therefore does not spread the pain across four regions, it just moves it off Australia and onto India and the UK, and 4:30am in India is worse than the 9:30pm this was supposed to fix. For this cohort the design that actually holds is the three-slot rotation above, a US-and-EU-friendly slot, an APAC-friendly slot, and a middle slot that is merely inconvenient for everyone rather than impossible for anyone, plus a shared daily async doc so the standup itself is never the thing someone has to be awake for. Re-derive the slots twice a year: the US, UK, and Australia change clocks on different dates and in opposite directions, and India does not change at all, so a rotation set once in July is wrong by November.

Trade-offs and pitfalls

Treating "remote" as "the same onboarding, just on video calls" quietly forces one region to always accommodate everyone else. Over-indexing on synchronous connection also eats into the deep work new hires need. The way to check whether it's actually working is to compare time-to-first-deliverable across regions in the cohort, along with a survey on whether people felt equally supported, not just whether they showed up to calls.

Direct answer

I fix immediately only what is small, isolated, reversible, and clearly wrong, not just odd-looking. Anything that touches shared behavior, has unclear blast radius (how much of the system would be affected if it goes wrong), or might be an intentional workaround I don't yet understand, I leave alone for now and write down as a candidate to revisit once I have more context.

Framework

• Criteria for fix now: small, isolated, reversible, and I'm confident I understand why the current behavior is wrong, not just that it looks strange to me.
• Criteria for leave alone for now: unclear downstream effects, or the design looks strange but might be a deliberate workaround for a constraint I don't know about yet, or fixing it properly needs more context than I currently have.
• How I avoid it becoming a later problem: I write it down the moment I notice it, what I observed and why I didn't act, so it isn't silently forgotten, and I set an actual date (like a 30 or 60 day check-in) to revisit that list once I know more, rather than relying on memory.
• Even for something I do fix immediately, I check for existing tests, ask a teammate to sanity check anything I'm not fully sure is isolated, and avoid bundling a "quick fix" with a bigger refactor in the same change.

Worked example

Joining a data engineering team, fix now: a script logs to a hardcoded local path that breaks on the current server, an obvious bug with zero ambiguity and no downstream dependents. I fix it in ten minutes and mention it in standup. Leave alone: a pipeline retries a failed job exactly three times with no backoff, which looks wrong to me. Instead of fixing it, I add it to my running notes and ask about it in my next 1:1. It turns out to be a deliberate workaround for a flaky vendor API that fails fast, and a naive "improvement" (exponential backoff) would have made a known outage take longer to detect. I only revisit that pattern once I fully understand the vendor's failure behavior.

Trade-offs and pitfalls

Assuming odd-looking code is automatically a bug, when it might be a deliberate, undocumented workaround, is the single most common way a new hire's quick fix becomes a regression. Letting a "for later" list become a black hole you never revisit leaves a real risk unaddressed indefinitely, so set an actual date to review it. Being too conservative and fixing nothing in the first weeks can also read as low initiative, aim for a small number of safe, clearly-justified quick wins rather than zero action.