Understanding the Role and First 90-Day Plans Questions

Bottom line

A program that scales across seniority levels needs one shared spine plus level-specific tracks, fixed checkpoints, and success metrics that measure whether people actually ramped and stayed, not just whether they clicked through a curriculum.

Modular structure by seniority

A shared core module everyone takes: company context, tools, compliance basics. On top of that, level-specific tracks, for example an individual contributor (IC, someone who does the work directly rather than manages others) track focused on hands-on ramp tasks, and a manager track focused on team-lead skills like running a first 1:1. A senior hire shouldn't sit through content built for a new graduate, and vice versa.

Checkpoints

Day 30: core checklist complete and a first small deliverable shipped. Day 60: owns a real piece of work, and their mentor pairing is established. Day 90: self-sufficient on their core scope, with a formal check-in against the success criteria set on day one.

Mentoring pairing

Every new hire gets a mentor who is not their manager, matched by role and, where possible, someone who ramped relatively recently themselves, with a light fixed structure, roughly 30 minutes every other week, rather than leaving the pairing informal and hoping it happens.

Keeping it current

Assign explicit ownership of the playbook itself, someone updates it every quarter based on new-hire feedback and what's actually changed in the org. Without a named owner, a program like this goes stale within two hiring cycles.

Measuring payoff

Track ramp-to-productivity time and, over a longer horizon, 12-month retention of hires who went through the program compared to a baseline, alongside a day-90 survey score, rather than treating module completion as the finish line.

Worked example

A company hiring 15 people a quarter across ICs and two first-time managers: the core module is a two-hour self-paced session, the IC track adds a shadow-then-own task progression, and the manager track adds a specific "run your first 1:1, with your mentor observing" checkpoint.

Trade-offs and pitfalls

Building a fully scaled program before you have enough hires to justify it is itself a form of debt. The bigger pitfall is letting completion metrics substitute for outcome metrics: people can finish every module and still not be productive, or leave within a year.

Direct answer

Treat cultural onboarding as its own explicit workstream alongside technical onboarding: actively map the unwritten norms, who really makes decisions, how disagreement gets voiced, which meetings actually matter, rather than assuming they match your last team's, and deliberately create visibility into decisions that currently happen live in only one site's timezone.

Activities across the first 60 days

Understand team norms: run short one-on-ones across at least two sites, not just with your manager, asking direct questions like "when you disagree with a decision here, what actually happens" and "what's a meeting I should never skip." A written norms document, if one exists, is often stale; actual behavior is the real signal.

Improve cross-site collaboration: find which recurring decisions currently happen informally, in hallway or desk conversations at one site, and move them into a written or recorded artifact, a shared decision log or a recorded demo, so people at other sites aren't structurally excluded from the reasoning.

Accelerate inclusion into decision-making: ask explicitly to be looped into one or two concrete upcoming architecture decisions, first as an observer, then as a contributor, rather than waiting to be invited. Propose rotating meeting times so no single site permanently bears the inconvenient hour.

Worked example

Joining a distributed team whose architecture group is mostly based in one city and pre-aligns informally over lunch before the "official" design review. Within the first 30 days, you notice the review's outcomes are effectively already decided before the meeting starts. Fix: ask the lead to move pre-alignment notes into the shared design document before the meeting happens, and volunteer to co-facilitate one review from a different timezone to prove the new format works. By day 60 that becomes the team's actual norm, not just your personal workaround.

Trade-offs and pitfalls

Pushing to change norms before you've earned trust reads as presumptuous in a new hire. Staying purely observational for the full 60 days means you're still structurally excluded right when real decisions get made. The balance is naming the specific exclusion concretely and proposing one low-cost fix, rather than raising a general complaint about culture.

Direct answer

In my first couple of days I ask to see the artifacts that reveal how the team actually works versus how it is supposed to work: the onboarding doc or runbook (a step-by-step document for operating or troubleshooting a system or process), the team's roadmap or current OKRs (objectives and key results, a goal-setting framework pairing a qualitative objective with measurable results), recent postmortems (written after-the-fact reviews of what went wrong and why) or retro notes, and whatever the team treats as its single source of truth. I am not reading to memorize facts, I am looking for the gap between the document and reality, and for who wrote it, since that person becomes my first stakeholder to talk to.

Structured elaboration

• What to request. Onboarding or runbook docs; architecture or process diagrams; recent decision records if the team keeps them; the last one or two retro or postmortem docs; whatever dashboard or report leadership actually looks at.
• What I'm looking for. Is it current (check the last-edited date)? Does it match what people actually say in standup? Does it name an owner? Does it explain the "why" behind a decision, or just the "what"?
• If it's thin or stale. I do not just complain about it. I fix the smallest piece I can verify myself within the first week (correct one broken link, update one outdated diagram), and I flag the larger gaps to my manager with a concrete ask (who should own keeping this current) rather than a vague observation. The guiding rule is to leave it better than I found it: even a small, honest edit compounds for the next new hire.

Worked example

On day two as a new Business Intelligence Analyst, I ask for the metric dictionary and the last quarterly business review deck. The dictionary defines "active user" one way, but the dashboard I'm handed calculates it differently (a 30-day window in the doc, a 28-day window in the actual query). Rather than assuming the doc is right, I ask the two people whose names are on recent commits which one is authoritative, get an answer within a day, and submit a one-line fix to the dictionary with the correct definition and a link to the query that proves it.

Trade-offs and pitfalls

Asking for every document that exists signals you would rather read than talk to people; asking for too little means you re-derive things others already wrote down. The real trap is fixing documentation quietly and never surfacing the pattern: one wrong line is a typo, the same kind of drift across five documents is a process problem worth naming to your manager.

Separate the two different asks: "no surprises" is a process commitment you can honestly make, while "a guaranteed revenue number" before you have done any discovery is an outcome commitment you generally cannot make with integrity. Say so directly and early, and offer a concrete alternative that actually gives the executive what they need, predictability, without a number you would have to walk back later.

What to commit to, what to refuse, and how

• Commit to a specific update cadence, such as a short written update every two weeks, an explicit promise to flag bad news the moment you know it rather than waiting for the scheduled update, and a firm date by which you will have a defensible number, after real discovery, not before.
• Refuse the premature number, but explain why rather than just declining: a number given today is a guess dressed up as a commitment, and missing it because you did not yet know something important is exactly the surprise the executive is trying to avoid.
• Offer a bridge if they need something to plan around immediately, such as a range with an attached confidence level, rather than either a hard number or a flat no.
• Frame the whole conversation as a partnership in reducing their risk of being blindsided, not a negotiation you are trying to win; executives who ask for this are often anxious about being surprised themselves further up the chain.

Worked example
A VP tells a new business operations manager, "I want a 100-day plan with zero surprises, and I want to know the number we're committing to for next quarter." The manager commits to biweekly written updates and a promise to flag anything material within 48 hours of finding it, and separately explains they cannot responsibly guarantee a quarter number in week one, but commits to a range with a stated confidence level by day 30 once initial discovery is done, and a firm number by day 45. The VP accepts because they got a concrete process and a real date, not a stall.

Trade-offs and pitfalls
Giving a made-up number just to end an uncomfortable conversation creates a worse surprise later when it is missed. Being so rigid about refusing the number that you offer nothing concrete in its place reads as evasive rather than principled.

Keep it to one page with three kinds of rows: what you learned, what you delivered, and what is blocking you. Mix one or two leading indicators, early signals that predict future results, with at least one lagging indicator, the actual outcome those signals lead to, and use the view in the weekly check-in to drive a real conversation, not to read a status report aloud.

What goes on it, where the data comes from, and how to use it

• Content: learned (key facts or risks discovered this week), delivered (concrete artifacts or decisions produced, not hours worked), and blocked or need help (specific asks, not vague concerns).
• Indicators: leading indicators such as stakeholder interviews completed or pipelines audited tell you whether you are on track before the real outcome shows up; a lagging indicator such as dashboard trust or deploy frequency confirms whether the work actually worked. A view with only one type either looks busy while producing nothing, or stays quiet for weeks and then surprises everyone.
• Data source: pull from whatever you are already tracking, a simple log, your ticket tracker, or a calendar of completed conversations, rather than building new infrastructure just for this view; it should cost minutes a week, not hours.
• Alert threshold: pick one number that would make you flag something early rather than waiting for the weekly meeting, such as "if a blocked item sits unresolved past two weeks, I escalate outside this cadence." That threshold turns a passive status view into something that actually catches problems in time. Write it at the top of the view in the same words every week so it fires on the number rather than on how the week felt, and give the leading indicators their own threshold, since a blocked-item rule never fires on work that has quietly stopped: "two consecutive weeks with no new stakeholder conversations, or a leading indicator flat for two weeks, and I raise it outside this cadence."
• Weekly check-in: walk through what changed since last week, ask directly for help on blocked items, and confirm you are still aligned with what the manager and stakeholders actually care about, since priorities often shift under a new hire faster than the plan anticipated.

Worked example
A new AI engineer's one-pager tracks leading indicators, pipelines reviewed and stakeholder conversations completed, against a lagging indicator, time to first successful experiment, once that becomes measurable. The threshold written at the top of that view is "two consecutive weeks with no new stakeholder conversations, or a leading indicator flat for two weeks, and I raise it outside this cadence." In week three, eight conversations are done and the lagging metric has not moved yet, which is expected this early. Weeks four and five pass with the count still at eight, and those are the two flat weeks the threshold names, so it gets raised in week five rather than in week six when someone else would have noticed anyway. The raise is specific rather than a status line: the leading indicator has stopped, here is why (two stakeholders have cancelled twice each), and here is the help needed to restart it.

Trade-offs and pitfalls
Turning this into a comprehensive project-tracking tool defeats the point of keeping it to one page. Showing only lagging indicators looks fine for weeks and then surprises everyone when the outcome does not show up on schedule.