Nobody Gets Promoted for Simplicity - Terrible Software

Engineers who build complex systems get promotion packets that write themselves - "designed scalable event-driven architecture, introduced reusable abstraction layer" - while engineers who ship simple, working solutions in two days have nothing to say. The work was better, but it's invisible because of how simple it looks. You can't write a compelling narrative about the thing you didn't build, and nobody gets promoted for the complexity they avoided.

This incentive problem starts before you even get the job. In system design interviews, propose a simple solution - single database, straightforward API, maybe a cache - and interviewers push back: "What about ten million users?" So you add services, queues, sharding, more boxes on the whiteboard. What you learn is that complexity impresses people. The simple answer wasn't wrong, it just wasn't interesting enough. In design reviews, clean approaches get hit with "shouldn't we future-proof this?" so engineers add layers they don't need yet, abstractions for problems that might never materialize, flexibility nobody asked for.

The actual path to seniority isn't learning more tools and patterns - it's learning when not to use them. Anyone can add complexity. It takes experience and confidence to leave it out. The difference is between "we're hitting database limits and need to shard" versus "we might hit limits in three years, so let's shard now." One is earned complexity, the other isn't.

The fix requires changing how you talk about your work. "Implemented feature X" means nothing, but "evaluated three approaches including event-driven architecture, determined that straightforward implementation met all current and projected requirements, shipped in two days with zero incidents over six months" - that's the same simple work, described to capture the judgment behind it. In design reviews, when someone asks about future-proofing, respond with: "Here's what it would take to add that later if we need it, and here's what it costs us now. I think we wait."

For engineering leaders, this is on you more than anyone. Change the questions you ask in design reviews: instead of "have we thought about scale?", try "what's the simplest version we could ship, and what specific signals would tell us we need something more complex?" That makes simplicity the default and puts the burden of proof on complexity. In promotion discussions, push back when someone's packet is a list of impressive-sounding systems - ask if all of that was actually necessary. And pay attention to what you celebrate publicly: if every shout-out is for big complex projects, that's what people will optimize for.