Engineering Career Ladders Reward Technical Depth. Business Impact Isn't Even on the Rubric

General
1

Following up on all these conversations about strategic thinking in engineering leadership—I want to call out a fundamental problem: Our engineering career ladders reward technical depth, but business impact isn’t even on the rubric.

The Typical Staff+ Promotion Criteria

Look at most engineering ladders for Staff Engineer and above:

What we evaluate:

  • Technical expertise and breadth
  • System design and architecture quality
  • Code quality and best practices
  • Technical mentorship and influence
  • Project delivery and execution

What we don’t evaluate:

  • Business context and commercial awareness
  • Strategic alignment with company goals
  • Cross-functional collaboration and influence
  • Ability to communicate technical decisions in business terms
  • ROI and business impact of technical work

The Consequence

We promote based on what we measure. So we end up with:

  • Staff engineers who are brilliant technically but can’t articulate why their work matters to the business
  • Architects who design beautiful systems that solve the wrong problems
  • Senior leaders who optimize for technical elegance over business outcomes

Then we’re surprised when these people struggle in leadership roles that require strategic thinking.

A Real Example

One of our Staff engineers was up for promotion to Principal. His technical work was exceptional:

  • Redesigned our data pipeline architecture
  • Reduced processing time from 6 hours to 45 minutes
  • Mentored 5 engineers on distributed systems patterns

His promo packet focused entirely on technical achievement. The business impact section said: “Improved pipeline performance.”

I asked him: “What was the business value of that improvement?”

He didn’t know. He’d never asked.

Turned out:

  • Faster pipelines enabled same-day analytics for customer success team
  • CS could now proactively reach out to at-risk customers before churn
  • We estimated it saved $400K in prevented churn annually

That’s a $400K business impact, and he had no idea. His promotion packet completely missed the strategic value of his work.

Should Business Impact Be in the Rubric?

I’m starting to believe that for Staff+ levels, business impact should be an explicit promotion criterion, not just a nice-to-have.

What if the Staff Engineer rubric included:

  • Business Context: Can demonstrate understanding of how technical work connects to company strategy and metrics
  • Strategic Communication: Can explain technical decisions in terms of business value (revenue, cost, risk, customer impact)
  • Cross-Functional Influence: Proactively builds relationships with product, business stakeholders to align technical work with company priorities

The Pushback I Expect

“You’re asking engineers to do product management work!”

  • No, I’m asking them to understand why their work matters beyond technical metrics

“Business impact is vague and subjective.”

  • So is “technical influence” and “leadership,” but we evaluate those

“We should promote based on technical excellence, not business skills.”

  • Then don’t be surprised when technically excellent people fail in strategic roles

The Question

Should business impact and strategic thinking be explicit criteria in engineering promotion ladders, especially at Staff+ levels?

And if yes, how do you evaluate it without it becoming entirely subjective or turning into a “who’s best at self-promotion” contest?

I’m genuinely curious how other orgs think about this. Are you measuring strategic impact in promotions? How? Or do you think it’s the wrong focus?

2

Absolutely yes. We recently rewrote our Staff+ criteria to explicitly include business context and strategic impact. Here’s what that looks like in practice.

Our Updated Staff Engineer Criteria

Technical Excellence (still required)

  • Deep expertise in one or more technical domains
  • Can architect complex systems with appropriate tradeoffs
  • Mentors engineers on technical topics
  • Drives technical standards and best practices

Strategic Business Impact (new requirement)

  • Business Context: Demonstrates understanding of how technical work connects to company strategy

    • Example evidence: Proactively asks product/business questions before starting technical work
    • Can explain the “why” behind priorities in business terms

  • Impact Articulation: Can quantify and communicate business value of technical work

    • Example evidence: Promotion packet includes customer impact, revenue influence, or cost savings
    • Presents technical work to cross-functional audiences in business language

  • Strategic Alignment: Proactively identifies technical work that unlocks business value

    • Example evidence: Proposed technical investments with ROI models or business cases
    • Partners with product/business to understand strategic direction

How We Evaluate This

Concrete examples from recent promotions:

Staff Engineer - Data Platform:

  • Technical achievement: Redesigned ETL pipeline, reduced costs by 40%
  • Business impact: Enabled real-time analytics for sales team, contributed to 15% increase in deal close rate because AEs had current data during calls
  • Strategic alignment: Proactively identified that sales was hampered by stale data, partnered with sales ops to understand requirements

Principal Engineer - Infrastructure:

  • Technical achievement: Migrated to Kubernetes, improved deployment reliability from 92% to 99.5%
  • Business impact: Reduced customer-facing incidents by 60%, saved $120K/year in on-call costs, enabled faster feature deployment (2 days → 4 hours) which accelerated product iteration
  • Strategic alignment: Built business case for migration, got exec approval, collaborated with product to sequence migration to minimize disruption

What Changed After We Added This

Good changes:

  1. Promotion packets now include business metrics, not just technical achievements
  2. Engineers proactively ask “why does this matter?” and “what’s the business impact?”
  3. Cross-functional teams report better collaboration—engineers understand context

Controversial changes:

  1. Some strong technical contributors aren’t getting promoted because they can’t articulate business value
  2. We’ve had difficult conversations: “Your technical work is excellent, but you haven’t demonstrated strategic thinking”
  3. Some engineers feel this is “unfair”—they argue technical excellence should be enough

The Fairness Question

Is it fair to require business impact for senior IC roles?

My position: Yes, because impact IS the job at Staff+ level.

Junior/Mid-level engineers: Job is to execute well on defined problems
Senior engineers: Job is to solve ambiguous problems with good technical solutions
Staff+ engineers: Job is to identify high-leverage problems and solve them in ways that create business value

If you can’t identify what matters strategically or communicate impact, you’re missing a core competency of the Staff+ role.

How to Avoid Subjectivity

David’s concern about this becoming a “self-promotion contest” is valid. We address it by:

  1. Requiring evidence, not narratives: Don’t just say “I had business impact”—show metrics, stakeholder testimonials, business outcomes
  2. Cross-functional input: Product and business partners provide feedback on strategic collaboration
  3. Calibration across the org: We review all Staff+ promo packets together to ensure consistent standards

It’s still somewhat subjective, but so is “technical influence” and “leadership.” We’re getting better at it with practice.

The Alternative

If we don’t explicitly evaluate strategic impact, we get:

  • Engineers optimizing for technical complexity over business value
  • Brilliant technical work that solves the wrong problems
  • Misalignment between engineering effort and company priorities

I’d rather have the uncomfortable conversation about business impact than promote people into senior roles without that context.

3

We did something similar—added business impact to our Staff+ criteria—and I want to share both what worked and what we got wrong.

Our Impact Ladder Framework

We structured promotion criteria around impact scope:

Junior Engineer: Task-level impact

  • Complete well-defined work items
  • Measured by: Code quality, delivery reliability

Mid-Level Engineer: Feature-level impact

  • Own feature development end-to-end
  • Measured by: Technical execution, cross-team collaboration

Senior Engineer: Project-level impact

  • Lead complex projects with multiple stakeholders
  • Measured by: Technical design, project delivery, team influence

Staff Engineer: Business outcome impact

  • Identify and deliver initiatives that move company-level metrics
  • Measured by: Revenue impact, user impact, cost savings, or strategic enablement

Principal Engineer: Strategic technical impact

  • Set technical direction that enables multi-year business strategy
  • Measured by: Architecture decisions that unlock business capabilities, technical leadership across org

The Key Change: Impact > Output

Before this framework, promotion packets focused on what you built:

  • “Implemented new authentication service”
  • “Migrated database to PostgreSQL”
  • “Reduced API latency by 40%”

Now they must focus on what business outcome you enabled:

  • “New auth service enabled enterprise SSO, which unblocked $2M in enterprise deals”
  • “Database migration reduced infrastructure costs by $15K/month and improved query performance, enabling real-time dashboards that improved customer retention”
  • “API latency reduction decreased mobile app crashes by 25%, improving App Store rating from 3.8 to 4.4 stars, which increased organic installs by 18%”

The Controversial Part

Some technically strong engineers couldn’t get promoted because they couldn’t demonstrate business impact.

One case that was painful:

Senior Engineer → Staff promotion (denied):

  • Incredible technical work: Rewrote core service, improved performance, reduced tech debt
  • Business impact: “Made the codebase better for future development”
  • Problem: No measurable business outcome. When asked “What customer problem did this solve?” he didn’t have an answer.

He was frustrated: “I did exactly what the tech lead asked me to do. How is it my fault that it doesn’t have business impact?”

Fair point.

This revealed a gap: We were asking engineers to own business outcomes without giving them agency to choose what to work on.

What We Changed

We realized: If we’re evaluating business impact, we have to give engineers autonomy to work on high-impact problems.

Now for Staff+ promotion:

  1. Strategic project ownership: Engineers at Senior level can propose strategic initiatives (with business cases) and get resources to execute
  2. Cross-functional partnership: Eng leaders help Senior engineers understand business priorities and identify high-leverage technical work
  3. Impact transparency: We share company OKRs, metrics, and strategic priorities openly so engineers can align their work

Result: Engineers are now empowered to ask “Is this the highest impact work I could be doing?” instead of just executing assigned tasks.

Measuring Without Subjectivity

To David’s question about avoiding self-promotion contests, we require:

Quantitative evidence (at least one):

  • Revenue impact (enabled deals, improved conversion, reduced churn)
  • Cost savings (infrastructure, operational efficiency)
  • User impact (adoption, engagement, satisfaction metrics)
  • Efficiency gains (developer productivity, reduced manual work)

Qualitative evidence (at least two):

  • Cross-functional stakeholder testimonials (product, sales, customer success)
  • Strategic alignment: How does this connect to company OKRs?
  • Scope of impact: How many teams/customers/users benefited?

We calibrate across the org to ensure consistency. Not perfect, but better than “tell me about your technical accomplishments.”

The Tension Michelle Identified

Some engineers still struggle with this. Common pushback:

“I’m an engineer, not a PM. Why do I need to think about business metrics?”

My response: At Staff+ level, you’re not just an engineer—you’re a technical leader who should be driving business outcomes through technology.

If you want to stay purely technical without business context, that’s valid—but the IC track caps out at Senior in our org. Staff+ requires strategic impact.

The Result

After 18 months of this framework:

  • Engineers proactively seek business context before starting work
  • Cross-functional teams report better alignment
  • Technical investments are more clearly tied to strategic priorities
  • Staff+ engineers feel more valued—they’re not just “doing what they’re told,” they’re driving strategy

But: Some strong technical contributors left because they didn’t want to think about business impact. That’s a tradeoff we accepted.

Strategic leadership requires business thinking. If our ladder doesn’t reflect that, we’re promoting the wrong people.

4

I’m going to offer a balanced perspective here, because I think there’s a risk of overcorrection.

Yes, business impact should matter. But we can’t lose technical excellence in the process.

The Dual Track Solution

My org explicitly separates two paths at Staff+ level:

Technical Depth Track (Staff/Principal/Distinguished Engineer)

Primary evaluation: Technical excellence and innovation

  • Deep expertise in core technical domains
  • Architecture and system design quality
  • Technical mentorship and knowledge sharing
  • Setting technical standards across the org

Secondary evaluation: Strategic technical thinking

  • Can they identify technical work that has strategic leverage?
  • Do they understand technical tradeoffs in business context?
  • Can they communicate technical decisions effectively?

Strategic Leadership Track (Engineering Manager → Director → VP)

Primary evaluation: Business alignment and strategic impact

  • Cross-functional collaboration and influence
  • Strategic decision-making and prioritization
  • Business outcome delivery
  • Organizational design and team building

Secondary evaluation: Technical judgment

  • Can they evaluate technical tradeoffs?
  • Do they maintain enough technical depth to make good decisions?
  • Can they ask the right technical questions?

Why Both Tracks Need to Exist

Not every Staff+ engineer should be evaluated primarily on business impact. Some of our best engineers:

Platform Infrastructure Principal:

  • Deep expertise in distributed systems and reliability
  • Designs infrastructure that enables the entire engineering org
  • Technical impact is massive, even if business impact is indirect
  • Doesn’t work directly with product/business, focuses on internal technical enablement

Security Staff Engineer:

  • Expert in security, compliance, and risk mitigation
  • Impact is preventing disasters, not creating new revenue
  • Hard to quantify business value of “things that didn’t go wrong”
  • Absolutely critical for the company, but doesn’t fit “business outcome” framing

The Balance I’m Advocating

For Staff+ IC Technical Track:

  • Technical excellence is primary criterion (70%)
  • Strategic thinking is secondary but required (30%)
  • “Can you articulate why your technical work matters?” is sufficient—you don’t need to drive business OKRs directly

For Staff+ Leadership Track or Cross-Functional ICs:

  • Business impact is primary criterion (60%)
  • Technical judgment is secondary but required (40%)
  • “Can you identify high-leverage work and deliver measurable outcomes?” is critical

Concrete Rubric Language

Here’s language from our ladder that balances both:

Staff Engineer - Technical Track:
“Demonstrates deep technical expertise and drives technical strategy within their domain. Can articulate how technical decisions enable business outcomes and collaborates effectively with cross-functional partners. Primary impact is through technical innovation, architecture, and raising the technical bar across the organization.”

Staff Engineer - Strategic Track:
“Identifies high-leverage technical initiatives aligned with business priorities. Drives measurable impact on company-level metrics through technical leadership. Partners proactively with product, business stakeholders to ensure technical work delivers strategic value.”

The Risk of Overcorrection

If we make business impact the primary criterion for all Staff+ engineers, we risk:

  1. Undervaluing foundational technical work: Infrastructure, security, dev tools—critical but hard to tie to revenue
  2. Rewarding self-promotion over substance: Engineers who are good at articulating impact get promoted over those who quietly deliver excellence
  3. Losing technical depth: Everyone optimizes for visible business wins instead of hard technical problems that enable long-term success

My Answer to David’s Question

Yes, business impact should be in the rubric. But:

  • For cross-functional/strategic IC roles: Primary criterion
  • For deep technical specialist roles: Secondary criterion

Both matter. The ratio depends on the role’s nature.

We need Staff engineers who can solve hard technical problems AND Staff engineers who can drive business outcomes. Different people, different strengths, equally valuable.

The mistake is assuming one ladder fits all.

5

This whole conversation is making me realize something: If strategic impact matters, why do only engineers evaluate promotions?

Cross-Functional Promotion Reviews

Hear me out on this radical idea:

If we’re saying Staff+ engineers need to:

  • Demonstrate business impact
  • Collaborate cross-functionally
  • Communicate in business terms
  • Align technical work with strategic priorities

Then shouldn’t non-engineers participate in promotion decisions?

What This Could Look Like

Technical evaluation (led by engineers):

  • System design and architecture quality
  • Technical depth and expertise
  • Code quality and engineering practices
  • Technical mentorship

Strategic impact evaluation (cross-functional panel):

  • Product partner: How effectively does this person collaborate with product? Do they understand user needs and product strategy?
  • Business stakeholder: Can they communicate technical work in business terms? Do they proactively align with business priorities?
  • Design partner: How well do they collaborate across disciplines? Do they understand holistic product thinking beyond just engineering?
  • Engineering leader: Facilitates, ties it together

Why This Would Help

Avoids the self-promotion problem:

  • Instead of engineers claiming “I had business impact,” product/business stakeholders directly validate it
  • Less about how well you write your promo packet, more about how you’re actually perceived by cross-functional partners

Gets to real collaboration ability:

  • Engineers can evaluate technical skills
  • Non-engineers evaluate strategic partnership, communication, business alignment

Surfaces blind spots:

  • Sometimes engineers think someone is collaborative but product sees them as difficult
  • Sometimes someone is technically brilliant but can’t translate that into value for partners

The Example That Convinced Me

When we promoted our design systems engineering lead last year, we included feedback from:

  • Engineers: Evaluated technical architecture, API design, performance
  • Designers: Evaluated collaboration, understanding of design principles, communication style
  • Product: Evaluated adoption strategy, internal DX, alignment with product priorities

The feedback diverged significantly:

Engineers said: “Incredible technical depth, great architecture decisions, strong IC”

Designers said: “Struggles to understand design thinking, sometimes dismissive of design feedback, treats designers like clients instead of partners”

Product said: “Doesn’t proactively communicate roadmap or tradeoffs, hard to get visibility into what’s being prioritized”

We almost promoted this person based purely on technical excellence. Cross-functional feedback revealed collaboration and strategic communication gaps that would have caused problems at the next level.

We created a development plan instead of promoting immediately. That feedback was invaluable.

The Pushback I Expect

“Non-technical people shouldn’t judge engineering work!”

  • They’re not judging technical quality—they’re evaluating collaboration, communication, and business alignment
  • If strategic impact is in the rubric, stakeholders should validate that impact

“This will slow down promotions”

  • Maybe. But promoting the wrong people is more expensive than taking extra time to evaluate

“This gives product/business veto power over engineering careers”

  • It’s input, not veto. Engineering leaders still make final decisions. But ignoring stakeholder feedback seems shortsighted if we claim to value cross-functional collaboration

When This Makes Sense

I don’t think this is necessary for all IC levels. But for Staff+ where strategic impact is explicitly in the rubric? It seems consistent.

If the promotion criteria include:

  • Business impact
  • Cross-functional collaboration
  • Strategic communication

Then the people who experience that collaboration should have input on whether the candidate demonstrates those skills.

Luis’s Dual Track Point

Luis made a great point about technical depth vs. strategic leadership tracks. Maybe this only applies to the strategic leadership track or cross-functional Staff+ roles.

For pure technical depth roles (infrastructure, security, research), engineering-only evaluation makes sense.

For cross-functional strategic roles? I think non-engineer input is valuable and maybe even necessary.

What do y’all think? Too radical? Or a natural extension of saying “business impact matters”?