Understanding the Role and First 90-Day Plans Questions

Direct answer

I structure it in three phases: learn in the first 30 days, contribute in the next 30, and own outcomes by day 90. I treat the plan itself as a draft I confirm with my manager, not something I show up with as already final.

The three phases (a 30/60/90 day plan breaks the ramp-up into three roughly month-long phases with different goals in each)

• Days 1-30, Learn: understand the systems, people, and current priorities. No major changes yet. Ship one small, low-risk task to prove I can follow through.
• Days 31-60, Contribute: take on real work with some support, start forming opinions about what should change, and build relationships beyond my immediate team.
• Days 61-90, Own: lead a piece of work end to end, propose at least one improvement backed by what I've learned, and become a resource others can rely on.

Getting manager agreement

I draft the plan as a short document in week one, explicitly labeled as a draft, and ask directly: "does this match what you'd want to see, and what would you change?" I revisit it at each 30-day mark to confirm I'm on track or to adjust, rather than treating day one's version as fixed for 90 days.

Worked example

Joining as a software engineer: days 1-30, read onboarding docs, ship a small bug fix by day 10, meet every teammate individually. Days 31-60, take a medium-sized ticket solo, start reviewing others' code, flag a recurring flaky test as a cleanup candidate. Days 61-90, own the flaky-test cleanup project end to end and present the results at a team retro. I share the draft plan with my manager in week one; they push back that the day-30 small task should specifically be in the payments module since that's the current priority area, and I adjust the plan before day five.

Trade-offs and pitfalls

Writing a generic plan and never actually confirming it risks discovering at day 60 that you were solving the wrong problem. Moving too fast into "own" activities before you actually understand the system risks a confident but wrong change. The three phases are a guideline, not a contract, a fast-moving startup might compress this to 30/45/60, which is fine as long as you say so explicitly rather than silently deviating from what you agreed.

Direct answer

I'd standardize only the parts of onboarding that are genuinely generic (access, orientation, core tooling, a shared definition of what "ramped" means) into a shared floor, leave team-specific execution to the teams, and co-design that floor with team leads, including the ones already doing well, instead of handing down a finished mandate.

Separating real variance from accidental drift

Before standardizing anything, I'd figure out which differences across teams are legitimate (a team with unusually complex domain knowledge genuinely needs a longer ramp) versus which are just accidental (nobody ever wrote the process down, so every manager improvised their own version). Standardizing over legitimate variance is a mistake; leaving accidental drift alone just repeats the problem the retrospective already found.

Designing the shared floor

The shared core should be a minimum, not a maximum: access provisioning, a defined first-week schedule, an assigned mentor, and a 30/60/90 plan template (the standard practice of setting goals at the 30-, 60-, and 90-day marks of a new hire's ramp). What goes inside each of those slots stays owned by the team.

Rolling it out without it feeling taken away

• Pull two or three respected team leads, deliberately including ones whose current process already works well, into designing the standard rather than presenting it to them finished.
• Pilot it on their teams first.
• Frame it explicitly as "here's the floor everyone gets, keep whatever's already working above it," not "your process is being replaced," and publish the actual cost of the variance (mentor time, hire confidence) so the change reads as solving a real problem rather than standardization for its own sake.
• When a team lead pushes back that their process is better, invite them to contribute it as a candidate for the shared floor. That turns resistance into ownership instead of a fight.

Worked example

Say the retrospective found one team ramps engineers in three weeks and another takes ten. Digging in, the fast team has a pre-built queue of starter tickets ready on day one, while the slow team's new hires wait for someone to think of something for them to do. The standard that comes out of that isn't a rigid week-by-week script, it's "every team maintains a ready starter-ticket queue," which respects that the fast team's actual advantage was structural, not personality-driven.

Trade-offs and pitfalls

An overly detailed centralized playbook strips out exactly the local judgment that made the fast team fast. Rolling it out as a mandate from a central function is what triggers the "my process is being taken away" reaction the question is worried about. And just measuring the gap without acting on it isn't standardization at all.

Build the smallest possible measurement first instead of waiting for full instrumentation, use honest proxies where a real metric does not exist yet, and be explicit with leadership about what is a solid number versus a directional estimate, so the 60-day evidence does not overclaim what it actually shows.

How to show progress without a measurement foundation

• In weeks one and two, pick the single thing leadership will actually judge you on and find the cheapest way to measure movement on it roughly, such as a manual weekly count or a spreadsheet pulled from raw log timestamps, rather than waiting for proper event tracking to exist.
• In parallel, instrument going forward for the next decision point only, adding the two or three events that matter most rather than a full tracking plan, since a comprehensive instrumentation project can itself eat the whole 60 days.
• When you cannot measure the real outcome yet, such as long-term retention, use a leading proxy instead, such as a week-one activation rate, and say explicitly that it is a proxy and why you believe it correlates, rather than presenting it as the real number.
• By day 60, show a before-and-after or trend on the rough metric, and be explicit about what is now properly instrumented versus what is still an estimate, with a plan to close that gap next.

Worked example
A new product manager at a startup with zero event tracking manually samples 50 recent signups from raw database timestamps in week one to build a rough "completed setup within 24 hours" proxy before any tracking exists, and ships the three events needed to measure that automatically going forward. The week-one sample comes back 20 of 50, which is 40 percent. By day 60 a second hand sample of 50 comes back 27 of 50, 54 percent, after a new onboarding flow shipped, explicitly labeled as a manually sampled proxy rather than a fully automated metric, alongside the now-live instrumentation that will produce a cleaner number next quarter. Report both as counts out of 50 and say out loud what a 50-row sample cannot tell you: each number carries a margin of error of roughly 14 points at 95 percent confidence, so the 14-point gap between them has a range running from about minus 5 points to about plus 33 points and is not yet distinguishable from sampling noise. Calling a 15-point move reliably would take something closer to 170 signups per sample, which the now-live instrumentation will supply and a hand count never will. So the honest sentence to leadership is "directionally up, 20 of 50 to 27 of 50, and the automated metric settles it next quarter", not "activation improved 14 points".

Trade-offs and pitfalls
Presenting a rough manual proxy with false precision, such as claiming 41.3 percent from a 50-row hand sample, undermines credibility the moment someone checks the math: 41.3 percent of 50 is 20.65 people. The same trap in a different shape is quoting a figure the sample cannot even produce, such as 55 percent, which would need 27.5 of the 50, or quoting a move that is smaller than the sample's own error bars. The opposite failure is spending all 60 days building the "correct" full instrumentation and showing up with nothing to point to.

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.

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.