Understanding the Role and First 90-Day Plans Questions

Direct answer

Before I can do anything useful I need two tiers of access: baseline access (identity/single sign-on, or SSO, meaning one login that grants access across the company's systems, plus email, calendar, and chat so people can actually loop me in) and role-specific access (for a technical role: source control, the ticketing system, and the relevant dev or staging environment; for a non-technical role: the CRM, or customer relationship management system, the reporting or BI tool, and the shared drives holding team playbooks). If the role-specific piece has not come through by the end of week one, I do not wait quietly: I escalate specifically, and I fill the gap with work that needs no privileged access.

Structured elaboration

• Two access tracks. Baseline access is usually IT-provisioned automatically before day one. Role-specific access usually needs a manager or system owner to explicitly grant it, and it is the one that stalls.
• Escalation ladder. Each rung escalates the audience, not the volume, and every rung is specific from the first one. Day 2 to 3: a low-key written ask to my manager that already names the system, the ticket number, and the work it is blocking. Low-key is about tone, not about content, because "just checking in" with nothing concrete in it is the version that quietly drops to the bottom of someone's list. Day 4 to 5: the same facts moved out of a direct message and addressed to the named system owner with my manager copied (an email or a ticket comment, so there is a paper trail and the person who can actually press the button sees it), rather than a vague "still no access." End of week one: if it still has not landed I stop asking the same question louder. I ask my manager to take it to whoever owns provisioning, and in parallel I ask for the narrowest interim grant that clears the block, read-only on the same system, or a teammate running the one command I need under their account while I watch, because a small scoped grant gets approved in hours where a broad one waits for a review cycle. I also note that the provisioning process itself looks broken, because if it is this hard for me it will be this hard for the next hire too, but that is a note for the team, not my unblock.
• What I do while waiting. Read documentation, sit in on meetings, start mapping who the key stakeholders are, and draft the questions I will ask once I am unblocked, so week one is not wasted.
• Handling sensitive access. I apply least privilege, meaning only the minimum access needed for the current task, nothing broader "just in case." I flag anything I did not ask for or do not immediately need (an admin role instead of a read role, access to an unrelated system), ask for it to be scoped down, and I do not let elevated access sit unused once a task is done. An unused, forgotten grant is exactly what a later access audit calls an orphaned account.

Worked example

Say I am a Data Engineer joining a team, and by day 3 I still do not have warehouse write access. Instead of waiting, I message my manager: "I'm blocked on loading the pipeline I'm supposed to own. Warehouse write access hasn't come through, IT ticket #4521 has been open since Monday. Can you ping the DBA (database administrator) team lead directly?" Meanwhile I read the existing pipeline's runbook (a step-by-step document for operating or troubleshooting the system) and shadow a teammate's deploy. When access finally lands, I notice I was granted admin on the entire warehouse instead of write access to just my team's schema, and I ask for it to be scoped down the same day rather than keeping the broader grant.

Trade-offs and pitfalls

Escalating too softly ("just checking in") gets deprioritized behind louder asks; escalating too aggressively in week one, before you have built any credibility, reads as entitled. Name the blocker and its cost, not your frustration. The bigger pitfall is quietly keeping over-broad access because it is convenient. That is exactly the kind of orphaned grant a security or compliance audit later traces back to you.

Direct answer

Turn every cross-team dependency into a named, dated, explicit commitment at the start of the plan, track it visibly, and have a pre-agreed fallback for each one before it's needed, so another team running late becomes a known risk you already planned around rather than a surprise that derails the whole plan.

Securing what you need and handling a miss

Map dependencies at planning time, not when they slip. For every milestone, name exactly which team or person owns the input you need, the date you need it by, and what breaks in your plan if it's late.

Get an explicit commitment, not an implicit assumption. Negotiate a lightweight joint service-level agreement, meaning both sides actually agree to a target date in writing, rather than relying on a hallway "sure, soon."

Keep the dependency visible. A simple shared tracker, reviewed weekly with the owning team, surfaces slippage while there's still time to react instead of at the deadline.

When a team says they can't deliver in time: get the real reason and the earliest realistic new date, then triage your own plan. Can you resequence your work around it, or descope the piece that needs it? If it's a genuine hard block, escalate early, to both managers rather than just theirs, with the concrete business impact stated plainly rather than assigning blame.

Worked example

A 90-day plan to launch a reporting feature depends on the platform team shipping an API by day 45. At kickoff, get the platform lead to commit to that date explicitly and log it in the shared tracker. At day 30, they flag they're now targeting day 60. Response: build and test everything else against a mock of that API so the 15-day slip doesn't stall the rest of the plan, and escalate the real slip to both leads with the concrete impact, launch moving from day 90 to day 105, so leadership can decide with real information rather than you quietly absorbing the miss and taking the blame for a late launch.

Trade-offs and pitfalls

Escalating every small slip burns political capital fast; staying quiet about a real blocker means you inherit someone else's miss as your own failure. The thing that actually separates a plan that survives a dependency slip from one that doesn't is having a mock or a resequencing option ready before you need it, not scrambling for one after the slip happens.

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

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

I'd evaluate a vendor or contractor the same way I'd evaluate a hire, on demonstrated capability for the specific gap rather than price or a good pitch, and before depending on them I'd get the exit terms written down, what happens when the engagement ends and who owns the resulting knowledge and work, so closing the gap doesn't leave me more exposed once they're gone.

How I'd choose one

• Define the gap precisely first: a missing skill and a missing capacity need different kinds of vendors, and conflating them leads to picking the wrong one.
• Ask for evidence of similar work, references, and where possible a small, paid, scoped trial before committing to a larger engagement.
• Check how they'll actually integrate with the team, not just their standalone competence: do they work in the same tools, follow the same review process, and meet the same security requirements the team already has.

What I'd want in place before depending on them

• A written scope with clear deliverables and a defined end date, not an open-ended arrangement.
• An explicit knowledge-transfer or handoff requirement built into the contract itself, documentation, code walkthroughs, whatever the actual deliverable is, so their departure doesn't quietly recreate the exact capability gap I hired them to close.
• Defined data and access boundaries, least-privilege access while they're engaged, and a clear offboarding checklist for when it ends.
• A named internal owner accountable for the relationship day to day, not just whoever originally signed the contract.
• A specific watch-out: a vendor whose value is tied up entirely in one person on their side is the same single-point-of-failure risk I'm trying to solve internally, just outsourced.

Worked example

Say the gap is security-audit expertise. I'd run a small, paid, scoped audit on one system first rather than committing to a year-long retainer, require a written report plus a live walkthrough of the findings as part of the deliverable (not just a PDF dropped in my inbox), and put an access-revocation step into the contract's end-of-engagement checklist so nothing lingers after the work is done.

Trade-offs and pitfalls

Picking the cheapest option without checking integration fit often costs more later in rework. Over-specifying the contract for a small, low-risk engagement wastes time that should go toward actually starting the work. And the biggest pitfall is treating a signed vendor relationship as set and forget, with nobody internally actually tracking whether the gap is closing.