Right Scope, Right Lever:
A 3x3 Framework
for Getting the Most ROI Out of a Fix

Most technology and business problems get "solved" the same way: someone buys a tool, writes a policy, or hires a person, and hopes it sticks. Sometimes it works. Often the return doesn't match the effort, because the fix was the wrong tool for the job: aimed at a layer of the problem it was never going to move.

A classic pattern: leadership mandates a new security platform (a tool) to fix what is actually a lack of accountability (a people problem). The tool gets purchased, nobody owns it, and six months later it's shelfware. Or the opposite happens: a team keeps hiring more people to do something that should have been automated years ago. Both are competent people making a reasonable-looking call. Both get a fraction of the return they should, because the fix didn't match where the problem actually lives.

The fix for this isn't more effort or more budget. It's picking the right scope and the right lever before you spend either, so the change you make is the one that actually returns something. That's what maximizes ROI: not doing more, but doing the one thing that was actually going to move the problem.

This post walks through a simple framework, Scope x Lever, for choosing that intervention deliberately instead of by default.

Two Independent Axes

Think about it the way you'd think about a physical toolbox. Lever is the difference between a hammer and a screwdriver: a different kind of tool for a different kind of fastener. No amount of hammer, swung harder or softer, drives a screw. Scope is the difference between a wrecking ball, a sledgehammer, and a claw hammer: all three are hammers, all three deliver the same kind of force, but they differ enormously in how much force and how broad a swing. Bring a wrecking ball to hang a picture hook and you take out the wall. Bring a claw hammer to a load-bearing demolition and you'll be there all year.

That's the whole framework in one image. Scope is where in the lifecycle a problem lives, which is really a statement about the size and reach of the intervention: Org-level change swings like a wrecking ball, broad and hard to aim precisely; Design-level change swings like a sledgehammer across the whole system at once, how the components fit together; Execution-level change swings like a claw hammer, small and local, one component at a time. Lever is what kind of fix actually addresses it, and that's a difference in kind, not degree: People, Process, and Tool aren't bigger or smaller versions of each other any more than a hammer is a bigger screwdriver. Getting the size right on the wrong tool still fails. Getting the right tool at the wrong size still causes damage. You need both answers, and they're answered separately.

Decision Tree 1: Which Lever?

Start with the problem in front of you and ask three questions in order.

The order matters. Tools amplify whatever process is already in place, and processes only work if the people running them have the standing and skill to follow through. Skipping ahead to Tool without checking People and Process first is exactly how shelfware gets bought.

Decision Tree 2: Which Scope?

Separately, ask where the problem actually originates.

This tree is about origin, not symptom. Design and Execution split along two lines at once: altitude (system-level versus one component) and resolvability (can it be talked through, or does it only reveal itself once it's built). If two engineers at a whiteboard can reason about how the components should work together and land on a solution that won't change once someone starts typing, that's Design. If the question only lives inside one component, and the conversation keeps circling because nobody actually knows the answer until it's built, running, and under load, that's Execution: the doing is the only way to surface the detail the problem needs. A production bug can look like sloppy code when the code is actually a faithful implementation of an architecture that never accounted for the failure mode, in which case the bug is a Design problem, not an Execution one. And that gap in the architecture might trace back further still, to a resourcing call nobody made (Org). Run the tree on the root cause, not the place you first noticed the pain.

Worked Example: AI Security

Say a company is worried about unsafe AI usage across the org: shadow AI tools, unclear model risk, and no consistent review before something ships. Applying the framework produces a full 9-cell grid.

None of these fixes is universally "the" answer. If engineers don't know secure prompt patterns, no CI/CD gate will help until that Execution x People gap is closed. If nobody owns AI risk at the leadership level, an eval harness won't fix a governance vacuum, that's an Org x People or Org x Process problem. The framework's value is forcing you to place the problem correctly on both axes before reaching for a fix.

Worth calling out for a technologist reading this: Org x Tool, "build a unified AI asset inventory platform," is a leadership decision, but it isn't something leadership hands you finished. Design and Execution are how that Org-level Tool decision actually gets answered. Design is the system-level question: how the inventory integrates with existing scanners, CI/CD, and data sources, agreed on before anything is built. Execution is the component-level question: the ingestion scripts, the dashboard, the API, actually written and shipped. And getting the platform to work isn't a Tool problem all the way down. At Design scope you still need an owner for the integration decisions (People) and a process for reviewing them (Process) alongside the diagramming (Tool). At Execution scope you still need engineers who know the domain (People) and a review or testing cadence (Process) alongside the code itself (Tool). One Org-level Tool decision pulls on all three levers again at every scope beneath it, or it doesn't actually ship.

The Takeaway

Before you propose a fix, answer two separate questions: where does this problem live, and what kind of fix does it need. Run the Scope tree and the Lever tree independently. The cell you land on is the intervention with the best odds of actually returning something for the effort you put in.

Real problems often need more than one cell. The AI security example above touches all nine. But that doesn't mean you should change all nine at once. Every scope or lever you touch simultaneously adds a variable, and every variable makes it harder to tell what actually worked, what didn't, and what broke something else on its way through. Change the Org lever and the Execution lever in the same quarter and a result six months out could be explained by either one, or by their interaction, or by neither.

The more disciplined path is usually to pick one lever, or one scope, and move it first. Get the AI risk governance council running before you also overhaul the CI/CD gates. Fix the ownership gap before you also swap the tool. It's slower in the moment, but it's the only way to actually learn which change is carrying the result, which keeps every fix after it better targeted instead of another guess layered on top of the last one.

The framework doesn't replace judgment, it just makes sure your judgment is being applied to the right cell, one deliberate change at a time, before you commit budget, headcount, or engineering time to it.