Why the brilliant SDE grinding at 2am keeps getting passed over — and what game theory tells us about it.
You Think You’re Playing Chess. You’re Actually Playing Poker.
Most engineers believe the promotion formula is simple:
Ship fast. Write clean code. Close tickets. Get promoted.
It’s not. And the reason isn’t unfairness or a bad manager. The reason is game theory.
You are not in a solo performance evaluation. You are in a multi-player strategic game where your outcome depends not just on what you do — but on what everyone else does, and what they perceive you to be doing.
The moment you understand this, everything changes.
The Four Games Every SDE Is Playing Simultaneously
Game 1: The Visibility Game
Your output only has value if the right people know it exists. Your manager doesn’t see your code at 2am. They see what surfaces in standups, Slack, and demos. Information is asymmetric — and the player who controls information flow has enormous power.
Game 2: The Coalition Game
Promotions are not decided by one person. They emerge from a coalition of voices — your manager, skip-level, peer reviewers, and cross-functional partners. The question that determines your career is not “what did you build?” It is “who is speaking for you when you’re not in the room?”
Game 3: The Signaling Game
Others cannot directly observe your competence. They read signals — your confidence in design reviews, the problems you volunteer for, the language in your documents. Competence without signal is invisible competence. It counts for nothing.
Game 4: The Reputation Game
This is a repeated game. Every interaction updates someone’s mental model of you. Miss one deadline loudly and it sticks for quarters. Nail ten things quietly and it fades by Friday. The compound interest of reputation is brutally asymmetric.
Why Pure Competence Is a Dominated Strategy
In game theory, a dominated strategy is one that always produces worse outcomes than an alternative — no matter what other players do. Relying purely on technical output is a dominated strategy.
Meet Aarav and Riya:
- Aarav writes flawless code, resolves P0s at midnight, and never misses a deadline. He believes the work speaks for itself.
- Riya ships solid work, narrates her decisions in design reviews, builds relationships across teams, and makes her impact legible to leadership.
In a pure meritocracy, Aarav wins. In the actual game — where promotions require coalition, signal, and narrative — Riya wins. Not because she gamed the system, but because she played the real game while Aarav played an imaginary one.
The Nash Equilibrium Nobody Tells You About
A Nash Equilibrium is a stable state where no player can improve their outcome by unilaterally changing strategy, given what everyone else is doing.
In most companies, the equilibrium looks like this:
Strong technical output + visibility + internal allies = best stable outcome
If everyone around you is playing the visibility game, the engineer who opts out unilaterally loses ground — even if their code is objectively better. This is the trap. Refusing to play visibility games feels principled, but in game theory, refusing to play is still a move. And it’s a losing one.
Why Competent SDEs Get Skipped for Early Promotion
Here is the central paradox: the most technically skilled SDEs are often the worst at getting promoted early.
- They optimize the wrong variable: They go deep on code quality and system design. These matter — but they are necessary, not sufficient.
- They underinvest in repeated interactions: Relationship-building is a repeated game. An engineer with 50 low-stakes positive interactions with a VP has more influence than one with a single brilliant architecture discussion.
- They mistake legibility for self-promotion: Making work understandable to non-engineers is not bragging — it is translation.
- They ignore the coalition structure: Promotion committees don’t see your code. They see the narrative constructed during calibration.
- They play a one-shot game in a repeated environment: They treat each quarter as independent, ignoring that reputation compounds over years.
The Five Moves That Actually Drive Early Promotion
Competence is the entry ticket. Here is what separates early promotions from everyone else:
- Narrate your reasoning, not just your output. Don’t just close the ticket. Write one paragraph on why you made the tradeoff you did.
- Make other people’s wins possible. Unblock colleagues publicly and attribute wins generously. This creates allies who advocate for you without being asked.
- Own a problem, not a task. Task-completers get rated "at level." Problem-owners get promoted above it. Volunteer for the ambiguous, messy things.
- Manage upward with outcomes, not effort. Give your manager ammunition. "I reduced latency by 40ms, which unblocks the mobile team’s Q3 launch" is a promotion argument.
- Build a personal board of directors. Identify 3–5 senior people across functions who respect your work. Their affirmation in a calibration session is worth more than any single project.
The Uncomfortable Conclusion
The engineer who gets the early promotion is not always the best engineer. They are the engineer who understood the actual game being played — and played it well, while also being technically strong enough.
This is not an argument to trade engineering excellence for office politics. It is an argument to stop treating excellence as sufficient when it is only necessary.
The most dangerous belief in a software engineering career is that the work speaks for itself. It doesn’t. You have to speak for it.
Top comments (0)