Skip to main content

Framework: Aligning Projects With Your Next-Level Goal

A framework for choosing projects that build the exact signals your next promotion requires — not just projects that keep you busy.

You’re two years into a level. You’re shipping. Your reviews say “strong performer.” But the promotion doesn’t land because the projects you’ve shipped don’t demonstrate the right things. Not bad things — the wrong things. The projects were hard, but they were hard at the wrong layer.

This framework helps you sort projects by promotion signal before committing your next quarter to them. The position is that project selection is the highest-leverage promotion lever you have — higher than execution quality, higher than visibility, higher than story-telling in the loop. If you’re working on the wrong project, working harder on it doesn’t close the gap.

The problem

The naive failure mode is letting your backlog decide your trajectory. Your manager assigns you work that needs doing. You do it well. At promo time, the calibration committee looks at what you did (not how), and the what doesn’t demonstrate next-level scope or judgment. You’ve been productive in ways that don’t accumulate toward anything.

The other naive failure mode is visibility-chasing: picking projects that are high-profile but low on the specific signals your level transition needs. A senior engineer who ships a visible feature that could have been done by a mid-level is still demonstrating at mid-level — regardless of how many people noticed.

The fix is deliberate: read the promotion requirements backward into project attributes, then select projects that carry those attributes. That’s the framework.

The framework: the signal-gap method

Three steps, in this order. Steps 1 and 2 happen once per quarter. Step 3 is continuous.

Step 1: Decode the next-level requirements into signal categories

Every rubric at every company boils down to four signal categories (the same ones that drive the three-axis promotion model):

Signal categoryWhat it means in project language
ScopeCross-team, multi-quarter, ambiguous problem space, or owning a system others depend on
Technical depthNovel solution to a hard problem, or an architecture decision with lasting consequences
LeadershipMoving other people’s work (mentoring, unblocking, setting direction)
Business impactA metric a non-engineer cares about moved because of the project

Read your company’s rubric (or your manager’s words) and map each requirement to one of these four. Most levels emphasize two heavily and the other two exist as baseline expectations. The two that are emphasized are where project selection matters.

For example:

  • IC4 → IC5 (senior → strong senior): usually scope + technical depth. The promotion narrative is “owned something cross-team and solved a hard problem in it.”
  • IC5 → IC6 (strong senior → staff): usually scope + leadership. The promotion narrative is “set technical direction that changed what multiple teams built.”
  • IC3 → IC4 (mid → senior): usually technical depth + business impact. The promotion narrative is “independently drove a project with real business results.”

The specific words vary. The shape doesn’t.

Step 2: Identify the gap

For each of the four signal categories, score yourself honestly:

  • Strong — you have 2+ recent projects (last 18 months) that unambiguously demonstrate this signal.
  • Partial — you have one project that partially demonstrates it, or the project is too old.
  • Gap — you have no project that convincingly demonstrates this.

The gap categories are where your next project needs to land. Not your strongest categories (you’re already covered there) and not all four (spreading across all four produces no strong signal anywhere).

The diagnostic test: could your manager write a single compelling sentence about this signal on your promo packet, citing a specific project? If the answer is no, it’s a gap.

Step 3: Evaluate every project against the gap

Before committing to a project (volunteering, accepting the assignment, kicking one off), score it against only your gap categories:

QuestionScore
Does this project require the scope dimension I’m missing?+2 per gap category it fills
Will this project produce a measurable outcome in <6 months?+1 if yes, -1 if vague timeline
Can I articulate the promotion sentence this project enables?+1 if yes, 0 if maybe
Would a person one level below me also be given this project?-2 if yes

If the score is 0 or negative, the project doesn’t advance your promotion — even if it’s important, interesting, or high-visibility. You don’t have to reject it. But you should know that it’s maintenance work (keeping you at level) rather than growth work (moving you to the next one).

How to apply it: three worked examples

Example 1: The senior engineer with a depth gap

You’re IC4 targeting IC5. Your gap analysis says scope is strong (you already own a cross-team system) but technical depth is partial (your last technically hard project was 20 months ago). Leadership is partial; impact is strong.

Two projects land on your plate:

  • Project A: Build a new admin dashboard for the internal ops team. High-visibility, many stakeholders, 3-month timeline.
  • Project B: Design and implement the new caching layer for the search service. Technically complex (consistency, eviction, partial failures), medium visibility, 4-month timeline.

Score them against the gap (technical depth):

  • Project A: scope-neutral (single team, no system ownership), depth-zero (UI work at the level any mid-level could do), impact-partial (ops efficiency), leadership-neutral. Score: -1 (below-level work).
  • Project B: scope-neutral (extends existing ownership), depth-high (novel architecture, distributed systems problem), impact-measurable (search latency), leadership-neutral. Score: +3 (fills the gap).

Project B is the promotion project. Project A is fine work that doesn’t move the needle. The framework makes that choice explicit before you’re three months into the wrong one.

Example 2: The strong senior targeting staff with a leadership gap

You’re IC5 targeting IC6. Technical depth and scope are strong — you’ve shipped complex systems across teams. The gap is leadership: calibration feedback says “strong individual contributor, less evidence of influencing direction.”

A rewrite of the data pipeline lands on the roadmap. Two ways to engage:

  • Option A: Own the implementation of the hardest component.
  • Option B: Define the technical vision, write the RFC, sequence the migration plan, and delegate the hardest implementation to engineers who need the depth-signal.

Option A fills a depth category you already have. Option B fills the leadership gap: you set direction, you elevated someone else’s work, you influenced what three engineers built for a quarter. Same project — completely different promotion signal depending on how you engage.

The framework’s move: before committing to how you’ll work on a project, check which gap it’s filling and engage at the layer that fills it. Depth problems need you in the code. Leadership problems need you above the code.

Example 3: The mid-level engineer with an impact gap

You’re IC3 targeting IC4. Your depth is strong (you solve hard problems) and your scope is growing. But you’ve never shipped something where you could write “X metric moved from A to B because of my work.” Your projects have been infrastructure-internal with no visible business outcome.

The framework’s prescription: find a project where the engineering work ladders up to a product metric. That might mean:

  • Volunteering for a performance optimization project where the outcome is conversion or retention, not just “p99 dropped.”
  • Adding instrumentation to your existing system to make the impact measurable, even retroactively. You may already have the impact; you just can’t point to the number.
  • Partnering with the product team on a feature where you own the backend, and aligning on which metric the feature is expected to move.

The trap to avoid: building a beautiful internal tool that no customer ever touches. Infrastructure work can demonstrate impact, but only if you explicitly connect it to downstream product or team-velocity metrics. “I built a deploy pipeline” is invisible to calibration. “I built a deploy pipeline that increased ship frequency from 2x/week to 12x/week” is impact.

Where this framework breaks

Three places.

Teams where you don’t get to choose. Some orgs rigidly assign work. The framework assumes you have at least partial agency over project selection — through volunteering, negotiation with your manager, or 20%-time. If you genuinely cannot influence what lands on your plate, the framework’s value is diagnostic (it tells you whether you’re accumulating the right signal) but not prescriptive (it can’t change the assignment). In that case, the right move is usually to change teams — which is itself a decision the framework can inform.

Early career (junior → mid). At this transition, the signal categories collapse to “can you independently deliver a feature end-to-end.” Project selection matters less than execution quality. The framework is designed for IC4+ transitions where calibration committees deliberate over signals.

Startup environments without levels. No ladder means no gap analysis. The framework is designed for companies with rubrics and calibration. In a startup, pick projects that build skills and reputation for whatever your next career move is (joining a larger company, raising a round, building authority). Different framework — closer to resume-enriching projects.

The framework also has a structural failure mode worth naming: over-optimizing for promotion signal can make you fragile. If every project is selected for its gap-filling value, you may avoid projects that build new skills that don’t fit your current gap. The long game — career durability over decades — requires occasional signal-neutral investments that broaden your surface. The framework is for the 12-month window of a promotion push, not a career philosophy.

What this framework is really saying

Project selection is the hidden variable in most stalled promotions. The work itself is good; it’s just good at the wrong layer. The framework’s one move is to make the expected layer visible before you commit, so the gap between what you’ve demonstrated and what you need to demonstrate shrinks deliberately, not by accident.

The compound effect of one well-chosen project per quarter — picked for gap-filling, not for difficulty or visibility — is usually enough to close the promotion in 2–3 quarters. The compound effect of four random projects per quarter, even brilliantly executed, is often zero accumulation. Choose first. Execute second.