Two engineers join the same team on the same day. Same college, same GPA, same coding ability. Three years later, one is a senior engineer being groomed for staff. The other is still a solid mid-level, wondering what happened.
Here's the uncomfortable part: the second engineer probably worked harder. Definitely logged more hours. Fixed more bugs. Responded faster on Slack. Was more "available."
The difference was not talent. It was not effort. It was not even luck — not entirely. The difference was what they chose to work on.
Most engineers treat project selection like a passive thing. Work comes in, you pick up the next ticket, you do good work, someone notices. That's the model. And in a small team or an early-stage startup, it works fine.
But in a mid-size or large engineering organization — Google, Meta, Amazon, any serious tech company with multiple levels and a structured promo process — that model will quietly strangle your career. Not because you're doing bad work. But because you're doing the wrong work.
This chapter is about making that invisible force visible. Once you see it, you can't unsee it — and you'll start making decisions that compound over years, not just weeks.
The Dirty Secret of Big Tech Promotions
Let's start with how promotions actually work, because most engineers have a fantasy version in their head that doesn't match reality.
The fantasy: you work hard, build good things, your manager sees it, they write it up, and the committee approves. Hard work in, promotion out.
The reality: promotions happen in calibration sessions where a group of managers argue over a limited number of slots. Your manager — your advocate — is in a room with eight other managers, all of whom also have engineers they're pushing for. Everyone thinks their person is great. The question is not "was this person good?" The question is "was this person's impact visible and undeniable to people outside their immediate team?"
And here's the kicker: the stories that win in calibration rooms are not stories about maintenance work, bug fixes, or being reliable. They're stories about movement. Projects that changed something. Systems that unlocked new capability. Work that other teams noticed and talked about.
The calibration room insight: Your manager needs to be able to say three sentences about you that make other managers nod. Those sentences are about impact, not effort. "She fixed 47 bugs" doesn't win. "She unblocked three teams by rebuilding the auth system" wins.
Now think about the projects on your current plate. What's the three-sentence story your manager could tell about you right now? If you're not sure, keep reading.
Not All Work Is Created Equal
This is the idea most engineers resist, because it feels unfair. And honestly, it kind of is unfair. But fairness is a separate debate. Right now we're talking about reality, and the reality is this:
The same amount of effort applied to different projects produces wildly different career outcomes.
Some work is high-leverage, visible, and career-compounding. Other work is necessary, appreciated in the moment, and completely invisible at promo time. The tragedy is that nobody tells you which is which. You're just supposed to figure it out.
Let's make it explicit. There are two axes that matter:
- 1. Visibility — Does this work surface to people outside your immediate team? Does it get talked about in all-hands, design reviews, or other team's planning meetings?
- 2. Strategic value — Does this work move the needle on what the org actually cares about this year? Is it tied to a company priority, a big bet, an OKR that leadership checks every month?
Plot those two axes and you get four quadrants. Most engineers live in the wrong ones for most of their career.
When you look at your current work, most of it is probably in Q3 or Q4. That's not an insult — it's just the natural gravity of big engineering orgs. Low-visibility, reactive work flows toward whoever is available and responsive. That often means the most diligent, reliable, "good team player" engineers — in other words, the people who deserve to grow the most.
The reliability trap: The engineers who are best at Q3 work — fast, dependable, no drama — are the ones most likely to get more Q3 work assigned to them. Organizations unconsciously exploit their most reliable people. Being good at the wrong work is a trap.
What a Franchise Problem Looks Like
The term "franchise problem" comes from sports. A franchise player is the one who changes the ceiling of the team. Without them, you're a decent team. With them, you're a contender.
Franchise problems in engineering are similar. They're the problems that, if solved, change what the entire organization can do. They're not just important — they're structurally important. Other work depends on them being solved.
Here's how to recognize one:
| Signal | What it looks like | Career value |
|---|---|---|
| Multiple teams are blocked by it | Three teams have it on their risk list in planning | Very high |
| Senior leaders mention it unprompted | Your VP brings it up in the all-hands | Very high |
| It's tied to a company-level OKR | It's in the S-team or exec deck, not just your team's planning doc | Very high |
| Nobody owns it clearly | Everyone agrees it's important but there's no clear DRI | Very high |
| It's technically hard but not impossible | Smart people have looked at it and said "this needs someone to really dig in" | High |
| Solving it unlocks other projects | If this is done, four downstream things can happen | Very high |
| It's only on one team's roadmap | Nobody outside your team tracks it | Low |
| It's a bug or reliability issue | Even critical bugs are reactive; solving them is expected, not celebrated | Low |
The best franchise problems have a specific shape: they're painful enough that leadership feels it, broad enough that multiple teams care, and ambiguous enough that no one has grabbed them yet. That last part is key. Ambiguity is where careers are made. When something is clearly scoped and assigned, the person who does it gets credit for execution. When something is a mess that someone had to make sense of — and then solve — that person gets credit for judgment, leadership, and execution.
The Maintenance Engineer Trap
Let's talk about a specific kind of invisible work that swallows careers whole: owning legacy systems.
It starts innocently. You join a team, you ramp up, and you get assigned to a legacy service because "someone needs to keep it running." You're good at it. You learn the code deeply. You fix the weird bugs. You add the monitoring. You own it.
Two years pass.
You're still good at it. You're indispensable, in fact. The problem is that "indispensable" is not the same as "promotable." Indispensable means nobody wants you to leave your current role. Promotable means people are actively pulling you forward.
Priya has owned the payment processing legacy service for 18 months. She knows it better than anyone. She fixed four P0 incidents, added comprehensive logging, and halved the on-call burden. Her manager loves her. The team relies on her.
At promo calibration: "Priya is great. We'd be lost without her on payments." Response from the committee: "So she's doing her job. What did she build? Who did she influence? What's different now because of her?" Silence. No promo.
This is not a failure of talent or effort. Priya worked hard and did important work. The failure was strategic. She let herself become the custodian of something old instead of the architect of something new.
Here's the move Priya should have made: use the deep knowledge she built about the legacy system to write the migration plan. Own the future of that system, not just its present. Turn "I maintain this old thing" into "I'm leading the modernization of our payment infrastructure." Same technical knowledge, completely different career narrative.
The maintenance escape hatch: If you're stuck owning legacy work, the way out is to use your knowledge as a foundation for ownership of the next version. Write the RFC. Propose the migration. Become the person who defines what replaces the thing you currently maintain. Your deep context is an asset — but only if you use it offensively, not defensively.
How to Read the Political Terrain
Good project selection is partly about technical judgment and partly about organizational reading. The second part is what most engineers skip because it feels vaguely political, and engineers are trained to distrust politics.
Let's get over that. Reading org priorities is not dirty politics. It's just paying attention. Here's how to do it cleanly.
Listen to what leadership keeps mentioning
Every organization has a short list of things that senior leadership genuinely cares about right now. They mention these things in all-hands, in town halls, in the engineering blog, in planning kickoffs. They repeat themselves constantly, because leaders think repetition means clarity.
Most engineers hear these messages and think: "Yeah, sure, company priority, whatever, back to my tickets." The strategic engineer hears these messages and thinks: "Where does my team's work intersect with this? How do I get on one of these threads?"
If leadership is saying "we need to close the loop on developer velocity" every quarter, and your team owns internal tooling, that is a franchise problem sitting right in your backyard. Go claim it.
Watch where senior engineers are spending time
Senior and staff engineers are organizational weather vanes. They are usually good at sniffing out where leverage lives, because their level requires it. When you notice multiple senior engineers circling around a problem space — even if they're not officially assigned to it — that's a signal.
Don't be intimidated. Get curious. Talk to them. Understand the problem. Find the angle they're not covering and own that. You don't have to eat the whole elephant to build a relationship with it.
Find what's on the risk register
In planning cycles, teams keep informal and formal risk lists. "Thing X is going to blow up if we don't address it." "We have a known scalability cliff at 10x load." "Our auth system hasn't been touched in four years and nobody understands it."
These are franchise problems with a timer on them. The team knows they need to be solved but hasn't prioritized them yet. The engineer who proactively writes the proposal to fix one of these wins on multiple dimensions: they look ahead of the curve, they own something strategically important, and they solve a problem that makes their manager's life easier.
The Courage to Say No
Here's the part of project selection that nobody talks about, because it requires something harder than technical skill. It requires the ability to say no to good-enough work in order to make space for great work.
That sounds simple. It is not.
The forces pushing you toward bad project selection are enormous:
- Your manager assigns you something because it needs to get done and you're good at it
- A colleague asks for help and you don't want to let them down
- A P1 bug comes in and you're the fastest one to fix it
- Nobody else wants the legacy work and you feel guilty leaving it
- The high-visibility project is "too risky" and you're not sure you can pull it off
Every single one of these is a real pressure. Every single one of them is a way that good engineers fill their year with work that doesn't compound.
The ability to say no — gracefully, professionally, without damaging relationships — is a genuine skill. It's also one of the clearest signals of seniority. When you see a Staff engineer turn down work, they're not being selfish. They're protecting the strategic bets that are most likely to create leverage for the whole team. That's the job at that level.
A useful reframe: Saying yes to low-leverage work is not just a personal career problem. It's an organizational problem. You are a finite resource with high capability. When you spend 60% of your time on Q3 work, the org is allocating its best resources to its least important problems. Saying no to the wrong work is a form of stewardship.
Here's how to say no in practice. Don't say "I don't want to do this." Say: "I want to make sure I'm focusing on the highest-leverage work. Here's what I'm currently committed to. Can we talk about prioritization? I want to make sure I'm not spreading too thin."
That's not a no. That's a conversation about resource allocation. It's professional, it's mature, and it puts the decision in the right place: with your manager, with full information.
Timing: When to Grab, When to Wait
Project selection is not just about which project — it's about when. Timing is a dimension most engineers completely ignore.
Here's a counterintuitive truth about franchise problems: the best time to grab them is before they become urgent. Once a problem is on fire, the org will assign it to whoever is most available. That's usually whoever has been most visibly idle, or whoever is seen as the "fixer" — not necessarily the right person for the strategic ownership.
Ravi notices in Q3 planning that search latency is mentioned as a "watch item" for next year. No urgent ticket exists. Nobody is assigned to it. He spends two weeks doing a quiet investigation, talks to a few people, and writes a short internal doc: "Search Latency — What We Know, What We Don't, and a Proposed Path."
He shares it with his manager. His manager shares it in the weekly eng sync. By Q4 planning, when search latency has become a real priority, Ravi is the obvious person to own it — because he already understands it better than anyone and he already has a point of view. He gets the project. He gets the visibility. He gets the credit.
What Ravi did there was not lucky. It was a specific pattern: identify a problem that is important but not yet urgent, invest early to build context and a point of view, and then surface that investment at the right moment. By the time the org needed to assign ownership, the answer was obvious.
Early context is leverage. The engineer who understands a problem first can shape how the entire org thinks about it.
The 70/20/10 Allocation Rule
Here's a practical framework for thinking about your work allocation at any point in time. It's not a rigid prescription — think of it as a calibration tool.
| Allocation | Type of work | Purpose |
|---|---|---|
| 70% | Your primary franchise problem — Q1 work | This is where your career story lives. Protect this time like it's sacred. |
| 20% | Team health work — the Q2/Q3 things that have to happen | Reliability, mentoring, code review, reasonable on-call burden. Necessary, bounded. |
| 10% | Early exploration — future franchise problems | Build context, write a small doc, talk to people about what's coming. Plant seeds. |
Most engineers accidentally run something like 20/70/10 — 20% on strategic work, 70% on team health and reactive work, 10% on whatever fires are burning. And they wonder why they feel busy but not growing.
Flipping those first two percentages is the single most impactful career move available to most engineers right now. It doesn't require a new job, a new manager, or a new skill set. It requires ruthlessness about how you spend the 8 hours in your day.
Talking to Your Manager About This
None of this works in a vacuum. Your manager controls a significant fraction of what you work on. If they keep assigning you Q3 work, you need to have an explicit conversation — not a complaint session, a calibration.
The conversation goes something like this:
"Hey, I've been thinking about my promo timeline and I want to make sure I'm building the right narrative. Looking at my last six months, most of my work has been on [X and Y]. I'm proud of it but I'm not sure it maps clearly to the kind of impact that makes a compelling case at the next level. I'd love your take on where the highest-leverage projects are right now, and how we can carve out some space for me to go deep on one of them."
That conversation does three things at once. It shows self-awareness. It shows ambition that's aligned with org goals, not just personal advancement. And it gives your manager information they can use to actually help you — because now they know you're ready for a bigger swing, and they can put you in position for one.
Most managers want to advocate for their people. Give them the material to do it.
The Narrative You're Building
Zoom out for a moment. Every project you take on adds a line to a story. Over a year, that story either makes a compelling case for your next level or it doesn't.
The question to ask about every significant project you consider is not "can I do this?" It's: "In twelve months, when my manager is in a calibration meeting, what's the sentence they'll say about this work — and is that sentence the one I want attached to my name?"
A year from now, which story are you building?
"She was incredibly reliable. Fixed a bunch of bugs in the payments service. Was great at on-call. The team really depends on her."
"She led the migration of our payments infrastructure off the legacy system. Three teams were unblocked. We retired 40,000 lines of decade-old code. She wrote the RFC, built the consensus, and drove the execution. We would not have been able to ship [product X] without this work."
Both of those engineers might have worked the same number of hours. The difference is where those hours went.
The Honest Audit
Here's your homework. Right now, before you close this chapter, open a blank doc and answer these five questions honestly.
- What is the single most important project I'm working on right now? Does it live in Q1 of the impact matrix?
- What percentage of my time last week went to reactive, Q3 work (bugs, maintenance, unplanned requests)?
- What problem does my organization have that nobody clearly owns? Have I considered claiming it?
- If my manager were in a promo calibration today, what would they say about my impact in the last six months? Would that be enough?
- What is one piece of work I should stop doing — or delegate — in order to create space for higher-leverage work?
Don't answer these in your head. Write them down. The act of writing forces you to be honest in a way that mental answers don't.
The Summary in One Paragraph
In large engineering orgs, effort is assumed. Everyone works hard. The engineers who accelerate fastest are the ones who work hard on the right things — high-visibility, strategically important problems that other teams depend on and senior leaders track. They learn to read the org, identify franchise problems before they become urgent, claim ownership through early investment, and protect their time ruthlessly against the constant gravity of reactive, low-leverage work. They also have explicit conversations with their managers about this, giving their advocates the material they need to tell a compelling story. None of this requires political games. It requires clarity, intentionality, and the courage to treat your own time as the finite, high-value resource that it is.