An essay on the quiet incentive problem in engineering teams: the engineer who overbuilds gets a compelling promotion narrative, while the one who ships the simplest thing that works gets nothing. The thought experiment: Engineer A ships a simple 50-line implementation in two days — invisible in a promotion packet (“implemented feature X”). Engineer B builds a pub/sub system, a new abstraction layer, and a config framework over three weeks — and his work “practically writes itself into a promotion packet: designed a scalable event-driven architecture, introduced a reusable abstraction layer adopted by multiple teams.” Her work was better; his was narratable. Nobody gets promoted for the complexity they avoided. The incentive problem starts before hiring: in system-design interviews, proposing the simple answer gets “what about ten million users?” — so you add queues, sharding, more boxes, and learn that complexity impresses people. Design reviews do the same: “shouldn’t we future-proof this?” sends engineers adding layers for problems that might never materialize. The essay is careful to distinguish complexity from unearned complexity — “we’re hitting database limits and need to shard” vs “we might hit database limits in three years, so let’s shard now.” The path to seniority is knowing when NOT to use tools: “Anyone can add complexity. It takes experience and confidence to leave it out.” The fix for engineers: make the judgment visible — instead of “implemented feature X,” write “evaluated three approaches including an event-driven architecture and a custom abstraction layer, determined that a straightforward implementation met all current and projected requirements, and shipped in two days with zero incidents.” The fix for leaders: change the review question to “what’s the simplest version we could ship, and what specific signals would tell us we need something more complex?” — putting the burden of proof on complexity, not simplicity. “If we keep rewarding complexity and ignoring simplicity, we shouldn’t be surprised when that’s exactly what we get.”
Nobody Gets Promoted for Simplicity — Terrible Software
The incentive problem behind over-engineering: complexity looks smart because evaluation systems reward it — and the fix is to make the judgment behind simplicity visible.