🏆 Promotion-based development

I spent last week digging through old HR docs, trying to stitch together a halfway decent career ladder for our engineers. Somewhere in that rabbit hole I tripped over a phrase I hadn’t heard before: “promotion-based development.” My private translation: building software optimized for performance reviews instead of users.

The basic manoeuvre is simple. Figure out what gets rewarded, do that—repeatedly. If managers hand out stripes for kicking off “green-field initiatives,” you’ll suddenly see a forest of brand-new projects. If they celebrate heroic bug-squashing, systems will mysteriously start leaking memory every release so someone can swoop in and save the day. Corner office by Q4, thank you very much.

Picture yourself newly minted as a tech lead with a ten-person squad. You give them the usual autonomy speech—pick your tools, own your roadmap, just keep the product moving forward. A healthy mix of features, refactors, the occasional bug hunt. Within a month the Jira board is nothing but shiny features. Why? Visibility. A 5-point story that demos well beats a week of untangling legacy dependencies every time. (I’ve been guilty of this too—rewriting a perfectly good cron job because a React dashboard “looked more impactful” during the review.)

The ripple effect is bigger than most of us admit. I’ve watched infra teams rebuild log aggregators, chat apps, even CI pipelines that already existed in open source, purely because integrating Fluentd or Mattermost wouldn’t show up on the promo packet. The ops folks later complained they were maintaining two parallel worlds—one battle-tested tool and one half-baked internal clone. Nobody wins; everyone’s on pager duty.

Google is the textbook cautionary tale: multiple teams shipping overlapping chat products over the years—about 20 chat products. Each squad shipped, celebrated, collected their kudos, then the next crew declared, “We can do it better,” and pressed reset. The cost isn’t just waste; it’s fragmentation. Users bounce between Hangouts, Allo, Meet, Chat (I’ve lost track). Inside the company, docs, metrics, and on-call rotations splinter.

How to do promotions right then?

Honestly, I don’t have the grand unified answer (and if someone claims they do, I’d double-check their incentive deck). What I do know: a culture that spotlights the individual over the mission warps priorities. The slick presenter who demoed a flashy POC gets the applause, while the quiet engineer who removed 30% of our AWS bill fades into the background.

A performance-oriented setup is marginally better: you measure impact against company goals instead of internal showmanship. Still gameable, of course—counting outbound calls instead of closed deals, lines of Terraform instead of uptime. (I’ve seen Terraform drift turn into a full-time job six months after the “quick win” launch.)

Startups, at least in the early days, dodge some of this. Survival trumps politics; equity keeps incentives pointed in the same direction. If the product lands and revenue follows, everyone’s slice grows. That shared upside makes profit-sharing feel less like a perk and more like table stakes.

Same boat, same oars, same waterfall ahead.

The absence of a formal “promo season” helps too. You’re too busy shipping, learning, and praying the burn rate behaves to craft a PowerPoint about why your microservice deserves a higher pay band. Visibility-hunting feels almost silly when runway is measured in quarters.

But momentum fades. Once headcount pushes past a certain threshold (somewhere around “I don’t know every engineer’s coffee order” size), the gravitational pull toward promo-based development returns. The pie looks finite again, so people angle for the biggest slice. Community norms that once shamed overt self-promotion loosen, and the internal chatter turns to ranking docs and calibration meetings.

I’m not convinced we can eliminate the behavior entirely, but we can skew incentives toward long-term quality: reward the engineer who deleted obsolete code, who closed the most security review findings, who said “Let’s integrate the battle-tested OSS version instead of rolling our own.” Bespoke builds sometimes make sense—enterprise constraints, gnarly scalability edges, missing support contracts. Just insist on a real business case, not a line on a promotion form.

If you want more war stories, this Twitter thread is a solid rabbit hole.

---

Other Newsletter Issues:

• ✍️ Being an Amateur
• 🎯 What does a Product Owner do all day?
• 📈 The Toxic Grind