You know that engineer who keeps getting promoted? The one who launches flashy projects that never quite ship, who volunteers for every high-visibility initiative but somehow never fixes the bugs that keep everyone up at night?
Yeah. They’re not the problem. You are.
Every tech company has the same disease. It’s called Promotion-Driven Development, and it’s eating your organization from the inside out.
Here’s how it works: An engineer realizes that promotions don’t come from maintaining critical infrastructure or quietly fixing things that matter. Promotions come from building new things — things that look impressive on a promo packet, things that generate metrics you can point to in a calibration meeting.
So they optimize. Not for the business. Not for the customer. For the promotion committee.
People don’t game the system. The system games people.
I’ve watched this play out dozens of times. The engineer who spent six months migrating a legacy system — you know, the unglamorous work that kept the company from crashing — gets a “meets expectations” rating. Meanwhile, the engineer who spent six months building a shiny new tool that nobody asked for, that was abandoned three months after launch, gets promoted.
Why? Because the promo packet looks better. “Led initiative to build X” sounds more impressive than “Maintained Y so nothing broke.”
The result? Your best engineers — the ones who care about the actual product — either leave or learn to play the game. And the game is this: build things that look good on paper, regardless of whether they create value.
When you promote people for building things nobody needs, you get a company full of people building things nobody needs.
Now here’s where most leaders get defensive. “We can’t blame the system! Engineers should take ownership! They should care about business value!”
Stop. Just stop.
You designed the incentive structure. You defined the promotion criteria. You created the calibration process that rewards visibility over value. And now you’re surprised that people optimized for the thing you’re measuring?
This is textbook Goodhart’s Law: when a measure becomes a target, it ceases to be a good measure. Your promotion criteria were supposed to identify high performers. Instead, they created a system where the highest performers are the ones best at gaming the metrics.
You don’t have a talent problem. You have an incentive problem dressed up as a talent problem.
The damage is deeper than you think. PDD doesn’t just produce bad code — it produces a toxic culture. It teaches engineers that ambition matters more than craftsmanship. It teaches them that the smart move is to start a new project, get promoted, and let someone else deal with the maintenance nightmare you left behind.
It teaches them that the system doesn’t reward doing the right thing.
I’ve sat in promotion committees where genuinely impactful work was dismissed because it wasn’t “visible enough.” I’ve watched engineers who saved the company millions get passed over because their work didn’t fit neatly into a promo narrative. And I’ve seen the exact moment when a talented engineer decides to stop caring and start playing the game.
That moment? That’s when your company starts dying. Not visibly. Not immediately. But the rot has begun.
The most dangerous person in your organization isn’t the one who does nothing — it’s the one who does everything wrong for the right reasons, and gets rewarded for it.
So what do you do?
First, admit the problem. Your promotion system is not neutral. It’s actively shaping behavior in ways you didn’t intend. Every criterion you set, every metric you measure, every calibration meeting you run — they’re all signals telling engineers what to optimize for.
Second, redesign incentives to reward value creation, not visibility. If maintenance work is critical, promote people for doing it well. If an engineer quietly prevents disasters, find a way to recognize that. Stop conflating “new” with “valuable.”
Third, accept that this is a leadership problem, full stop. The engineers are responding rationally to the system you built. If you don’t like the behavior, change the system. Don’t blame the people who are playing the game you designed.
The system you build is the behavior you get. If you don’t like the behavior, stop blaming the players and start fixing the game.
Your engineers aren’t broken. Your promotion system is. And until you fix it, PDD will keep eating your company alive — one promo cycle at a time.
FAQ
Q: Isn't it still the engineer's responsibility to do the right thing instead of gaming for promotions?
A: Sure, in a world where people don't have mortgages, rent, and career anxiety. But you're asking humans to act against their economic self-interest because it would be 'nice.' That's not a strategy — that's a fantasy. People optimize for what you measure and reward. Fix the measurement, fix the behavior.
Q: How do you actually redesign promotion criteria to reward value over visibility?
A: Start by promoting people for maintenance work that prevented disasters. Track 'value delivered' not 'projects launched.' Include peer reviews from downstream teams who inherited the code. And stop requiring 'scope and impact' narratives that inherently favor new builds over critical upkeep. It's hard but not complicated.
Q: Isn't PDD sometimes good? Doesn't it at least drive some innovation?
A: It drives activity, not innovation. There's a massive difference. Innovation solves real problems. PDD solves promo packet problems. You get a graveyard of abandoned projects, technical debt, and engineers who've learned that shipping something useless is safer than maintaining something critical. That's not innovation — that's organizational cancer.