Skip to main content
Catalog
O020
Organizations

Promotion-Driven Architecture

HIGH(80%)
·
February 2026
·
4 sources
O020Organizations
80% confidence

What people believe

“Senior engineers make better architecture decisions because they have more experience.”

What actually happens
+200%System complexity
-40%Architecture decisions aligned with business needs
+100%Technical debt from abandoned promo projects
-50%Promotion rate for simplifiers
4 sources · 3 falsifiability criteria
Context

In many tech companies, promotion to senior or staff engineer requires demonstrating 'impact' through large-scale technical projects. The incentive is clear: build something big, get promoted. But this creates a systematic bias toward complexity. Engineers propose microservice decompositions, platform rewrites, and new infrastructure not because the business needs them, but because they're promotion-worthy projects. A simple solution that works doesn't get you promoted; a complex solution that requires a team does. The architecture of the system becomes a reflection of the promotion criteria, not the business requirements. Google engineers coined the term 'promo-driven development' to describe this pattern. The result is over-engineered systems that serve career advancement more than customer needs.

Hypothesis

What people believe

“Senior engineers make better architecture decisions because they have more experience.”

Actual Chain
→
Engineers propose complex solutions for simple problems(Architecture complexity exceeds business requirements)
└
Microservice decomposition proposed when monolith suffices
└
Platform rewrites initiated for career advancement, not technical need
└
New infrastructure built when existing tools would work
→
Simple, effective solutions undervalued(Maintainable code doesn't get you promoted)
└
Engineers avoid simple solutions because they're not 'impactful' enough
└
Maintenance and reliability work deprioritized vs new systems
→
Technical debt accumulates from abandoned promo projects(Engineers move on after promotion, leaving complex systems)
└
Promoted engineer moves to new team, leaving system to juniors
└
Complex system becomes unmaintainable without original author
└
Next engineer proposes rewrite for their own promotion
Impact
MetricBeforeAfterDelta
System complexityBusiness-drivenPromotion-driven+200%
Architecture decisions aligned with business needsHigh-40% (career incentives dominate)-40%
Technical debt from abandoned promo projectsBaselineSignificant accumulation+100%
Promotion rate for simplifiersExpected equal50% lower than builders-50%
Navigation

Don't If

  • •Your promotion criteria only reward building new systems, not maintaining or simplifying existing ones
  • •Engineers can't get promoted by making things simpler

If You Must

  • 1.Include 'simplification' and 'maintenance' as promotion-worthy impact categories
  • 2.Require architecture proposals to justify complexity against simpler alternatives
  • 3.Evaluate engineers on outcomes (reliability, user impact) not outputs (systems built)
  • 4.Mandate that architects maintain their systems for 12+ months post-launch

Alternatives

  • Outcome-based promotions — Promote based on business outcomes, not technical complexity
  • Simplification bonuses — Explicitly reward reducing complexity and removing systems
  • Architecture review boards — Independent review of whether proposed complexity is justified
Falsifiability

This analysis is wrong if:

  • Architecture decisions in promotion-driven cultures are equally aligned with business needs as in outcome-driven cultures
  • Engineers who build complex systems produce better long-term outcomes than those who simplify
  • Promotion criteria don't measurably influence the complexity of proposed technical solutions
Sources
  1. 1.
    Google: Promo-Driven Development (internal term)

    Google engineers coined this term to describe architecture decisions driven by promotion criteria

  2. 2.
    Will Larson: Staff Engineer

    Analysis of how promotion incentives shape technical decisions at senior levels

  3. 3.
    Charity Majors: The Engineer/Manager Pendulum

    Discussion of how career incentives create perverse technical decisions

  4. 4.
    Kellan Elliott-McCrea: Architecture and Incentives

    Former Etsy CTO on how organizational incentives shape system architecture

Related

This is a mirror — it shows what's already true.

Want to surface the hidden consequences of your organizational design?

Try Lagbase