Understanding the Role and First 90-Day Plans Questions

Direct answer

Sort inherited technical debt (shortcuts or unfinished work in a system that make future changes harder or riskier) by combining two questions: how much pain or risk does leaving it cause, and how cheap is it to fix right now. That combination, not gut feel about what looks messy, decides the bucket.

The three buckets and what puts something in each

Fix now: it's actively causing incidents, data problems, or security exposure, or it's directly blocking the work you're already doing, and it's small and well-understood enough to fix safely without a big investigation.

Schedule: it carries real risk or cost, but fixing it is non-trivial (bigger effort, touches other systems, needs a coordinated window) or isn't urgent yet. This goes on a backlog with a rough size estimate and a revisit date, not into "someday."

Deliberately leave alone: it's low risk as-is, expensive to fix, or you don't yet understand why it exists. Changing something you don't understand in your first month is how you cause the next incident.

The decision criteria to ask for each item: is this hurting customers or causing pages today; what's the blast radius (how much of the system or how many users it would affect) if it breaks unattended; do I actually understand why it's built this way; and what's the fix effort relative to how often I'll have to touch this code going forward.

Worked example

Inheriting a data pipeline, three findings in week one: (1) a nightly job silently swallows exceptions and reprocesses the same records, causing duplicate rows, fix now, since it's actively corrupting data and the fix is a small logging and dedup change. (2) a credential-rotation script that still uses long-lived hardcoded secrets, schedule, since it's a real security risk but the fix requires a coordinated rotation window with other teams. (3) an odd manual CSV export step that feeds a finance report, and nobody currently on the team remembers why it exists, leave alone until you've found who owns that report and confirmed it's actually safe to change.

Trade-offs and pitfalls

Fixing whatever looks ugliest to you personally, rather than what's actually causing pain, burns early credibility on low-value work. Leaving something alone because you don't understand it yet is a reasonable week-one call, but it's not a permanent answer: revisit it once you've had time to learn the system, and move it to fix or schedule once you understand it.

Direct answer

I'd structure pairing so the new hire starts as the "navigator" (reading and asking questions while an experienced engineer drives the keyboard) on low-risk work, then flip so the new hire drives once they know the codebase's shape, and I'd rotate who they're paired with on a fixed cadence so no single person becomes the only route to getting unstuck.

How I'd sequence the work

• Weeks 1-2, new hire navigates: an experienced teammate drives while the new hire watches and asks questions, on small, well-understood tickets (a bug fix, adding a test). The goal here is building a mental map of the codebase and dev loop, not output.
• Weeks 3-4, new hire drives: same low-risk category of work, but now the new hire has the keyboard and the mentor narrates and catches mistakes. This surfaces gaps in their understanding while the stakes are still low.
• Month 2 onward: pairing shifts to genuinely ambiguous work, like a design decision or a tricky bug, as two peers thinking together rather than a teacher-student session.
• Rotation: I'd rotate the pairing partner every one to two weeks specifically during the first month, not because any one mentor is doing badly, but because a new hire who's only ever paired with one person has one person's blind spots and one person's idea of "how we do things," and becomes dependent on that person's availability.

Worked example

Say a new backend engineer joins a team of six. In week one they navigate while their first assigned partner fixes a flaky test, asking "why does this call go through the queue and not directly." In week three, after the first rotation, they drive on a similarly small ticket with a second teammate, who only jumps in when they're about to make a real mistake. In week five a third partner, a senior engineer this time, pairs with them on a schema change, and they contribute actual design opinions instead of just absorbing context. Three partners inside five weeks is the two-week rotation actually running rather than just being written down: by the end of the first month the new hire has seen three people's habits and three people's idea of "how we do things here," which is the entire reason for not leaving them with one.

Trade-offs and pitfalls

Pairing too long without letting the new hire work solo means you never find out if they can operate independently, which is the whole point of onboarding. Rotating too fast (every session) prevents any rapport or continuity from forming. And treating pairing purely as a training exercise for the new hire wastes the fact that a fresh set of eyes often catches things the rotating partner had stopped noticing.

Direct answer

Run knowledge transfer as a structured handoff with a concrete independence test at the end, not an open-ended series of conversations, because having talked about it is not the same as confirming the replacement can actually operate without the departing person.

The handoff, from artifacts to verification

Identify what's actually at risk: not everything the departing person knows, specifically the undocumented decisions and tribal knowledge, why the architecture is shaped this way, what breaks and how it gets fixed, who else to call, that only lives in their head.

Artifacts to produce before they leave: a written architecture decision record (ADR, a short document capturing a decision, its context, and why the alternatives were rejected) for the biggest undocumented decisions, an updated runbook (a step-by-step reference for handling a specific recurring task or incident) for anything they currently handle informally, and a list of "if X breaks, here's what I'd check first" debugging knowledge.

Shadowing structure, three distinct stages and not two: stage one, the replacement shadows the departing person on a real task. Stage two, reverse it, the replacement drives while the departing person watches and corrects in the moment, which surfaces gaps a passive walkthrough never will. Stage three is the independence test below, and it is a genuinely different setup from stage two, not a rename of it: in stage two someone is standing there to catch a mistake, and in stage three nobody is.

Verifying independence: before departure, have the replacement handle a real, ideally low-stakes task solo while the departing person is reachable but not in the room and not watching, so nobody can silently correct the run as it happens. Then debrief on what they got stuck on, and separately on whether they came close to reaching for help. That gap list is your remaining risk after the person leaves. Skipping from stage two straight to the departure date confirms only that the replacement performs under supervision, which is not the thing you needed to confirm.

Worked example

The departing architect owns the reasoning behind a multi-region failover design nobody else fully understands. Days 1-20 of the remaining 60: write the ADR explaining why the design uses active-passive rather than active-active, a cost and complexity trade-off made two years earlier. Days 20-35: the replacement shadows the next scheduled failover drill. Days 35-45: the replacement drives the following drill while the departing architect sits beside them, watching and correcting in the moment, which catches the two steps they would otherwise have skipped. Days 45-55: the independence test, which is deliberately not another supervised drill. The replacement handles a real but low-stakes piece of the same system solo, say executing a scheduled region drain during a maintenance window, with the departing architect reachable by phone but not in the room and not on the call. Days 55-60: every gap from those three runs gets documented before the departure date, and anything still unresolved is written down as named, owned risk rather than quietly assumed to have transferred.

Trade-offs and pitfalls

Relying only on documentation without a hands-on solo test leaves real uncertainty about whether the knowledge actually transferred. Relying on a supervised run as if it were the solo test is the subtler version of the same mistake, because a watcher who corrects one step has already changed the result you were trying to measure. Waiting until the final week to start usually leaves time for nothing beyond a passive knowledge dump, so this needs to begin the moment the departure date is known.

Direct answer

I'd start with short, frequent check-ins, twice a week in month one, focused on removing immediate blockers and confirming basic ramp progress, then taper to a weekly one-on-one by month two focused more on growth and feedback than logistics, and from month three through month six shift again toward a standard cadence focused on ownership and forward-looking goals rather than onboarding at all. I plan the third phase against month three rather than month four because that is usually the point where someone is shipping without me unblocking them, and I would move that boundary for the individual rather than treat it as a date: the trigger for dropping the onboarding frame is that they have carried something end to end on their own, not that a particular month has elapsed. The schedule itself becomes a signal of how the relationship is maturing.

Structured elaboration

• Month 1 (twice weekly, 15 to 20 minutes). Mostly logistics and blockers: is access working, are they finding what they need, do they understand what's expected this week. Short and frequent beats long and infrequent here, since problems compound fast when someone's new.
• Month 2 (weekly, 30 minutes). Shift toward their actual work: what are they learning, where are they stuck conceptually rather than logistically, early feedback on their first real contributions.
• Months 3 to 6 (weekly or biweekly, a standard one-on-one). Shift toward growth and ownership, career conversations, and confirming they're integrated socially, not just technically, since isolation often shows up later than skill gaps do.
• When to bring in a mentor. When the gap is skill- or context-specific and better served by a peer than a manager, an experienced teammate who can pair on a specific technology, or answer "who do I actually go to for X" questions a manager might not know.
• When to bring in HR. When the signal is about fit, wellbeing, or something outside what a manager can or should handle alone: repeated disengagement, a conflict not resolving through normal conversation, or the new hire raising something HR-scoped directly, like compensation or an accommodation need.

Worked example

A new hire is technically fine by week six but seems isolated: not volunteering in meetings, eating lunch alone, deflecting "how's it going" with short answers. That's a mentor-shaped gap, not a performance problem, so I'd pair them with a peer mentor for informal context and social integration rather than adding more manager check-ins, which would just formalize something that needs to feel informal. If instead the same signals came with the person explicitly saying they feel excluded or uncomfortable in how they're being treated, that's a different, HR-scoped conversation, not something a buddy system solves.

Trade-offs and pitfalls

Keeping the high-frequency, logistics-heavy cadence going past month one reads as micromanagement and can slow someone's growth into ownership; tapering too fast leaves gaps unnoticed until they're bigger. The subtler pitfall is treating every struggle as a skill gap a mentor can close when it's actually a fit or wellbeing issue that needs HR, or the reverse, escalating a normal skill-ramp bump to HR when a mentor pairing would have solved it faster with less friction.

Direct answer

I negotiate 2 to 4 concrete outcomes with my manager up front, each tied to a named data source so "progress" is evidence rather than a claim, and I report on a fixed cadence using a short artifact rather than waiting to be asked.

Framework

• Start from expectations, not personal wins: in week one or two I ask my manager directly what "going well at 90 days" looks like to them specifically, not what I assume it means.
• Pick metrics with a source: for each objective I name exactly where the number comes from (a dashboard, a query against a specific table, a ticketing-system report, a survey), because a metric with no clear source becomes an argument about opinions later.
• Mix leading and lagging: leading indicators show early motion (a document shipped, a relationship built) before the lagging business metric (revenue, cycle time, model accuracy) has had time to move.
• Communicate on a fixed cadence with an artifact my manager does not have to chase: a one-pager, a dashboard link, or a lightweight roadmap view updated on a schedule (say, biweekly, which lands on days 14, 28, 42, 56, 70 and 84) and shared in a recurring 1:1 or written update. The cadence is a floor, not a ceiling: anything far enough off target that waiting two weeks would cost options gets flagged off-cycle the day I see it.
• If the role is operational, I also tie at least one metric to something like reducing a manual reporting cycle time, in addition to a milestone that is simply "delivered."

Worked example

Joining as a BI (business intelligence) analyst, I negotiate four 90-day outcomes with my manager: rebuild the weekly sales dashboard (source: Salesforce export, target day 14); get it actually adopted, which I define as a countable number rather than a feeling, 30 of the 40 people on the sales team opening it at least once in a given week (source: the dashboard tool's own viewer log, and I check before agreeing that the log counts unique viewers rather than page loads, because agreeing to a number I have not looked at is how a metric becomes an argument later); cut report turnaround from three days to same-day by day 60 (source: ticket timestamps already logged); and present findings to the VP of Sales at day 90. I keep a one-pager updated every two weeks: status per item (shipped, in progress, blocked) next to the current number against the target. At day 45, three days after the day-42 update, the viewer log shows 6 of the 30 weekly viewers I committed to, which is 20% of that target. I do not hold it for the day-56 update: a miss that size is exactly the off-cycle case, so I flag it the same day with a concrete mitigation (an in-person walkthrough with three heavy users), rather than let it surface as a surprise at day 90.

Trade-offs and pitfalls

Choosing a metric you cannot actually source turns "progress" into assertion. Going quiet until day 90 for a "big reveal" makes stakeholders start doubting you are doing anything in the meantime. Chasing only a lagging metric that will not move within 90 days regardless of your work, with no leading indicator to show in between, is a common trap. And more metrics is not better: 2 to 4 well-chosen and well-sourced beats 8 vague ones that dilute focus.