Staff and Senior-Level Readiness Questions

Direct Answer

A promotion case that lands is not a highlight reel. It is two or three examples, each mapped explicitly to one competency in the leveling rubric your company actually uses (leveling rubric: the written document, sometimes called a career ladder or leveling guide, that spells out the expected skills and behaviors for each job level), each with an outcome you can back up with a number or a corroborating source rather than only your own account. State upfront which level and which specific competencies you are targeting.

Five Things Every Example Needs

1. The specific competency you are demonstrating, named exactly as your leveling rubric names it, for example "technical leadership" or "scope of ownership."
2. The baseline: what was true before you acted.
3. The action: what YOU specifically did, especially where you made a call others did not, not what "we" did.
4. The outcome: a number, an artifact, or third-party corroboration, such as a peer's or manager's account, rather than only your own telling.
5. Why it demonstrates the NEXT level rather than your current one: name the counterfactual, what a person at your current level would have done differently or not done at all.

This same five-part exercise is the right shape whether you are building a junior-to-mid case, a mid-to-senior case, or a senior-to-staff case; only the competencies in step 1 and the baseline in step 2 change with the transition. The worked example below uses a senior-to-staff case to illustrate it, but swap in your own target level's competencies and the method holds.

Worked Example

Illustrative senior-to-staff case, two examples. Example one, competency "scope of ownership": baseline, owned one service; action, took over an adjacent failing service no one owned after its previous owner left, without being asked, stabilizing it and merging its on-call rotation into mine within a quarter; outcome, on-call pages for that service dropped from several a week to roughly one every couple of weeks, corroborated by the on-call dashboard. This shows staff rather than senior scope (staff: a level where your ownership and influence are expected to extend beyond your own team, not just deeper skill within it) because a senior engineer keeps their own service healthy, while volunteering to absorb an orphaned service's operational burden is scope beyond assignment. Example two, competency "technical leadership without formal authority": baseline, three teams each built inconsistent retry logic; action, proposed and drove adoption of one shared retry library, presenting the design at each team's own planning meeting individually; outcome, adopted by all three teams within two quarters and it prevented a class of incident that had previously hit two of them, corroborated by those services' incident record and by the two leads who ran the rollout on their side rather than by my own account of it. Nobody assigned this and I had no authority over those teams. The fifth element, the counterfactual, is what makes it a next-level example rather than a good one: a senior engineer here fixes the retry logic in their own service and moves on, which is correct and complete work at that level. What the next level added was noticing that the same defect existed three separate times, judging that one shared library was worth the slower path of selling it team by team, and absorbing that cost without a mandate to do it.

Trade-offs and Pitfalls

• Picking examples that are impressive but map to your CURRENT level's competencies rather than the next one is the most common reason a promotion case gets rejected.
• Outcomes with no independent corroboration read as self-graded.
• Too many examples dilutes the case; two or three strong ones beat six mediocre ones.

Direct answer

The line between "I can just decide this" and "I need to escalate" moves along two variables, blast radius (how many people or systems are affected if you're wrong) and reversibility (how expensive it is to undo), not along your title. What changes as you gain seniority isn't the underlying rule, it's how accurately you can estimate blast radius and reversibility yourself, plus the organizational trust that lets people accept your call without re-checking it.

Structured elaboration

A simple two-axis test: if a decision is reversible and its blast radius is narrow (it mainly affects your own work), decide and inform people afterward. If it's irreversible or its blast radius is wide, crossing teams, costing real money, touching compliance or customer-facing data, decide only with input, or escalate before acting at all. As you gain experience, you've personally seen more of the ways a "small" decision turned out to have a wide blast radius, so your estimate gets sharper, and colleagues who've watched your calls hold up start extending you more latitude even on objectively similar-risk decisions.

Worked example

Two years ago, I would not have unilaterally added a new field to a shared internal API contract, because I didn't yet understand every consumer well enough to judge the blast radius, so I looped in the platform team's lead before touching it. Today I add optional fields to that same class of API on my own judgment, informing consumers afterward instead of asking permission first, because an added optional field is backward compatible: existing callers keep working untouched, so the blast radius really is narrow and the change is cheap to revert. The actual risk of that API change didn't shrink; my ability to size it, and the trust extended to my sizing, did.

Deprecating a field is the opposite case, and my own test says so: removal breaks every consumer still reading it, and undoing it once teams have shipped against the removal is expensive, so it stays wide blast radius and poorly reversible no matter how senior I get. What experience changed there is not that I now decide it alone, it is that I run the process myself instead of handing the whole question up: I pull usage telemetry showing which callers still read the field, publish a deprecation timeline, get explicit acknowledgement from the remaining consumers, and only then remove it. Seniority moved me from asking permission to owning the coordination, not from coordinating to not coordinating.

Escalation itself also changes shape with scope: two years ago "escalating" meant asking my direct manager. Now, if a decision affects a system a peer team's manager owns and mine doesn't, the right move is often to go straight to whoever actually holds the context, and that is two distinct moves worth keeping separate. A skip-level conversation means going to my own manager's manager, which is what you want when the call needs authority sitting above my manager. Going to the other team's lead is a lateral escalation across an org boundary, appropriate when the system in question is theirs and the decision is a technical one they own. Either can beat routing everything through my own manager first, because the person with the actual context to weigh in isn't always one level up in my own reporting line, but calling the lateral move a skip-level muddles who is being asked to decide and who is being asked to consent.

Trade-offs and pitfalls

Escalating everything reads as a lack of ownership and slows the whole team down. Deciding everything solo without telling anyone erodes trust and can blindside people even when the underlying call was correct. The goal to aim for is "decide, then over-communicate," not "always ask permission first."

Direct Answer

Score the three projects on the same short list of criteria (business impact, urgency, and what's irreversible if delayed), pick the one with the strongest combination rather than the single biggest number on any one axis, be able to name which single project you start first rather than only which two you fund, and be explicit that the third project isn't cancelled, it's sequenced, so the team doesn't hear "no" when the honest answer is "not yet."

The Framework

1. List the real constraint honestly: capacity for two out of three, so the exercise is genuinely a forced choice, not a search for a way to squeeze in all three badly.
2. Score each on impact, urgency, and reversibility: which one moves a number that actually matters this quarter, which one has a hard external deadline or window that closes if missed, and which one gets meaningfully harder or more expensive if delayed rather than just later.
3. Check for a hidden dependency: sometimes one project is a prerequisite for another, which changes the ranking regardless of its standalone score.
4. Communicate the decision as a sequence, not a rejection: tell the owner of the deprioritized project specifically when it's likely to be picked up and what would move it up sooner, rather than leaving it in limbo.

Worked Example

With three legitimate projects and capacity for two, I'd score them: one has a hard external deadline tied to a partner's contractual date (high urgency, high irreversibility if missed), one has strong long-term impact but no fixed deadline (high impact, low urgency), and one is a nice-to-have improvement request with moderate impact and no urgency. I'd fund the deadline-bound project and the high-impact project, and I'd start the deadline-bound one first. The reason is that its value is the only one of the three that can go to zero: miss the partner's contractual date and the work is worth nothing, while the high-impact project is worth the same whether it lands in week two or week eight, so it is the one that can safely be second. That also settles the collision case in advance: when both need the same engineer in the same week, the deadline-bound work takes the week and the high-impact work absorbs the slip, decided once at the start rather than re-argued every time it happens. I'd explicitly sequence the third for next quarter rather than declining it outright, telling its owner the specific reason (no hard deadline, so it's the one that can absorb the delay without real cost) and giving them a real date to expect it.

This same forced-choice pattern shows up with even less room to maneuver: facing three competing priorities from a CEO wanting fast revenue impact, research wanting foundational long-term investment, and product wanting near-term features, I'd apply the same logic but phase it rather than fully deprioritizing anyone: a small, fast win to satisfy the urgent ask while a slower foundational track runs in parallel at reduced scope, rather than picking one stakeholder's priority and telling the other two no. Similarly, when a product team wants a new feature in six weeks but the underlying data is known to be weak, the honest move is the same kind of negotiation: propose a phased scope, a fast, limited version now that's honest about its limitations, with the fuller, more robust version sequenced for later, rather than either quietly shipping something unreliable or flatly refusing the deadline.

Trade-offs and Pitfalls

• Picking projects purely by whoever's stakeholder has the most organizational power, rather than the actual impact and urgency criteria, erodes trust in the prioritization process over time.
• Framing a deprioritized project as "no" instead of "not yet, and here's when" turns a capacity decision into a relationship problem you didn't need to create.
• Phasing every hard choice to avoid saying no to anyone can become its own failure mode: sometimes the honest answer really is that one project won't happen this year, and dressing that up as "phased" just delays the disappointment.

Direct answer

The individual-contributor (IC) track and a first-time people-management track diverge almost entirely in what "success" is measured against: the IC track is measured by technical outcomes and how much you multiply other engineers' effectiveness, while management is measured by the team's output and retention at one remove from any single line of code. Both are leadership; only one comes with direct reports.

Structured elaboration

The personal signal worth paying attention to when choosing between them isn't "which one has more prestige", it's whether you get more energy from unblocking a specific person's career than from solving the hardest technical problem in the room yourself, and whether you're already informally doing 1:1-style coaching and finding you enjoy it.

Worked example

A senior engineer five years in notices they've started spending unscheduled time coaching two teammates through career decisions, and finds that more satisfying than the technical design review they also did that week. That's a real signal toward management, distinct from simply wanting more influence, since a staff IC role offers plenty of influence with no direct reports at all: it's a technical-leadership track, not an absence of leadership.

Trade-offs and pitfalls

Switching into management and later realizing you miss deep technical work is common and, in a healthy org, reversible, not a personal failure. The more common wrong turn is conflating "I want more influence" with "I should manage", when a staff-level IC role would satisfy that goal without the people-management responsibilities that come with the other track.

Direct Answer

Structure the 1:1 so roughly a third of it is unblocking today's work, and the rest is protected time for the promotion-relevant conversation: what stretch work or visibility they need to reach the next level, whether that's senior, staff (a senior individual-contributor, or IC, role whose scope spans multiple teams), or beyond, and what's actually blocking it. Pair that with a written development plan with named milestones, reviewed monthly, so the promotion case is built deliberately over months instead of assembled retroactively the week the packet is due.

1:1 Structure and Development Plan

• Weekly 1:1 split: quick blocker check-in first (keep it short and move it out of the 1:1 if it's a five-minute Slack fix), then the majority of time on one specific promotion-relevant thread: progress on a stretch project, a piece of feedback from a stakeholder, or a decision about what to say yes or no to next.
• Monthly development plan review: 2 to 3 named milestones tied to the actual promotion bar (own a cross-team initiative end to end, present technical work to a wider audience, mentor someone junior), each with a rough timeline and what evidence would prove it happened.
• Balancing blockers against stretch work: day-to-day blockers get triaged into "solve now" versus "this is actually a symptom of a scope or process problem worth raising up," and I explicitly protect the mentee's time for the visibility-building work by helping them say no to lower-value asks that would otherwise fill the calendar. Promotion-relevant work rarely gets prioritized on its own against urgent short-term asks unless someone actively defends the time for it.

Worked Example

I mentored a BI analyst with strong technical skills but almost no visibility outside her immediate team. Over a 12-month plan, we agreed on three milestones: own an end-to-end dashboard project with direct stakeholder presentation (not just building it), present findings to product leadership at least twice, and mentor a newer analyst. In 1:1s, when day-to-day dashboard bugs came up I'd help her triage which ones actually needed her versus could be delegated, specifically to protect time for the stakeholder-facing milestone. Around month nine, after two visible presentations and positive stakeholder feedback that reached her skip-level (her manager's manager) unprompted, she was promoted to a mid-level role with an expanded scope.

The same structure applies to building cross-team influence specifically: a mentee preparing for staff can have a milestone like "lead a proposal that requires buy-in from two teams you don't work with day to day," and the 1:1 time is spent debriefing what happened after each attempt, not rehearsing the pitch beforehand.

Trade-offs and Pitfalls

• Letting 1:1s become 100% blocker-clearing feels productive but never advances the promotion case; the mentee ends every quarter exactly where they started on visibility.
• A development plan with vague milestones ("build more influence") is unmeasurable; each one needs a concrete artifact or event you can point to later.
• Pushing stretch work onto someone who's already at capacity from day-to-day blockers sets them up to fail at both; sometimes the right 1:1 conversation is about what to stop doing, not what to add.