Understanding the Role and First 90-Day Plans Questions

With thin documentation and siloed teams, interviews alone will not surface the real gaps, because each team only sees its own slice of the process. Spend the 45 days combining a document and systems inventory, live process walkthroughs where you watch rather than just ask, and at least one end-to-end trace of a single case as it crosses team boundaries, since that trace is usually where the real gaps live.

How to structure the 45 days

• Weeks 1 to 2: inventory what documentation exists, note how stale it is, and interview each team lead about how their piece of the process actually works today.
• Weeks 3 to 4: shadow the process live and pick a handful of real cases (an order, a request, a ticket) and trace each one across every team it touches, watching for the handoffs nobody owns.
• Weeks 5 to 6.5: synthesize into a short set of concrete gaps, each tied to a rough cost or risk, with a recommended fix and an owner.

Worked example
Tracing 10 customer orders end to end at a mid-size distributor shows the sales-to-fulfillment handoff has no documented service standard and typically takes three days of email back and forth to resolve. Separately, finance turns out to keep its own shadow spreadsheet because the shared system's export has been broken for months and nobody escalated it. Both make the leadership readout as named, owned gaps, not as a general complaint that "things are undocumented," and each is costed in its own units rather than lumped into one number. Seven of the ten traced orders needed the manual back and forth; at roughly 40 minutes of combined sales and fulfillment time each, and about 200 orders a month, that is 140 affected orders and about 93 hours a month, a bit over half a full time person. I show that arithmetic in the readout so anyone who disagrees argues with the 40 minute input rather than with my conclusion. The three day handoff is a different quantity in different units and must not be folded into the same figure: it is elapsed time on the order, not labor time, so it lands as three days of added order cycle time on those 140 orders a month, which is a revenue timing and customer expectation cost, not a headcount one. The finance shadow spreadsheet is costed separately again, as the hours that team spends rebuilding an export that is supposed to work, plus the standing risk that two sets of numbers diverge and someone reports the wrong one.

Trade-offs and pitfalls
Trying to document everything in 45 days spreads you too thin; pick the highest-cost gaps and leave the rest noted but unaddressed. Framing this as an audit of people rather than of the process invites defensiveness; presenting it as fact-finding to help everyone, with their input credited, gets you better information and less resistance.

Bottom line

Start with more structure than feels necessary, then use the cadence itself, not just its content, as the lever for handing over real autonomy, so independence builds on a track record rather than a fixed calendar date. The three stages below are calendar days from the start date, not weeks: day 30 lands at roughly week four, day 60 at roughly week nine, and day 90 at about week thirteen.

Days 1 to 30

Twice-weekly, short check-ins of 15 to 20 minutes, focused on calibrating judgment: review a decision they're about to make together, before they make it, not after.

Days 30 to 60

Shift to weekly 30-minute 1:1s, and shift the pattern from "let's decide together" to "tell me what you decided and why," so you're coaching the reasoning after the fact instead of co-deciding.

Days 60 to 90

Biweekly, and explicitly hand off one full workstream where you're informed rather than consulted, choosing something bounded enough that a wrong call is recoverable.

The decision-rights ladder

Make this explicit and revisit it together rather than leaving it as a vague sense of "getting more independent." Both of you should be able to say exactly what they now decide alone versus what still comes to you.

Knowing it's working

They start pushing back on your suggestions with their own reasoning, a sign of real ownership rather than compliance, and the content of their updates shifts from "what should I do" to "here's what I did, and here's the one thing I'm unsure about."

Worked example

In the second week, before a new PM sends a customer-facing roadmap update, you review the draft together. By day fifty, roughly week seven, they draft and send it themselves and just flag that it happened. By day eighty, roughly week eleven, they own a full feature's roadmap decisions and only loop you in when a trade-off has real stakes.

Trade-offs and pitfalls

Keeping the same cadence and content for all ninety days out of habit either smothers a fast learner or under-supports someone still building judgment. The real skill is treating the ladder as adaptive to the individual in front of you, not a fixed schedule applied uniformly.

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.

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.

Direct answer

A good early quick win, a small, fast, visible improvement that builds trust and momentum before you've earned the standing for bigger changes, is one that's low-risk to attempt, fast enough to finish inside 30 days, and connected to something a stakeholder already cares about, not just something that happens to be easy. I pick between candidates on two axes: expected impact on something someone is already watching, against effort and blast radius (how much damage it could do if it goes wrong), and I check the candidate against real data or a real conversation before committing, since the fastest fix I can imagine is worthless if nobody was actually bothered by the problem it solves.

Structured elaboration

• Sourcing candidates. Ask people directly what's been annoying them, not what they think I should fix, and look for complaints that show up more than once. One person's pet peeve is a weaker signal than three people independently naming the same friction.
• Filtering. Effort (can one person finish this without five approvals), risk (does it quietly annoy one team, or could it break something customer-facing), and visibility (does it connect to something leadership already tracks).
• Deciding it mattered, afterward. Before I start, I write down what I expect to change and how I'll know, a specific number or a specific person's stated pain going away, because judging impact after the fact with no baseline just becomes a story I tell myself. I check back at a fixed point, typically two weeks after shipping, against that same baseline.

Worked example

As a Data Analyst inheriting a reporting backlog, three requests keep coming up: a broken weekly sales export, a slow dashboard query, and a request for a new customer segment. I pick the broken export first: low effort (a single query fix), low risk (it only affects one report), and high visibility (three people have already pinged about it). Before fixing it I note the current state, the export has been silently failing for two of the last four weeks, fix it, and two weeks later confirm both runs came back clean and the requester stopped manually reconstructing the numbers by hand. That manual workaround disappearing is my actual evidence it mattered, not just that the code now runs.

Trade-offs and pitfalls

Chasing visibility alone risks doing something showy nobody structurally needed; chasing your own sense of "real" impact without checking what stakeholders notice risks fixing something invisible to the people whose trust you're building. The subtler trap is calling something a win because it shipped, without ever checking whether the underlying pain actually went away.