You’re Not Getting Promoted Because You’re Doing Your Job
The uncomfortable truth about performance and promotion committees
Welcome back to Path to Staff! This week, we have Danny Miller, an Engineering Manager with 20 years of experience who recently left Meta.
Danny sat on dozens of promo committees, particularly for the Senior → Staff jump for ICs. What he saw in those rooms is not what most engineers expect. I personally enjoyed this piece a lot because he uses an analogy to flying a plane. It makes the invisible mechanics of promo committees feel tangible in a way that most career advice doesn't. I hope it's as helpful for you as it was for me.
Without further ado, here’s Danny.
Most engineers treat their career like a commercial flight. They board, buckle in, and assume someone up front is steering them toward the next IC level.
They write code, hit deadlines, and expect the aircraft to carry them upward on schedule. Then one day they look out the window and notice they have been circling the same airport.
So they walk to the front. They open the cockpit door.
And the cockpit is empty.
No invisible hand steers their trajectory. Just a dashboard of gauges they have never been taught to read and a single empty seat. You expected your manager to be sitting next to you, wearing the captain’s hat, adjusting the altimeter. But there is no co-pilot’s chair. The manager isn’t in the plane at all. At best, your manager operates as air traffic control. They sit in a distant tower, managing a dozen other blips on a radar screen. They can grant you clearance, warn you of incoming weather, and advocate for your airspace at the promotion committee. They can’t pull the yoke. You’re supposed to be flying the plane.
Big tech runs on a myth of mechanical meritocracy. To the junior developer, the org chart looks like a ladder of pure output. Shovel enough story points into the furnace and you ascend. The bitter reality of big tech is that advancement functions entirely as a lagging indicator, an administrative echo of altitude you achieved months ago. The promotion process demands proof of sustained performance at the next altitude before it grants you the title. You must breathe the thin air of the next level for a calendar year, surviving without an oxygen mask, before the company agrees that you live there.
Engineers believe in the myth of the singular heroic event: diving into a monolithic codebase over a weekend and patching a catastrophic vulnerability that saves the company millions. Their reward will be a glowing review, a maximum bonus multiplier, and perhaps a commemorative acrylic desk ornament.
The reward won’t be a promotion.
A performance review evaluates your output against your current job description. A promotion committee, a tribunal of exhausted middle managers locked in a windowless room, evaluates your sustained operating velocity against a job description you don’t yet hold. Heroics are spikes. The promo committee demands a constant performance.
To survive the promo committee, your manager must answer a set of questions on your behalf (typically in a promo template). A relationship between an individual contributor and a manager can’t be a black box. It requires blunt partnership. A shrewd manager will share the blank promotion template from their org with you early on. They will strip away the mystery of promotion so you can actively work together on blind spots. If you haven't communicated with air traffic control the data, your flight remains in a holding pattern; your career circling without clearance to climb.
Most engineers assume good work is self-evident. It isn’t. Document obsessively. Not to brag, but to leave an audit trail for calibration. Six months later, nobody remembers who initiated the refactor unless there are receipts. Write the design doc. Send the follow-up post. Log the decision. The promo committee doesn’t reward vibes. It rewards artifacts. If there is no paper trail, the story will be rewritten. And you won’t be the author.
Who is flying the plane?
When the committee convenes, success is treated with suspicion. When presented with a flawless, high-impact project, their immediate reflex is to search for the stowaways.
They ask their first question. What did this person specifically do on the project? Did they build the ship, or did they merely occupy a comfortable cabin while someone else navigated?
How long have they been flying up there?
The committee will check for consistency. The question is always some variation of: How long has this person been operating at the next level? They want a sustained record, not a great quarter. You need twelve consecutive months at that altitude. The system doesn’t grade on a curve for bad luck.
You might lead a massive architectural overhaul for six months, only for a sudden reorg to pause the initiative. You spend the next six months working on something else before finding another “high-impact” project. To the committee, this isn’t a year of senior-level execution. It is an inconsistency. It is structurally unfair, but the reality of big tech is that organizational chaos routinely destroys the cohesion of a promotion narrative.
This unforgiving demand for continuous altitude in a highly unstable atmosphere is exactly why senior promotions are so hard to land.
Who chartered the flight?
You cannot piggyback your way up the corporate hierarchy. Riding the coattails of a Staff Engineer’s architectural masterpiece proves you can follow orders. It does not prove you can captain. And that Staff Engineer has their own expectations to meet. So the promo room will ask, politely: “And how much of this was actually theirs?”
The committee will demand to know the origin of the work. Did the candidate pull a perfectly scoped tech design document from the ether, or did they write the ticket? Did they identify the structural decay in the payment gateway, propose the migration strategy, and convince the stakeholders to pause feature work to fix it?
Executing handed-down tasks demonstrates reliability. Discovering, defining, and defending the work demonstrates the self-direction expected at higher levels. Instead of handing you pre-drawn maps, your manager must purposefully leave a vacuum for you to fill, ensuring they can clearly prove to the committee that you were the architect of the solution.
Autonomy matters more when people outside your team can see it. Build relationships with tech leads outside your immediate org. If you co-author a spec with a TL from another team, your visibility multiplies instantly. Your work has witnesses. Your name travels without you being in the room.
What is so spectacular about how they fly?
Then the committee engages in a speculative fiction exercise. “How would you expect an average engineer at the current level to do the work the IC did differently?”
This forces a clear way to show the difference between doing the job and outgrowing the job. If a mid-level engineer completes a complex data migration, the committee wants to know the inevitable disasters a standard mid-level engineer would have triggered. Advancement requires clear proof that you saw problems coming. If your manager can only speak of how you executed the requirements, you have simply succeeded at your current job.
I once tried to promote an IC5 to IC6 and kept getting the same question from the room. “Was the work technically complex enough for IC6?” The question sounded rigorous right up until you asked what it meant. And what does technically complex even mean inside a mature tech company? Most engineers aren’t inventing new sorting algorithms or proving theorems. They’re assembling systems from infrastructure that has been built over twenty years. Algorithms are already written. The RPC layer exists. The storage systems are battle tested. Nobody is discovering gravity between a privacy review.
So the real exercise to answer that question became framing. I stopped trying to prove the engineer had written some mythical piece of “advanced architecture.” Instead we started documenting the invisible complexity. Convincing three teams to adopt their framework. Negotiating with privacy on complex data retention rules that, if rejected, would have forced a significantly more complex solution. The argument that finally worked was an average IC5 would not have pulled this off. Promotion narratives are rarely about the code itself. They are about constructing a believable explanation for why the code mattered.
The committee cannot reward foresight unless someone writes down the catastrophes you quietly prevented.
Senior engineer endorsements are critical. Last-minute endorsement requests read like a cold email with “circling back” in the subject line. “We’ve barely spoken, but can you confirm I’m exceptional?”
At the start of the half, find someone already operating at N+1 or N+2 who actually matters in calibration. If needed, ask your manager for an intro. Book time monthly. Not to “network.” To work. Co-develop something real. A spec. A roadmap adjustment. A cross-team integration. Something with consequence. You’re an E5. You find an E7. You bring a real problem. I.e. your launch depends on three teams that all say “next half.” Or ranking quality varies wildly across entry points because each surface tuned its own model. Something big that affects multiple teams.
Ask for unfiltered feedback. Incorporate it publicly. Now when promotion season arrives, their endorsement is not charity.
How many other pilots are they leading?
The trope of the brilliant, isolated coder toiling in the dark is an organizational dead end. As you ascend, the limiting factor ceases to be your personal capacity to type valid syntax. The metric shifts to the radius of your influence, prompting the next question. “How many people did they lead or influence?”
Influence serves as the primary currency of senior engineering levels. The tribunal asks your manager to quantify your contagion. Did your testing framework become the default standard for three other teams? Did your design document change the mind of a skeptical principal (IC8) engineer? Did you mentor the junior developers to the point where they could review each other’s pull requests without your intervention?
A developer who operates as an island remains an island. To move up, your work must be visible in outcomes you didn’t directly execute. You must become the infrastructure. Your manager can function as your radio amplifier, putting you in the room where respect is earned by delegating architectural reviews or sponsoring cross-functional proposals. But you are the one who has to broadcast the signal. I remember an IC5 who didn’t own anything obviously broken. But they started attending SEV reviews anyway. Not just their team’s. Everyone’s. Over time, their name started showing up in the follow-ups. They became known to EMs and senior ICs as someone operating above the team level, seeing patterns others missed and shaping how problems were understood. It isn’t about who you know, it's about who knows you.
Grow another engineer. Pick someone at N-1 or N-2 and give them a real problem with risk attached. Let them draft the design doc. Let them run the review. Sit silently while they defend it. Debrief afterward. Show them where they missed stakeholders, underestimated migration risk, or overscoped the solution. Pull them into roadmap discussions. Expose the machinery. Speak with their manager about their strengths and gaps. That manager will likely sit in your calibration. Their anecdote about how you accelerated their engineer’s growth will carry more weight than your self-reported heroics.
What’s the weather up there?
Bureaucracy loves difficulty, but it distinguishes sharply between the tedious and the complex. Digging a trench with a teaspoon requires monumental effort, but it warrants no special recognition. So the committee asks, What made this problem hard?
They are probing for structural complexity. Was the difficulty derived from a messy legacy codebase, or was the fundamental mathematics of the algorithm untamed? Did the candidate have to herd cats across four different time zones and three distinct product vertical silos to get the API approved? The narrative must frame the friction as a barrier to the business, not just a barrier to the keyboard. Overcoming self-inflicted architectural wounds or navigating a poorly documented internal tool is part of the baseline expectation. Untangling a Gordian knot that unlocks a new revenue tier or permanently reduces cloud compute overhead is the type of friction the committee recognizes. It falls on your manager to translate your specific engineering friction into these headwinds, but you must provide the raw meteorological data.
Where are they flying to anyway?
Bureaucracies don’t care about technical elegance when it lacks business utility. You can engineer the most robust, fault-tolerant, perfectly abstracted distributed system in the history of the org chart. But if it powers a product vertical that zero customers utilize, your material impact rounds down to zero. The promo committee inevitably arrives at the ultimate question of corporate nihilism. “Who cares?”
You can absolutely end up performing N+1 level engineering on a doomed initiative. You will hear from time-to-time a manager in a calibration room say something in the vein of, “This project would have failed without [IC]! I mean okay yes it still failed, but it would have failed even more!”
The committee does not reward the heroic mitigation of irrelevant disasters. They do not care how beautifully you landed the aircraft if you touched down on an abandoned runway. To secure a promotion, you and your manager must demonstrate that the work moved a metric the business gives a shit about.
Because you are operating in an open partnership, you must collaboratively and ruthlessly evaluate the destination before you ever take off, ensuring that the payload you are delivering actually justifies the fuel spent.
If you are flying, then you need a flight plan. Ask your manager or your skip directly: “Which recent promotions were the strongest? What did actual N+1 work look like?” Study those examples like accident reports. Compare your current workload against them. Same scope? Same ambiguity? Same cross-team blast radius? It is risky to invent a fantasy version of N+1 in your head. Mimic what the organization has already rewarded. If your current work does not resemble those examples in size, ambiguity, and blast radius, the problem is trajectory. You may need to change the work. Or the team.
Proof or it didn’t happen
Promotions are political, but they are political around evidence. The system operates under an unspoken assumption of managerial bias. Of course your manager wants you promoted. It validates their leadership and expands their operational empire. The committee inherently distrusts the air traffic controller advocating for their own blip. Therefore, they demand artifacts, primarily authored by the pilot. And they demand an independent witness. “Is there a person already operating at the N+1 level (ideally N+2) who enthusiastically supports this promotion?”
I sat in several promotion committees for IC5 to IC6. An engineering manager would present a candidate with a packet full of accomplishments. Pages of bullet points describing migrations, frameworks, reliability improvements, performance wins. To the manager presenting it, these projects represented months of heroic engineering. To the rest of the room they looked like hieroglyphics.
The awkward reality of promotion rooms is that, more often than people realize, the room doesn’t actually understand the work being discussed. The other EMs usually don’t share your codebase, roadmap, or context. So the conversation collapses to “Why should we care?”
And that is when the packet either survives or dies. If the manager is the only witness to greatness, the room raises an eyebrow. If there are no endorsements from senior engineers, no external validation, no evidence the work mattered beyond one team, the tribunal becomes suspicious. You are essentially asking a room of strangers to approve a promotion based on your personal testimony. That request rarely clears the runway.
Ideally, endorsements come from outside your immediate reporting structure. It is one thing for your manager to claim your architecture is robust. It is a completely different reality when a senior engineer from a parallel platform team, someone with zero vested interest in your career progression, cares enough to write an endorsement. If you have not built collaborative, visible partnerships with the engineers already occupying the altitude you wish to reach, the committee will naturally conclude you are not ready to join them.
A capable manager acts as the guide to the org chart. They know which of the senior engineers carry actual weight in the room and which are merely decorative. A nod from a notoriously ruthless principal is treated as gospel. A rubber stamp from a checked out staff engineer is dismissed as noise. A tactical manager maps these personalities and subtly orchestrates collisions between you and the right gatekeepers months in advance. If an endorsement request arrives a week before calibrations, it looks exactly like a desperate political transaction. Build the connection early so the endorsement reads like an obvious conclusion, not a sudden discovery.
If you care about promotion, say it plainly. If you're worried you're under-scoped, say that too. If you suspect you avoid conflict in design reviews or over-index on execution instead of influence, surface it. Managers can't coach against information they don't have. Absent context, they default to generic advice: “communicate more”, “think bigger”, “drive impact”, “operate at the next level.” This advice circulates like an internal meme. It sounds profound, vaguely urgent, and just specific enough to be useless.
And if you do not trust your manager enough to do that, you have smoke in the cabin. Promotion runs through them. If the relationship is performative or adversarial, you are going to crash.
Switching managers does risk resetting the promo clock. New manager. New “observation period.” Fresh set of calibration notes that begin with, “Has not yet been observed at sustained N+1.”
Yes, that hurts.
But staying under a manager who cannot or will not advocate for you is a worse strategy. Promotion is not awarded to raw effort. It is assembled into a prosecutable case. Your manager is the attorney. If your attorney is disengaged, misaligned, or quietly skeptical, you are not “due.” You are more likely doomed for a “needs another half operating at N+1.”
Engineers overestimate the cost of resetting the clock and underestimate the cost of circling under weak advocacy. They tell themselves, “I’m close.” Close to what? A manager who does not articulate your impact will not suddenly discover the language in Q4. If they are vague now, they will be vague in calibrations.
Counterintuitively, resetting with a new team or manager is usually better than staying. Now the work can be intentionally scoped without historical baggage and three years of half-failed roadmaps. A delayed takeoff with a competent air traffic controller beats spending two years circling the runway while being told to “drive more impact.”
Are You Sure You Want to Fly the Plane?
Engineers regularly came to me with the same question. “I want to get to IC6. What should I do?” My first response was usually another question. “Why?”
The path to IC6 is rarely the triumphant career milestone people imagine. It is more like a bureaucratic obstacle course filled with variables you cannot control. Reorgs derail your projects. Roadmaps change mid-flight. Managers leave. Initiatives get sunset by a VP halfway through. The path is littered with false starts, stalled momentum, and just enough progress to keep you thinking you’re close. It takes a psychological toll to keep hearing, “maybe next cycle.”
I also think there is a misconception that promotion equals growth. It does not. Promotion means you have become a very specific type of engineer. One who operates at a particular level of ambiguity, influence, and political coordination. Some engineers genuinely enjoy that work. Others discover they prefer being closer to the code. There is nothing lesser about choosing not to optimize for promotion. Do not confuse being a strong engineer with being this particular kind of one.
Not everyone needs to want that job. But if you do, stop waiting for someone else to take the seat.
TL;DR:
Nobody is flying your plane. Your manager is air traffic control, not your co-pilot. Own your career trajectory.
Promotions are lagging. You must already be operating at the next level for ~12 months before the committee will recognize it. Heroic one-offs don’t count.
Get the promotion template early. Ask your manager to share the exact questions the committee will ask, then work backward to build the evidence together. Ask which projects in your org have successfully cleared the process before.
Originate the work, or at least the hardest parts. Don't just execute it. The committee wants to know you identified the problem, scoped the solution, and convinced stakeholders — not that you picked up a ticket.
Your job is to leave behind evidence of the disasters you prevented. Your manager’s job is to translate that evidence into a believable case that a less experienced engineer would not have navigated the work the same way.
Make your work influence others. The goal is not to be in the critical path. The goal is to remove yourself from it. If three teams depend on your testing framework but still need you to explain it every week, you didn’t scale the work.
Tie everything to business impact. Everything is “important” at kickoff. Very little is six months later. A beautifully engineered system powering a product nobody uses is a promotion-killer. Pick your battles before you fly.
Line up your independent endorsement now, not later. Build visible relationships with respected senior engineers outside your org months before the committee meets. Last-minute asks look desperate.
Thanks Danny for the write-up on promotions. If you enjoyed it, follow him on LinkedIn for more.
Interested in writing for Path to Staff! Reply and reach out with a perspective you’d like to share.