WHY-WHAT-HOW: A Field Model for Who Actually Decides Things in Engineering Projects

Picture a sprint planning session. The product manager is explaining—in some detail—which microservice the team should modify and which endpoint to add. Two senior engineers are pushing back, but not on the implementation: they’re relitigating whether the feature makes any business sense at all, three sprints into building it. The engineering manager is present, nodding, and owning absolutely nothing. Everyone in the room is doing someone else’s job, and nobody is doing their own.

I’ve sat in some version of this meeting dozens of times over twenty years in this industry—as a developer, as a team lead, as a consultant parachuted in to figure out why delivery ground to a halt. So fair warning: this piece breaks from the usual format of this site. It’s not a single client case study with a tidy before-and-after. It’s a compilation—a model I found myself applying instinctively across roles and organizations, long before I bothered to give it a name.

The working name is WHY-WHAT-HOW.

Three disclaimers before you close the tab.

First: no, this is not Simon Sinek’s Golden Circle. Sinek’s 2009 model (WHY-HOW-WHAT) is about motivation, purpose, and inspirational branding. Nobody here will ask you to find your deeper purpose. This is about something far less glamorous and far more useful: who gets the final say on which decisions in a software project.

Second: I’m not claiming divine revelation. The underlying concepts are at least as old as agile itself. But I’ve never seen them assembled quite this way, so I’m allowing myself modest authorship—while feeling faintly ridiculous reaching for grand words like model, methodology, or heaven forbid, framework. Let’s settle on “model” for lack of a better option. Maybe it’ll be useful to someone.

Third: if this smells like Marty Cagan’s empowered teams to you, your nose works fine. Think of it as an evolution of that model—one that, I’d argue, accounts a little better for how most organizations actually operate. More on that heresy below.

The Cast: Three Roles

For the purposes of this model, every project has three functions. Your org chart will call them something different—terminology creativity in our industry is nearly infinite—but the functions are constant:

• The business representative. Product owner, product manager, whatever your organization calls the person who generates work for the engineering team.
• The team lead. The person accountable for the team functioning as a team. “Team lead” is a term of convenience here: in larger organizations this is often an engineering manager, sometimes a technical scrum master, and in others simply the most experienced engineer in the room. What matters is the function, not its formal title—or whether it appears on the org chart at all.
• The dev team. The engineers who actually build the thing. “Dev team” is a simplification; in cross-functional teams this includes designers, DevOps, QA, and anyone else on the delivery floor.

The Territory: Three Questions

Classic agile describes projects as stacks of user stories: “As X, I want Y, so that Z.” You write hundreds of these. Let’s spare ourselves.

Strip away the ceremony, and every task—regardless of complexity—can be described by answering three questions:

• WHY? Why is this worth doing at all? What problem are we solving? This is almost exactly the user story—almost, because we shift the emphasis: narrowing the focus in some areas while significantly widening it in others. The “as X” part can be treated as an afterthought or skipped entirely—which, let’s be honest, is what most teams I’ve worked with quietly do anyway. The “so that Z” part, meanwhile, deserves far more attention than the template usually grants it. What matters here is a clear description of the problem and, critically, a clear justification for why this problem made it to the top of the pile.

• WHAT? What are we actually going to do about it? Perhaps a new microservice, an architecture change, a refactoring effort. On the surface this looks like the “I want Y” of a user story, but it isn’t quite—“I want Y” never descends into technical territory. WHAT is a translation layer: it converts a business need (WHY) into a technical direction.

• HOW? This is where the technical meat lives. Which classes to create, whether we need a database, a new endpoint, an API contract, a message queue. The blueprint.

The Controversial Part: Who Owns What

Here’s the assignment, and here’s where I expect the angry comments:

• The business owns WHY.
• The team lead owns WHAT.
• The dev team owns HOW.

The three questions sit on an axis, and so do their owners:

If you’ve read any product management literature, you’ve noticed the heresy. The classical wisdom says the PM owns the WHY and the WHAT, and engineering owns the HOW. I’m deliberately taking WHAT away from the business and handing it to the team lead.

And if you’ve read Cagan, you’re already drafting your rebuttal: empowered teams get problems to solve, not solutions to build; carving out WHAT for anyone above the team is how feature factories are born. Here’s the promised heresy in full. Cagan describes a destination worth aiming for. Most companies I’ve worked with live somewhere along the road: PMs with deep backlogs and shallow technical context, teams with strong opinions and zero appetite for stakeholder management, and a translation gap between them that someone has to own. Pretending that gap doesn’t exist doesn’t empower the team. Empowered teams still need translation layers—the only real question is whether that translation happens explicitly, or emerges accidentally during sprint planning. Usually badly. Usually in a meeting like the one that opened this article.

The WHAT needs an owner. The team lead—senior enough to challenge the business, technical enough to be challenged by the engineers—is the natural candidate.

Fluid Boundaries (or: How Not to Build a Bottleneck)

The obvious objection: doesn’t this turn the team lead into a bottleneck? A human proxy through which every conversation between product and engineering must pass?

No—and the boundaries are precisely the mechanism that prevents it.

The borders between the three questions are deliberately fluid. Each owner can and should work closely with their neighbors on the axis—while everyone remembers who holds the final say. In practice:

• The PM collaborates tightly with the team lead on WHY. And the traffic runs both ways: the team lead is a legitimate source of WHY, feeding technical necessities into the backlog—runtime upgrades, technical debt, architecture changes. Things that simply have to happen, whether or not a stakeholder asked for them.
• The team lead works both sides of the axis to sharpen the WHAT—translating with the PM on the left, sanity-checking with the engineers on the right.
• On HOW, the dev team keeps control. This is non-negotiable if you want to avoid micromanagement, preserve the team’s sense of agency, and get genuine buy-in for the plans they’ll be the ones executing. The engineers know the technology best—in physical engineering terms, they’re the ones on the factory floor. The team lead still has a voice, most usefully as a tie-breaker when the team splits between competing strategies. But a voice is not a veto over every class diagram.

And here’s the part that kills the bottleneck argument outright: because the team lead’s WHAT territory overlaps with the business “from the left” and with the dev team “from the right,” the PM and the engineers can meet in the middle and hash things out directly. In many situations the team lead doesn’t even need to be in the room—if they trust their colleagues, and they should. Ownership is not attendance. The team lead still owns the WHAT, in the sense that the accountability and the final say rest with them. But an owner who has to personally supervise every conversation isn’t an owner. They’re a chokepoint with a fancy title.

Information Flows Freely; Decisions Don’t

None of this means engineers shouldn’t care about WHY, or that the business should stay away from technology. Quite the opposite—it’s still one team, and everyone should be ready to answer questions about their part of the axis.

The trick is answering at the right altitude. The product manager doesn’t need to know the difference between a class and an interface, or between an outbox worker and a two-phase commit—but they should roughly understand why the team chose that approach. Symmetrically, the dev team doesn’t need to parse budgets, ROI models, or conversion funnels—but they should understand why this sprint is about conversion rates rather than paying down technical debt.

Knowledge flows across the entire axis. Decision rights don’t. That asymmetry is the whole model.

Where This Model Doesn’t Fit

Every model fits only a subset of reality, and even inside that subset it’s not revealed truth—it’s a starting point you adapt to the situation in front of you. Anyone selling you a universal framework is selling you the framework, not the solution.

WHY-WHAT-HOW is no exception. It assumes three distinguishable roles actually exist. In a five-person startup where everyone does everything, drawing this axis is theater. In a team with a strong staff engineer and no formal lead, the WHAT will naturally gravitate toward that engineer—and forcing it elsewhere out of loyalty to a diagram would be exactly the dogma-over-pragmatism mistake this site keeps warning about. And in organizations that genuinely operate the Cagan way—rare, but they exist—the team may collectively own the WHAT just fine, and adding an owner would only subtract.

Use the model where it names a real gap. Skip it where it doesn’t. That advice, unlike the model, is universal.

The Payoff

What the axis buys you is boring and priceless: everyone knows where their competence ends and their neighbor’s begins. The PM stops designing endpoints. The engineers stop relitigating the roadmap mid-sprint. The team lead finally owns something concrete instead of vaguely “being responsible for the team.” Because when nobody owns a question, everyone starts answering it—and that’s usually the exact moment delivery slows to a crawl.

And when the boundaries are clear, violations become visible. A PM dictating implementation details isn’t a personality quirk anymore—it’s a role crossing the axis into territory it doesn’t own, and you can name it as such in the retro.

The full bestiary of those violations—the pathologies, the politics, the ways this goes hilariously wrong—deserves its own article. And frankly, it begs for a rather less professional tone, so it will likely surface soon on my other blog. ;)