Staff and Senior-Level Readiness Questions

Direct Answer

The first 90 days after a scope jump are about earning the right to the new authority you were just given on paper, not exercising it. Spend the first month mapping the people and the landscape, the second finding one or two real wins that prove competence at the new scope, and the third establishing the standing relationships and habits that make the credibility durable rather than a one-time impression.

The 90-Day Structure

• Days 1 to 30, map stakeholders and landscape: identify who actually has to say yes for anything to move at this new scope (not just the org chart), run 1:1 listening conversations with each of them asking what's working, what's broken, and what they're afraid a new person in this role will get wrong. Resist the urge to propose changes yet.
• Days 31 to 60, find early wins: pick one or two problems that are real, visible, and genuinely solvable in the time window, ideally something people have complained about but nobody owned. The goal isn't the biggest possible win, it's a fast, credible one that proves judgment at the new scope.
• Days 61 to 90, establish technical credibility and standing rhythms: put in place the recurring mechanisms (a review forum, a written technical direction doc, a regular sync with key stakeholders) that carry your judgment forward without you personally being in every conversation, since operating at wider scope means you can't be everywhere.

Worked Example

Moving into a role with scope across three previously-separate teams, my first month was almost entirely listening: I ran individual conversations with each team's lead and two or three senior ICs (individual contributors) per team, asking specifically what they thought a new person in this role should not break. That surfaced that all three teams distrusted a shared infrastructure decision made a year earlier without their input. In month two, instead of picking a splashy new initiative, I fixed one specific piece of that shared infrastructure that all three teams had independently flagged, delivered visibly and on time. By month three, I'd set up a monthly cross-team technical review I chaired, which became the standing mechanism through which my judgment on trade-offs reached all three teams without needing a meeting every time.

Trade-offs and Pitfalls

• Proposing big changes in week two, before understanding the landscape, is the single most common way new leaders burn credibility they need for the rest of the year.
• Picking an early win that's technically impressive but that nobody outside your own head cared about doesn't build the trust you need; the win has to be visible to the stakeholders whose confidence you're earning.
• Skipping the standing-mechanism step means your influence doesn't outlast your personal attention, which becomes a real problem once your scope is too wide to be everywhere.

Direct Answer

Mentoring a junior engineer is mostly about building skill and confidence: you give more direction, check in more often, and protect them from ambiguity they're not ready for. Mentoring a senior engineer aiming for staff (a senior individual-contributor, or IC, role whose scope spans multiple teams) is mostly about building judgment and visibility: you give less direction, ask more questions than you answer, and deliberately expose them to the ambiguity and cross-team politics you'd have shielded a junior from.

What Changes, Beyond the Content

• Direction versus inquiry: with a junior engineer, when they're stuck I'll often just show them the pattern, because the goal is building a foundation quickly. With a senior engineer aiming for staff, if I answer directly I've robbed them of the judgment-building rep; instead I ask "what have you considered, and what's the trade-off you're weighing," even when I already know what I'd do.
• Cadence and initiation: junior mentoring tends to be higher-frequency and mentor-initiated, since they don't yet know what they don't know. Staff-track mentoring tends to be lower-frequency and mentee-initiated, since part of what's being developed is the judgment to know when to ask for input at all.
• What "protecting" them means: I'll shield a junior engineer from a messy, high-ambiguity cross-team negotiation because it would just be noise for their current growth. I'll deliberately put a senior engineer into that exact situation, because navigating ambiguity without a clean brief is the actual skill staff-level work requires, and it can't be taught in the abstract.
• Feedback style: junior feedback is often "here's the better way to do this." Senior-track feedback is more often "here's how that landed with the room, and here's what I noticed about the trade-off you didn't name."

Worked Example

I mentored a junior engineer through their first on-call rotation by walking through incidents together in real time and explicitly naming the diagnostic steps I was taking. A year later I mentored a senior engineer preparing for staff scope by doing almost the opposite: when they came to me frustrated that a cross-team proposal wasn't getting traction, I didn't tell them what to change in the proposal. I asked who on the other team they'd talked to before writing it, and let them realize on their own that they'd skipped the coalition-building step, which was a more durable lesson than if I'd just told them to go build allies first.

Trade-offs and Pitfalls

• Applying junior-style directive mentoring to a senior engineer stunts their judgment development and can read as a lack of trust.
• Applying staff-track hands-off mentoring to a junior engineer too early leaves them floundering in ambiguity they don't yet have the tools to resolve.
• The hardest case is a senior engineer who's technically excellent but still wants to be told the answer; part of the mentoring is making that dependency visible to them, not just working around it.

Direct Answer

Self-reported "I improved things" claims do not survive scrutiny. The fix is picking one or two concrete, collectible metrics per dimension, tied to a specific before and after window, rather than a vibe.

Metrics, Collection, and Targets

Worked Example

Illustrative: an engineer owned a checkout service where change-related incidents ran roughly once a week before a review-gate change they introduced. Tracking incident tags over the following two quarters, the rate dropped to roughly once every three weeks. They cross-checked that this was not just quieter traffic by confirming deploy volume held flat over the same window.

Trade-offs and Pitfalls

• Picking a metric you can move by gaming it, for example only counting the most severe incidents while smaller ones quietly rise, undermines the whole case if discovered.
• Claiming credit for a metric several people influenced, without naming your specific contribution, reads as overreach.
• Some genuinely high-impact work, like architecture that prevents future problems, is hard to measure directly. Be honest that some evidence is qualitative, and pair it with the metrics you do have rather than forcing a number where none exists.

Direct answer

Near-term, I'd get the knowledge out of one person's head and into something durable through pairing and a live-narrated writeup, not a single info-dump meeting. Over the following months, I'd change the team's habits so this bus-factor problem, meaning how many people could disappear before a system becomes unmaintainable, doesn't quietly recur with the next critical system.

Structured elaboration

Near-term (weeks):

• Sit with the engineer while they narrate the system live, with someone else writing the runbook or architecture notes in real time, rather than asking them to write documentation alone, since people underestimate what they know and skip the "obvious" parts when writing solo.
• Put a second engineer on the next two or three changes to that system as a pair, specifically to force knowledge transfer through doing, not just reading.
• Identify the single riskiest unknown, the thing that would hurt most if it broke, and address that first rather than trying to cover the whole system at once.

Over months:

• Rotate on-call and ownership so the same critical system isn't reflexively paged to the same person every time.
• Make writing things down a normal, visible part of doing the work itself, like a lightweight expectation that a nontrivial change updates its own doc, rather than a separate initiative people deprioritize.
• Build a recurring, low-ceremony forum, such as a monthly walkthrough where someone presents a system to the rest of the team, so knowledge sharing becomes a habit rather than a one-time fire drill.

Worked example

A Machine Learning Engineer is the only person who understands why a feature pipeline occasionally needs manual intervention. I sit with them for two sessions while a teammate writes a runbook capturing the three known failure signatures and the fix for each, then put that teammate on the next real intervention as the primary responder with the original engineer coaching from the side, rather than doing it themselves again.

Trade-offs and pitfalls

Documentation that isn't tied to actual usage goes stale within months. And trying to force knowledge transfer right before that person leaves is often already too late, this needs to be a continuous habit, not a reactive scramble once you know someone's departing.

Direct answer

Senior means you can be handed an ambiguous problem inside your own team and reliably deliver the right solution without close supervision. Staff means your judgment is trusted and needed outside your own team, on problems spanning several teams' systems. Principal extends that further, to problems spanning the whole engineering org or company strategy, where you're often setting the direction other staff engineers align their own work to.

Structured elaboration

The three axes that actually separate the levels are scope (how big a piece of the system you're accountable for), technical ownership (whether you originate the direction or execute someone else's), and cross-team influence (whether your work changes what people outside your team do).

Worked example

A senior engineer redesigns their own team's retry logic after an incident, and it holds up under load for the next year. A staff engineer notices four teams have each built their own inconsistent way of handling duplicate internal API calls, proposes a shared idempotency-key standard (idempotency: designing an operation so repeating it by accident, like a retried API call, produces the same result as doing it once, instead of double-charging or duplicating data), and gets it adopted by all four without being asked to. A principal engineer sets the multi-year direction for the company's data platform, one that staff engineers across three separate organizations plan their own roadmaps against.

Trade-offs and pitfalls

Titles vary a lot between companies, so what someone actually decided or delivered matters more than the label on their badge. Someone can be technically brilliant and still not be operating at staff level if their impact never reaches outside their own team.