Nobody gets promoted for simplicity
Promotion systems in large tech organizations often reward visible complexity—new architectures, abstraction layers, and elaborate systems—while the quiet benefits of simple, reliable solutions remain undervalued. Commenters describe how metrics, hiring practices, and design-review culture all bias toward overengineering, even when a spreadsheet, a single Postgres instance, or a small refactor would solve the problem better and cheaper. Many argue that simplicity still wins in genuinely results-driven teams, but it must be explicitly framed in business terms (cost, reliability, velocity) and backed by documentation or instrumentation to be recognized.
Incentives: Simplicity vs. Career Progression
- Many argue orgs reward visible complexity, “big architectures,” and heroic firefighting more than quiet, simple solutions that just work.
- Simplicity that prevents incidents is hard to credit because counterfactuals (“problems that never happened”) can’t be measured.
- Others counter that in healthy orgs, consistently shipping reliable features fast does get noticed and promoted, but such orgs are not the norm.
- Some note explicit “detect issues early” criteria in promo rubrics rarely translate into actual rewards.
Framing Simplicity in Business Terms
- Thread repeatedly emphasizes: don’t sell “simplicity,” sell outcomes: fewer incidents, faster MTTR, lower on-call load, reduced infra costs.
- Suggestions: build small cost models, instrument KPIs/SLOs, and tie refactors or deletions to dollars, downtime, and velocity.
- However, some report even large cost savings lost to more “impressive” but less effective projects.
Organizational Culture and Management Skill
- Good managers/EMs are expected to understand why simple designs are better and to make that visible in reviews and promo packets.
- Many describe “promotion-driven development” and managers who equate complexity with robustness or competence.
- Several say this is worse in big-tech or heavily layered orgs; smaller companies more often value pragmatism and speed.
Interviews, Design Exercises, and “Future-Proofing”
- System-design interviews often implicitly reward overengineering: candidates feel punished for simple “just use Postgres / Google Sheets” answers.
- Others say the real intent is to explore trade‑offs; interviewers should acknowledge the simple answer, then push candidates into hypothetical constraints.
- There’s tension between testing design depth vs. rewarding pragmatic, off‑the‑shelf solutions.
AI Tools and the Cost of Complexity
- Multiple comments: AI drastically lowers the creation cost of complex code and architectures, but not the maintenance or operations cost.
- Concern that AI agents default to “add more layers” and popular stacks, amplifying overengineering unless tightly guided.
- Some see AI as a force-multiplier for good engineers who already value simplicity; others say models still lack the context needed for truly maintainable designs.
Broader Reflections on Simplicity
- Simplicity is described as a hard, “master-level” skill: finding the minimal solution, not just the easiest or smallest diff.
- Several note we are psychologically biased toward additive solutions and “serious-looking” complexity.
- A recurring suggestion: celebrate code and systems deletions, reduced dependencies, and monoliths that are “boring but fast.”