Engineers Are Valued for Business Strategy, Not Just Technical Expertise—How Do We Actually Teach 'What, Why, When' Thinking?

General
1

I’ve been thinking a lot about this shift I’m seeing in engineering leadership. When I was at Google and Airbnb, the engineers who got promoted to senior levels weren’t just the ones who could write the most elegant code—they were the ones who understood business impact.

The Strategic Thinking Gap

Here’s what I mean by “what, why, when” thinking:

  • What constraints actually matter for this problem? (Performance? Security? Time to market? Cost?)
  • Why should we prioritize this work over everything else competing for resources?
  • When is “good enough” actually good enough, versus when do we need perfection?

The best engineers I worked with could answer these questions fluently. They didn’t just propose technical solutions—they articulated trade-offs in business terms that product, design, and leadership could evaluate.

The Challenge

But here’s the uncomfortable truth: We hire for technical skills, but we promote based on strategic thinking.

Most engineering education focuses on algorithms, data structures, system design. Almost none of it teaches you how to evaluate which technical constraints align with business priorities, or how to communicate technical decisions to non-technical stakeholders.

I’ve seen brilliant engineers plateau because they couldn’t make this leap. And I’ve struggled to help them develop these skills because… honestly, I’m not sure how I learned them myself. Was it osmosis from working with great PMs? Mentorship? Trial and error?

The Question

How do we actually teach strategic thinking to engineers?

Not in theory—what has actually worked for you? Frameworks? Specific practices? Mentorship structures? Cross-functional exposure?

At my current startup, I’m working with our CTO to develop our senior engineers, and we’re honestly making it up as we go. I’d love to hear what’s worked (or failed spectacularly) for others.

Because if we can’t systematically develop this skill, we’re limiting both individual careers and organizational effectiveness. And that seems like a solvable problem.

2

This resonates deeply with my experience scaling engineering teams at a Fortune 500 financial services company. I’ve seen exactly this pattern—brilliant technical contributors who struggle to advance because they can’t connect their work to business outcomes.

What Actually Works: Structured Business Exposure

Here’s what we’ve implemented that’s shown real results:

1. Quarterly Business Reviews

We require senior engineers to present their technical work in quarterly business reviews alongside product and sales teams. No technical jargon allowed—they have to explain their architecture decisions in terms of customer impact, revenue implications, or risk reduction.

The first time, most engineers are terrified. By the third quarter, they’re fluent.

2. OKR Alignment Exercises

Every technical proposal must explicitly map to company OKRs. Not just “this improves performance”—but “this reduces customer churn by 15% because page load time correlates with trial conversion.”

This forces engineers to understand how their technical decisions cascade to business metrics.

3. Customer Immersion

We rotate senior engineers through customer support for one week per quarter. Nothing teaches business context faster than hearing real customers struggle with your product.

Success Story

One of my senior engineers was technically exceptional but kept getting passed over for staff engineer. His proposals were always technically sound but lacked business justification.

We put him through this program. Six months later, he proposed a database optimization that he articulated as “reducing cloud costs by $2M annually while improving customer-facing latency by 40%, which customer research shows is our #2 driver of enterprise renewals.”

He got promoted to staff engineer the next review cycle.

The Key Insight

Strategic thinking isn’t magic—it’s a learnable skill that requires structured practice and feedback. But you have to create the forcing functions, or engineers will default to what they’re comfortable with: pure technical execution.

What frameworks or practices have others found effective?

3

As someone who failed a startup, I can tell you exactly where this breaks down: technical excellence does not equal business success. And I learned that the hard way.

My Expensive Education

My co-founder and I built an incredible design system tool. Beautiful API. Elegant architecture. Every engineer who saw it loved it.

Zero customers bought it.

Why? Because we optimized for technical elegance instead of solving the actual business problem our customers had. We built what we thought they needed, not what they were actually willing to pay for.

Cross-Functional Collaboration Is the Learning Ground

After that failure, I joined a design systems team and finally learned strategic thinking—not from classes, but from working alongside product managers, sales, and customer success.

Here’s what I’d suggest:

Engineers Should Sit In:

  • Customer discovery calls - Hear the actual problems, not the filtered requirements
  • Sales demos - See what features actually close deals vs what we think matters
  • Product reviews - Understand why some features get prioritized over others
  • Post-mortems - Learn how technical decisions impact customer trust and revenue

The first time I sat in a customer call and heard someone say “I don’t care how you built it, I just need it to work with our existing tools,” something clicked. All my elegant technical solutions meant nothing if they didn’t solve the customer’s actual workflow problem.

The Design Parallel

We have the same challenge in design. A designer who only thinks about aesthetics won’t advance. You need to understand information architecture, accessibility, conversion optimization, and ultimately—how design impacts business metrics.

Technical excellence is necessary but not sufficient. You need business context to make your technical expertise valuable.

And honestly? You can’t learn that from a book. You need real exposure to customers, business constraints, and cross-functional trade-offs.

(Expensive lesson, but I’m glad I learned it early enough to change course.)

4

Great discussion. I’ve built strategic thinking programs at both Microsoft and Twilio, and now at my current company, and I want to push back on something maya_builds said: exposure alone isn’t enough.

Structured Reflection + Feedback = Learning

You can put an engineer in 100 customer calls, but if they don’t have a framework for synthesizing those insights into technical decisions, they’ll just collect anecdotes.

Here’s what we do that actually creates systematic development:

1. Rotation Programs with Structure

We rotate engineers through product management, customer success, and sales for 6-week stints. But the critical part is the structured reflection:

  • Weekly journal: What surprised you? What changed your assumptions?
  • Bi-weekly coaching: Discuss insights with a mentor
  • Final presentation: Propose a technical investment based on what you learned

Without this structure, rotation is just tourism.

2. Quarterly Strategic Planning Participation

Senior engineers participate in quarterly planning—not just as implementers, but as strategic contributors. They see the business metrics, market positioning, competitive analysis.

But we prepare them first:

  • Pre-work: Business context, financial overview, customer research
  • Framework: Template for evaluating technical proposals against business strategy
  • Feedback: Debrief after planning to discuss what they learned

3. Architecture Decision Records That Require Business Context

Every architectural decision must include:

  • Business context (not just technical rationale)
  • Customer impact
  • Revenue/cost implications
  • Trade-offs considered

This forces engineers to think strategically even in day-to-day technical work.

The Bottom Line

Exposure is valuable, but learning requires structured reflection and feedback. You can accelerate this process, but only if you’re intentional about it.

Otherwise, you’re just hoping engineers learn through osmosis—and that works for some people but excludes many others who could develop these skills with proper support.

What structured approaches have others tried? I’m always looking for better frameworks.

5

This is such an important conversation, and I want to add a dimension that’s been critical in my experience at Google, Slack, and now at an EdTech startup: not all engineers want to be strategic, and that’s okay.

Multiple Paths to Senior Leadership

One thing that frustrated me early in my career was the assumption that to advance, you had to become strategic, business-focused, cross-functional.

But some of the most valuable engineers I’ve worked with are deep technical specialists who have zero interest in business strategy. And forcing them into that mold is counterproductive.

Here’s the framework we use:

Strategic Leadership Track

  • Staff Engineer → Senior Staff → Principal
  • Focus: Cross-functional influence, business alignment, architectural vision
  • Development: Business immersion, strategic planning, executive communication
  • Value: Technical decisions aligned with business strategy

Technical Depth Track

  • Staff Engineer → Senior Staff → Principal (same titles!)
  • Focus: Deep technical expertise, innovation, technical excellence
  • Development: Advanced technical skills, mentorship, thought leadership
  • Value: Solving complex technical problems, raising the technical bar

The Key: Equal Value, Different Paths

Both paths have equal compensation and organizational influence. A Principal Engineer on the depth track has the same level and pay as one on the strategic track.

The difference is how they create value, not whether they create value.

Development Differs by Path

For strategic track:

  • Business context exposure (what everyone’s been discussing)
  • Cross-functional collaboration
  • Customer immersion
  • Strategic planning participation

For technical depth track:

  • Advanced technical training
  • Research and innovation time
  • Technical community leadership
  • Mentoring on technical excellence

Why This Matters for Inclusion

When I mentor Black women and other underrepresented engineers, I notice that they often feel pressure to prove themselves by being “well-rounded” and strategic.

But forcing everyone into the same mold reduces diversity of thought and contribution.

Some engineers drive business value through strategic thinking. Others drive it through technical innovation. Both are essential.

So yes, teach strategic thinking to engineers who want to develop that skill. But also create paths for those who don’t—because we need both.