Zone of Control and Sphere of Influence

Definition

Borrowing H. William Dettmer's three-way system split — the zone of control (what you can change directly), the sphere of influence (what you can affect but not command), and the external environment (what you can't touch at all) — the book applies it to a single story: the need ("in order to...") should sit in the delivery team's sphere of influence, while the deliverable ("I want...") should sit in their zone of control. A story that breaks this pattern is a signal to investigate, not a rule to enforce blindly.

In the Book

Chapter 1 works through both failure directions. When a story's need already sits inside the team's zone of control, it is usually fake (a developer's own need dressed as a user story), a micro-story (a fragment of something larger, tracked separately from the outcome that actually justifies it), or misleading (it names a solution, not a need). The book's central case is a back-office operator asking to "run reports faster" — technically fully within the team's control, which is itself the tell. Tracing the request back reveals the operator actually needs to spot and resolve discrepancies between customer records, comparing report outputs by hand in Excel; report speed only ever touched part of that chain, and "resolving the discrepancies" (calling customers) was never something the team could deliver at all. Rephrasing the need as "resolve customer data discrepancies faster" led to a completely different, cheaper solution: a page that diffs the data sources directly, skipping the slow reports entirely. Conversely, when the deliverable itself sits outside the team's zone of control — needing a specialist central team, as with message-format changes at a financial firm — the fix is to split off the actionable part and start it early so it's ready the moment the external dependency clears.

Why It Matters

Framing a request by who actually controls each part of it turns "this seems like a reasonable ask" into a diagnostic: does the stated need sit where we can actually observe and influence it, and does the stated ask sit where we can actually deliver it? Mismatches point straight at root causes — an over-scoped ask, a mislabeled dependency, a solution masquerading as a need — instead of leaving a team to discover the mismatch only after building the wrong thing. The same triage applies to any handoff between parties with different degrees of control: policy asks, vendor requests, cross-team dependencies.