I Built a Framework for the 'What, Why, When' Shift - Here's What Changed in My 1:1s

General
1

After reading Michelle’s thread about engineering leadership’s strategic shift, I realized I’ve been living this transition for the past 18 months without naming it. Let me share what changed when I stopped asking “how did you implement this” and started asking “what problem does this solve, why now, when do we validate.”

The Problem I Noticed

My team was asking permission for everything. Senior engineers with 10+ years of experience were coming to me for technical decisions they were fully qualified to make. At first I thought it was imposter syndrome or lack of confidence. Then I realized: I had trained them to wait for my approval by focusing all our conversations on implementation details.

Our 1:1s looked like code reviews. “Did you use microservices?” “What database did you choose?” “How are you handling authentication?” I was optimizing for my own technical validation, not their growth as decision-makers.

The Framework Shift

I rebuilt my 1:1 questions around three dimensions:

What: What business capability are we enabling? What user problem gets solved? What specific outcome changes?

Why: Why is this the priority right now? Why not the other 47 things on the backlog? Why does this matter to the business?

When: When do we validate we’re solving the right problem? When do we ship the minimum version? When do we know if it worked?

Notice what’s missing: “How are you building it?” Unless there’s a compliance, security, or irreversible architecture decision, I stopped asking about implementation.

Real Example from Fintech

An engineer came to me proposing a new data pipeline. Old me would have immediately jumped into: “What technology? How are you ensuring data consistency? What’s the schema design?”

New approach:

  • What: “You’re enabling real-time fraud detection. What specific fraud patterns can we catch that we’re missing today?”
  • Why: “Why is this more urgent than the customer onboarding improvements the product team wants?”
  • When: “When will we know if the new pipeline actually reduces fraud losses? What’s the validation metric?”

The conversation shifted from me validating technical choices to them articulating business impact. And here’s what happened: they came back with data showing fraud losses cost us $200K/month, onboarding improvements would increase revenue by $50K/month, and we could validate fraud reduction within 2 weeks of deployment.

They made the business case. I didn’t need to.

The Results (and Tensions)

Positive:

  • Team became dramatically more autonomous
  • Engineers started talking to product and customers directly instead of through me
  • We shipped higher-impact features because priority decisions were grounded in outcomes, not technical preferences
  • My calendar freed up - I went from 25 hours/week in meetings to 15 hours/week

But here’s the tension: Not all engineers want to think this way.

I had two senior ICs push back hard. “I didn’t become an engineer to worry about business metrics. I want to build excellent systems.” That’s a completely valid perspective. The challenge is that in leadership roles, we can’t only optimize for technical excellence anymore.

One of those engineers is now explicitly on an IC track with no intention of people management, and that’s perfect. They’re brilliant at technical design and we need that depth. The other one left for a bigger company where they could focus purely on technical architecture. Also fine - not everyone wants to operate in the “what, why, when” space.

The Question I’m Wrestling With

How do we develop this mindset in teams that have spent their entire careers being rewarded for technical depth?

In my financial services context, engineers are hired for their ability to understand complex systems, optimize for performance, and ensure regulatory compliance. Those skills are critical. But they don’t naturally translate to “what business outcome matters most right now.”

I’ve tried a few approaches:

  • Embedding engineers in product discovery sessions
  • Sharing P&L data so they understand revenue/cost drivers
  • Celebrating business impact in team meetings, not just technical achievements
  • Running “strategy sprints” where we practice articulating the “why” behind our roadmap

It’s working slowly. But I’m curious what others have tried, especially in technical teams where the culture has historically been “we build what we’re told to build.”

For leaders making this shift: how do you coach strategic thinking without losing the technical excellence that got your team here in the first place?

2

Luis, this framework is exactly what I’‘‘ve been trying to articulate to my leadership team. You’’‘ve named something that’‘‘s been implicit in how I’’'ve been running architecture reviews for the past year.

I want to add a fourth dimension that makes the business impact even more explicit: Who benefits?

The ‘Who’ Dimension

Every technical decision creates value for someone: customers, internal teams, partners, the business itself. Making that explicit changes how we evaluate tradeoffs.

Example from a recent architecture discussion:

Engineer proposed migrating to a new observability platform. Framed purely on ‘what/why/when’, the conversation was:

  • What: Better monitoring and alerting
  • Why: Current system is hard to use
  • When: 6-week migration, validate by measuring incident response time

All reasonable. But when I added ‘who benefits’, the conversation shifted:

Me: “Who specifically benefits from this change? The on-call engineers? The entire eng team? Product teams? Customers?”

Engineer: “Primarily on-call engineers. They’''re the ones struggling with the current tools.”

Me: “How many people is that?”

Engineer: “About 15 people in the rotation.”

Me: “And what’''s the cost of this migration in engineering time?”

Engineer: “Probably 4 engineer-months of work.”

Suddenly the math became clear: we’‘‘re spending 4 engineer-months to improve the experience for 15 people. That might still be worth it if it prevents critical incidents or burnout, but now we’’'re having a different conversation about ROI and priority.

Connection to Your Framework

The beautiful thing about your ‘what/why/when’ approach is it forces engineers to articulate impact, not just capability. Adding ‘who’ makes the stakeholder explicit, which helps with prioritization when you have 10 good ideas and resources for 2.

I’''ve also found that ‘who benefits’ helps engineers build empathy for non-technical stakeholders. When you realize the customer success team spends 10 hours/week working around a missing feature, suddenly that feature feels more urgent than the technical debt refactor that only engineers care about.

On Developing This Mindset

Your point about not all engineers wanting to think this way resonates deeply. I’''ve seen the same split in my teams.

What’''s worked for me: explicitly separating the IC technical leadership track from the strategic leadership track earlier in careers.

At the senior engineer level, I start asking people: ‘Do you want to influence technology decisions through technical depth and mastery, or do you want to influence business decisions through technology?’

Both are valid and valuable. But they require different skills and mindsets. The IC track leads to staff/principal engineer roles where technical excellence and architectural vision are the primary value. The strategic track leads to engineering management and eventually director/VP/CTO roles where business judgment becomes increasingly important.

The engineers who struggle most are the ones who want the compensation and title of leadership roles without shifting to strategic thinking. That’''s where the frustration and burnout happen.

I love your idea of ‘strategy sprints.’ Have you tried rotating engineers through temporary product owner roles? I’''ve experimented with having senior engineers own a feature end-to-end - including talking to customers, making priority decisions, and measuring business impact. The ones who enjoy that experience are revealing themselves as future leaders. The ones who find it draining are telling you they want to stay technical.

3

Luis, I need to ask the uncomfortable question about scaling this approach. Your framework makes perfect sense for your direct reports. But I have 80 engineers across multiple teams. I can’''t personally coach everyone through this mindset shift.

The Scaling Challenge

Here’‘‘s my reality: I have maybe 8 direct reports (directors and senior managers). They each have 5-10 reports. If this strategic thinking mindset needs to happen through 1:1 coaching conversations, it’’'ll take years to permeate the organization.

Meanwhile, our CFO wants to see business-driven technical decisions now. Product wants engineers who understand customer impact now. The board wants strategic technology leadership now.

The Question I’''m Wrestling With

Do we hire for this mindset, or do we develop it?

If we hire for it: what does that even look like in interviews? ‘Tell me about a time you made a technical decision based on business impact’ gets rehearsed answers. And frankly, most strong engineers have spent their careers being evaluated on technical skill, not business acumen.

If we develop it: what’‘‘s the systematic approach that doesn’’'t require me to personally mentor 80 people?

What I’''ve Tried (With Mixed Results)

  1. Cascading the framework through managers: Taught my directors your ‘what/why/when’ approach and asked them to coach their teams. Result: about half of them got it and are running with it. The other half are still asking ‘how are you building it’ in their 1:1s. They say they understand the framework but their default mode is technical review.

  2. Making business context explicit in planning: We now share revenue data, customer churn metrics, and support ticket volumes in sprint planning. The goal is to make the ‘why’ visible. Result: some engineers really engage with the data, others zone out because it feels like ‘not my job.’

  3. Changing performance review criteria: Added ‘business impact’ as an evaluation dimension alongside ‘technical excellence.’ Result: engineers game it by claiming everything they do has business impact. Without coaching on what that actually means, it’''s just a checkbox.

The Real Question

Is strategic thinking fundamentally a personality trait that some people have and others don’''t? Or is it truly developable at scale?

Because if it’‘‘s the former, we need to completely rethink our hiring pipeline. We’’'re hiring for technical brilliance and hoping people will magically develop business judgment.

If it’''s the latter, I need concrete tactics for developing it systematically across 80 people without burning out my management team or turning every 1:1 into a business strategy session.

Michelle, your idea about separating tracks earlier is smart. But even that requires infrastructure: clear career ladders, different interview pipelines, explicit coaching programs. That’''s a multi-year organizational redesign.

What can we do this quarter to shift the culture when we’''re already underwater with hiring, delivery pressure, and now AI transformation on top of everything else?

4

Coming from the product side, I want to raise a concern about engineers using ‘business value’ as a way to avoid hard technical work.

The Pattern I’''m Seeing

Your framework is great, Luis. But I’''m noticing some engineers weaponize ‘why’ questions to push back on anything technically challenging.

Examples:

Engineer: ‘Why do we need real-time analytics? Batch processing overnight is good enough for business impact.’
Reality: They don’‘‘t want to build the streaming infrastructure because it’’'s hard.

Engineer: ‘Why are we optimizing page load time from 2 seconds to 0.5 seconds? The data shows conversion rate only drops below 3 seconds.’
Reality: They don’''t want to do the performance work because it requires profiling, optimization, and deep technical skill.

Engineer: ‘Why do we need to refactor this code? It’‘‘s working fine and customers don’’‘t care about internal code quality.’
Reality: The code is a mess and they’''re avoiding the discipline of clean architecture.

The Balance I’''m Looking For

I love that engineers are thinking about business impact. That’'‘s a massive improvement over ‘we need to rebuild this because it’’‘s not architected the way I think it should be.’

But strategic thinking can’''t become an excuse to avoid technical excellence.

The best engineering leaders I work with - and Luis, you’‘‘re in this category - balance both. They ask ‘what’’‘s the business value’ and they maintain technical standards. They prioritize ruthlessly and they don’''t cut corners that create future problems.

The Question for Engineering Leaders

How do you teach engineers to use strategic thinking as a prioritization tool without letting it become a rationalization for taking shortcuts?

Because right now I’‘‘m seeing some engineers use ‘customer impact’ to mean ‘I don’’‘t want to do the hard technical work that doesn’’‘t have immediate visible results.’

And ironically, six months later we’'‘re paying the price when the system falls over because we skipped the foundational work that ‘wasn’’‘t a customer priority.’

What I Think the Framework Needs

Maybe we need a fifth question: ‘What’'‘s the technical foundation required for this outcome to scale?’

That forces the conversation about architectural decisions, code quality, performance, security - all the things that don’''t ship features but enable sustained delivery of features.

Strategic thinking isn’‘‘t just ‘what makes customers happy today.’ It’’'s ‘what enables us to keep making customers happy for the next 3 years.’

Thoughts?

5

This whole thread is giving me flashbacks to a parallel shift in design leadership. Let me share what we learned, because the patterns are eerily similar.

The Design Critique Evolution

Old design critiques: ‘What font did you use? Why that shade of blue? How did you create that interaction?’

New design critiques: ‘What user need does this serve? Why this approach over alternatives? When do we test if it’'‘s working?’

Sound familiar?

What We Learned About Reframing

We created a literal template for reframing technical decisions into user-centered language. It looks like this:

Instead of: ‘I chose Figma because…’
Reframe to: ‘This design enables [user segment] to [achieve goal] because…’

Instead of: ‘I used this component library because…’
Reframe to: ‘This approach reduces time-to-market for [feature] which matters because…’

Instead of: ‘I designed this interaction pattern because…’
Reframe to: ‘Users currently struggle with [pain point], this solves it by…’

The Engineering Translation

Luis, I think your framework could benefit from similar concrete reframing examples.

Instead of: ‘I chose PostgreSQL because…’
Reframe to: ‘This database choice enables [business capability] with [performance characteristic] that matters because…’

Instead of: ‘I’'‘m refactoring this code because…’
Reframe to: ‘This refactor enables the team to ship [future capability] 40% faster because…’

Instead of: ‘I built this microservice because…’
Reframe to: ‘This service architecture allows us to scale [specific user workflow] independently, which matters because…’

The Gap You’''re All Dancing Around

Here’‘‘s what I’’'m hearing in this thread:

  • Luis: Some engineers don’‘‘t want to think strategically and that’’'s ok
  • Michelle: We need to separate IC technical track from strategic leadership track
  • Keisha: We can’''t coach everyone individually, need systematic approaches
  • David: Strategic thinking can’''t excuse poor technical work

But here’‘‘s the question nobody’’'s asking: Is this strategic shift creating a gap for IC technical leadership?

If engineering managers are moving toward ‘what/why/when’ and away from ‘how,’ who’‘‘s maintaining the deep technical expertise? Who’’'s the person junior engineers go to when they need to learn how to build things the right way?

In design, we solved this by creating a ‘principal designer’ track that’‘‘s explicitly about craft mastery and mentorship, not strategy. They don’’'t run design critiques focused on business impact - they run craft sessions focused on excellence.

Does engineering need the same split? Strategic leaders focused on ‘what/why/when’ and technical leaders focused on ‘how/quality/mastery’?

Because if everyone’‘‘s optimizing for business impact, who’’'s optimizing for technical excellence?