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 promotionsPromote based on business outcomes, not technical complexity
  • Simplification bonusesExplicitly reward reducing complexity and removing systems
  • Architecture review boardsIndependent 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