How to Pick Projects That Actually Get You Promoted

Most engineers pick projects based on what sounds interesting. That’s how you end up with a great portfolio of work that nobody outside your immediate team has ever heard of.

Promotion committees don’t reward interesting. They reward visible impact on problems that matter to the organization.

I spent twelve years at Facebook watching this pattern play out. Engineers who got promoted weren’t always the strongest coders on the team. They were the ones who understood which problems mattered, built the right things, and made sure the right people knew about it. Engineers who stayed stuck were often just as talented, but they optimized for craft over leverage.

Here’s what I learned from being on both sides of that table.

The Visibility Problem Nobody Talks About

When a promotion packet lands in front of a committee, the reviewers are asking one question: where was this person operating?

Not what did they build. Where were they operating.

If all your work affected one team, you’re operating locally. If your work affected three teams, you’re operating cross-functionally. If your work changed how the organization solves a category of problems, you’re operating at a systems level.

Each of those maps to a different level on the ladder. Local impact is table stakes. Cross-functional impact gets you to senior. Systems-level impact gets you to staff and beyond.

The problem is that most engineers pick projects without thinking about this at all. They take what’s assigned, raise their hand for things that seem technically interesting, or volunteer for work that helps their immediate team. That work might be genuinely excellent. But excellent local work is not the same as visible organizational impact.

What Makes a Project Promotable

I’ve seen hundreds of engineers get promoted and hundreds more get passed over. The projects that carried promotions had a few things in common.

They had a clear before and after. Not “improved performance” but “reduced API latency from 800ms to 120ms, which unblocked three dependent teams and eliminated the most common support escalation we were getting from sales.” Vague impact doesn’t hold up in a committee room when someone asks a follow-up question.

They touched more than one team’s roadmap. When your work shows up in another team’s priorities, that’s a signal you’re operating above your immediate scope. Cross-team dependencies are messy and political, which is exactly why most engineers avoid them. They’re also exactly why they carry weight in a promotion case.

They solved a problem that leadership had explicitly named. Not a problem you identified independently, not a problem your manager mentioned once in passing, but a problem that was on the quarterly roadmap or that a director had said out loud in an all-hands. When the problem is already on leadership’s radar, your solution gets seen by people who have context on why it matters.

Someone above your skip-level knew about them. This one’s uncomfortable to say, but it’s true. Promotion decisions at most companies involve people who have never seen you write code. If the only people who know about your work are your immediate teammates and your manager, your promotion case depends entirely on your manager being a good advocate. Some managers are great advocates. Many are not.

How to Evaluate a Project Before You Take It

Before committing to a piece of work, run it through these questions.

Who cares about this problem, and what level are they? If the answer is “my team” and nothing above that, the project has low promotional leverage. If the answer is “two other teams are blocked by this” or “this is on the VP’s radar for Q3,” you’re in better territory.

What’s the counterfactual? If you didn’t do this project, what would happen? If the answer is “someone else would do it” or “we’d find a workaround,” the leverage is lower. If the answer is “this problem would go unsolved for the foreseeable future because nobody else has the combination of skills and context to tackle it,” you’re in good territory.

Is there a number attached to the outcome? Not everything has a clean metric, but more things do than engineers usually assume. Latency, error rates, deployment frequency, number of teams unblocked, hours saved per week for downstream teams. If you can’t articulate even an approximate number before you start the project, figure out how you’ll measure success before you commit.

Does this create work for you to talk about, or just work to ship? Some projects are genuinely worth doing but produce nothing to present, nothing to write about, nothing to anchor a design document around. Those projects still need to get done. But they’re not where you put your discretionary energy when you’re trying to get promoted.

The Portfolio Approach

You probably don’t get to choose every project you work on. A lot of your time is legitimately committed to maintenance, bugs, on-call, and whatever the team’s current priority is.

But most engineers have more discretionary time than they realize. A few hours a week. The ability to propose a project rather than wait to be assigned one. The chance to volunteer for cross-team work that nobody else has raised their hand for.

Think of this discretionary time as a portfolio. One or two projects per cycle that have real promotional leverage. The rest of your time covers your commitments and keeps the team running.

The engineers I saw get promoted consistently weren’t working more hours than their peers. They were making better choices about where their marginal time and energy went.

A Common Mistake: Picking Projects Based on Tech

Engineers love interesting technology. Distributed systems, new languages, machine learning infrastructure, whatever the current thing is. There’s nothing wrong with working on interesting technology. But “this uses a novel approach” is not a promotion argument.

I’ve seen engineers spend a year building something genuinely sophisticated that had almost no impact on anyone outside their team. Technically impressive. Promotionally irrelevant.

The question is never “is this interesting?” The question is “who does this help and does anyone above the team know about it?”

What to Do Right Now

Look at what you’re working on. For each project, write one sentence describing who it helps beyond your immediate team. If you can’t write that sentence, that project won’t carry weight in a promotion case.

Then look at what’s on your organization’s roadmap. What problems does leadership talk about that don’t have obvious owners? That’s where your next project should come from.

Pick something hard enough that it’s not already assigned. Make sure there’s a number you can attach to the outcome. Find out if another team cares about the solution. Build it well. And then make sure the people who make promotion decisions know it happened.

That last part is its own skill, and it makes a lot of engineers uncomfortable. But you can’t be promoted on work that nobody above your manager has ever heard of. That’s not how committees work.

The interview process tests whether you can think and communicate under pressure. The promotion process tests whether you’ve been solving the right problems in a way that’s visible to the right people.

Both are skills. Both can be developed.

If you’re preparing for interviews at companies where this kind of thinking gets evaluated directly, the Software Engineer’s Interview System covers how to talk about your work in a way that demonstrates you’ve been operating at the right level.