Understanding the Role and First 90-Day Plans Questions

Direct answer

The core structure, learn, then contribute, then own, stays the same, but at a seed-stage startup I compress discovery to days, act on thinner evidence, and expect the ground to shift under my plan, while at a large public company I extend discovery, work through more formal process and sign-off before acting, and lean on existing documentation and specialists rather than figuring everything out myself.

Framework

• Discovery speed and depth: at a seed-stage startup, often pre-product-market-fit, there's little or no documentation, a handful of people hold all the context, and I can talk to nearly everyone, including the founders, within the first week. At a large public company already generating stable, predictable ARR (annual recurring revenue), there's more documentation but also more of it is stale or contradictory, and no single conversation gives the full picture, so discovery takes longer and needs multiple rounds with different specialist teams.
• Timelines: at a startup, my day-30 milestone might already be a shipped, customer-facing change, because the company can't afford three months of pure ramp-up. At a large company, day-30 might legitimately still be mostly learning, because the blast radius (how many systems, teams and customers a single mistake actually reaches) of an uninformed early change is much larger. Detection is the second, separate multiplier: more layers of abstraction and more owners sit between the change and whoever would notice it, so the same mistake both travels further and runs longer before anyone catches it. At a startup you usually get neither, which is a large part of why the same change is cheap there and expensive here.
• How fast to push for change: at a startup, especially pre-product-market-fit, I'd push faster and accept more risk, because the cost of being slow, running out of runway, missing a market window, usually exceeds the cost of a wrong but reversible bet. At a large, regulated, or public company, like a financial institution versus a fast-growth consumer startup, I'd push more slowly and go through more formal validation, because the cost of an unreviewed change, a compliance breach, a regression affecting a large existing customer base, is asymmetric and hard to undo.
• What stays constant: I still get explicit agreement from my manager on the plan, still map stakeholders, and still aim for a concrete deliverable, not just activity, by day 90. Only the pacing and risk tolerance shift.
• If the product itself is still changing shape quickly (a variant of the startup case), I'd treat my own 90-day plan as similarly disposable, revisiting it every two to three weeks rather than trusting a plan written on day one to still be right by day 60.

Worked example

At a seed-stage, pre-product-market-fit startup with eight people, my week one includes a 1:1 with literally every person in the company, and by day 10 I've shipped a small but real customer-facing fix, because there's no formal review process and the founders want visible momentum immediately. At a large public company in a regulated space like a financial institution, my first 30 days is almost entirely discovery, reading compliance and architecture documentation and meeting a risk and compliance stakeholder I wouldn't need to involve at all at the startup, and my first proposed change doesn't ship until it clears a formal review process, likely closer to day 60. The plan skeleton is identical, but at the startup "act" starts inside the first week and has already shipped by day 10, while at the regulated company "act" might not start until day 45 and does not ship until closer to day 60.

Trade-offs and pitfalls

Applying startup-speed instincts at a large regulated company reads as reckless and can trigger a real compliance or trust problem. Applying large-company caution at an early-stage startup means the company can run out of time before you've delivered anything. Moving fast at a startup means accepting a higher rate of small, reversible mistakes as the cost of speed; moving slow at a large company means accepting that your early credibility-building takes longer to show results. Both are the right trade-off for their context, misreading which context you're actually in is the real risk.

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 keep a running, dated log of decisions, questions, and anything I had to ask someone else to figure out, written down in the moment rather than reconstructed from memory later, and periodically turn the recurring items into something shared, like a doc or wiki page, rather than leaving it all in personal notes only I can read.

How I'd do it

• Capture at the moment of confusion: whenever I have to ask someone how something works, I write down the question and the answer immediately, with a date. That's both a personal reference so I don't ask twice, and raw material for future onboarding docs.
• Keep personal notes separate from shared knowledge, then convert: personal notes can stay quick and messy. Every couple of weeks I'd go back through them and pull out anything that would have helped me on day one into a real doc entry someone else can find.
• Organize for search, not for chronology: tag or file things by topic ("how do I get access to X") rather than leaving a plain diary, so a successor can find an answer without reading through my whole history.
• Look for the pattern later: when I eventually onboard someone else, or just look back myself, the recurring questions in that log are usually the strongest evidence of what the onboarding process itself should actually fix.

Worked example

On day three, I have to ask a teammate three separate times how the staging environment differs from production. Written down once, that's just a personal reminder. Noticed as a pattern (three separate times, same question), it's a clear signal worth turning into an actual "staging versus production" doc entry for the next person.

Trade-offs and pitfalls

Notes that never get converted into a shared doc only ever help me. Converting everything with no filtering produces a bloated wiki nobody trusts enough to read. And the whole practice only works if I actually revisit the notes, a log nobody reopens is no better than not keeping one.

Direct answer

I state the role's purpose in one sentence tied to a business outcome, not a task list ("this role exists to make sure the product team can trust the numbers they're making decisions on," not "this role does dashboards and SQL"). Then I pick three 30-day priorities that each map back to that purpose: usually one is about understanding the current state well enough to be trusted, one is a concrete early contribution that proves competence, and one is a relationship or process gap that would otherwise slow everything down later.

Structured elaboration

• The "why those three" test. Does each priority map to the stated purpose? Would skipping it create a bigger cost later than doing it now? Is it achievable with the access and trust I'll realistically have in 30 days?
• What I deliberately leave out. Deep technical debt and big strategic bets usually need more context and more trust than a first month provides. Tackling them too early risks confidently solving the wrong problem.
• Sanity-checking against expectations. I compare my three against what my manager and my skip-level (my manager's manager, one level above my direct manager) actually expect, because what I would prioritize and what leadership assumes I'm prioritizing can quietly diverge. That gap is one of the more common reasons a strong first quarter still reads as disappointing.

Worked example

Joining as a Product Manager on a struggling onboarding flow, I'd frame the role's purpose as "get more new users to their first meaningful action, faster." My three priorities: first, spend two weeks instrumenting and understanding the actual drop-off funnel, since I can't trust the existing dashboard's definitions yet; second, ship one small, low-risk change we can measure within 30 days, to prove I can move the metric, held to what that window can honestly support: two weeks of instrumentation leaves about sixteen days to build, ship and read a result, so I run it as a split against a holdout rather than a before-and-after, because the "before" period was measured on the funnel definitions I have just replaced, and comparing across that change measures my instrumentation rather than my fix. If new-user volume is too low for a split to separate the effect from noise inside sixteen days, I say that up front and present the day-30 number as directional, with the honest read scheduled for day 60, rather than claiming a causal win that a marketing push, a pricing test or a seasonal dip would explain just as well; third, set up a recurring sync with the three most affected teams (support, growth, engineering), since that coordination gap was previously slowing every prior fix. I would explicitly not touch the pricing page redesign that's been discussed for months, because it needs more organizational buy-in than 30 days of trust can generate.

Trade-offs and pitfalls

Choosing priorities that are all "learning" tasks with no visible output looks passive to stakeholders watching for signal; choosing all "shipping" tasks with no listening phase risks confidently fixing the wrong thing. The failure this question exists to catch is a candidate who lists three generic activities (meet people, read docs, ship something) with no connection back to why the role exists in the first place.

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.