The dashboard was beautiful. Forty-three signals from support tickets, sales notes and churn interviews, clustered overnight by a model nobody had to configure, labelled “Onboarding friction.” Red, trending up, impossible to ignore.
The meeting took eleven minutes. Great, so we fix onboarding. Six weeks later a shiny new setup wizard shipped. Usage of the wizard was excellent. Churn among the customers who had actually complained didn’t move.
When someone finally read the forty-three signals instead of the label, the picture was different. Most of them came from enterprise tenants above fifty users, and most of those were stuck on one thing: they couldn’t configure DNS for their own domain without a support call — roughly eleven days of implementation time per deal. The wizard was a fine answer. To a question nobody in that cluster had asked.
Nothing in this story is a failure of sensing. The signals were real, the clustering was decent, the team shipped fast. What failed was the step between “here is what’s happening” and “here is what we intend to change.” I call that step Frame.
(And yes, a cluster. The signal kind. Platform engineers may unclench.)
Between the signal and the lever
The best vocabulary I’ve found for this problem comes from Elisabeth Hendrickson and Joel Tosi’s new book, Signals & Levers. Two definitions carry the whole thing:
“A signal is an observable characteristic of the system.”
“A lever is a choice that causes a shift in the system. Every decision you make is potentially a lever, no matter how large or how small.”
Read the signals, find the levers. It’s a deceptively simple loop, and the book is full of ways to do both well.
What I want to add is the step in between. Before anyone can choose a lever, someone has to decide what the signals mean — which problem they point to, for whom, and which choices are even on the table. That decision is Frame. The book already points in this direction; I want to make it explicit. Between the signal and the lever sits the frame, and because so much depends on it, I treat it as a step of its own: signal → frame → lever, and back to signal to check whether the lever actually was one.
With humans doing all the work, Frame used to happen implicitly, in hallway conversations and in the heads of senior people, often through arguments. John Cutler calls this positive friction: the disagreement that slowed things down was also where weak framings got caught. With agents, that friction disappears, and Frame can’t stay implicit anymore. Agents act on whatever framing they’re handed, and they don’t wander down the hallway to ask.
I · Five ways the dashboard misled us
Signals & Levers offers five recommendations for reading signals. Read them next to the onboarding dashboard and they work like a post-mortem.
“Scan broadly and systematically. Use the CREATE framework to overcome blind spots.” CREATE stands for capacity, risk, execution, adaptability, trust and economics. The cluster lived entirely in execution — friction in a workflow. Nobody looked at economics (eleven days of implementation time per deal) or at capacity (an implementation team that was quietly saturated).
“Attend subtle signals. The loudest signals often mislead.” The loudest complaints came from small customers who found the setup screens confusing. The expensive pain was quiet: a few enterprise accounts, each one escalating through a different channel.
“Distinguish noise. … What seems like noise might be a signal if it creates a pattern across multiple aspects of your system.” A single DNS ticket looks like noise. The same issue showing up in support, in sales notes and in implementation timesheets is a pattern.
“Use goal-question-metric thinking. Start with what you are trying to accomplish.” The goal was never “improve onboarding”. It was expansion revenue in the first quarter after a deal closes. Elisabeth and Joel put it precisely: GQM helps you “avoid drowning in data by starting with what you’re trying to accomplish, then working backward to the signals that matter.”
“Question your proxies. … Ask: What is this proxy really measuring?” “Forty-three” measures how many people complained. It says nothing about what the complaints cost.
The book’s own favourite example of a misread proxy is worth repeating: a platform team consolidating duplicate tools after an acquisition decides to keep the “highest-quality” option, judged by open bugs. One tool has a massive backlog, the other has none. Obvious choice — until someone notices the bug-free tool has no users. The issue count was a signal, just not about quality. It was about adoption.
A cluster is that problem at scale. It aggregates what is observed. Elisabeth and Joel are blunt about what matters instead: the key is to “act where the pain is caused, not where it is observed.” That sentence is the job description of Frame.
II · Every playbook starts one step too late
IT Revolution’s new Enterprise Technology Leadership Journal (Fall 2026) is the best collection of agent-era delivery thinking I’ve read this year, and it makes the gap unusually easy to see.
Timothy Cochran, Bryan Finster, Tim Ottersburg, Scott Prugh and Amy Willard open When Coding is Free, Where is the Bottleneck? with an illustrative value stream: about 281 days of lead time, of which actual coding is roughly 32. Make coding free and nearly nine-tenths of the wait is still there. The largest single block in their figure is the fuzzy front end — requirements — at 93 days.
Their bottleneck table names the failure mode in that phase with five words I’d frame and hang on the wall: “The agent builds the wrong thing quickly.” Their intervention is to use AI to synthesize requirements, expose ambiguity and generate testable acceptance criteria before implementation. That works — once someone has decided what the requirement is for. Synthesizing requirements from forty-three signals produces forty-three well-formatted requirements for a setup wizard.
The paper names the metric for the missing step, too. Among the leading measures of whether a dependency left the system, the authors list “the time from idea to clear intent.” They mention it in passing, as one of four. It deserves a piece of its own, so let me pick up the thread.
A second paper in the same issue arrives at the same place from the other end. Zach Davis, Michelle Gill, Elisabeth Hendrickson, Angie Jones, Sha Ma, Randy Shoup and James Wickett, building a pattern language for code review in the age of agents, conclude that “ambiguity in intent is the dominant source of failure” — and that by the time code reaches review, the most consequential decisions have already been made.
Anthropic’s AI-Native SDLC Playbook operationalizes the agent-era loop more concretely than anything else I’ve seen, and it makes the same starting assumption. Stage 1 captures intent “in the originator’s own words” as an intent.md, which a product owner reviews and accepts. That’s the right artifact. But it arrives as one originator’s view. Forty-three signals would produce forty-three of them, each well-formed, none of them a frame.
One paper measures from idea to clear intent. The other shows that unclear intent is what review keeps catching too late. And the playbook that runs the loop starts with intent as given. Frame is the step that comes before all three.
III · What Frame produces
FIG 1 — From cluster to intent. The clock that matters runs between them.
Frame takes a cluster and returns an intent.
The options are where the real work is. For the onboarding problem there are at least four serious ones, and each is a different lever:
(a) Self-service DNS in the product — fix it once, for everyone.
(b) Customer-success-led onboarding for tenants above fifty users.
(c) Partners or consulting take over the setup.
(d) A commercial decision: offer onboarding free of charge, because the expected expansion is worth more than the cost.
Every one of them addresses the pain. Every one of them pulls on the system somewhere else. This is where CREATE does double duty: the same six dimensions that help you read the signals help you weigh the options.
Two things jump out that a feature backlog would never show. The fastest lever (b) is also the most reversible. And the most generous one (d) is the hardest to undo — nobody enjoys explaining why something that used to be free now isn’t.
A table is still a list. To see how the levers interact, Elisabeth and Joel use causal models: circles for quantities, clouds for qualities, arrows marked + when two things move together and − when they move in opposite directions, and a question mark wherever a decision could change the picture.
FIG 2 — The onboarding loop, drawn in the causal-model notation from Signals & Levers.
The model makes the uncomfortable part visible: this is a loop. More expansion means more onboarding load, which means longer waits, which erodes confidence and, eventually, expansion. Lever (a) cuts the days per deal; levers (b) and (c) add capacity; lever (d) props up confidence directly and leaves the loop itself untouched.
In my experience, drawing a model like this together doesn’t make dominant stakeholders less dominant. It does put sales, product, customer success and finance in front of one picture, and that alone changes the conversation. The five maps from Steve Pereira and Andrew Davis’s Flow Engineering complement this well; the outcome and dependency maps in particular often surface the same tensions from a different angle.
So we choose (b), because it’s fast, reversible, and tells us within a month whether implementation time really is the driver. If it is, (a) goes on the roadmap with evidence behind it.
Elisabeth and Joel have a line for why the options matter at all, built on a children’s board game. In Chutes and Ladders you roll a die and do what the board says. What’s the winning strategy? There isn’t one: “In the absence of choice, there can be no strategy.”
A frame with one option is not a decision. It’s an assumption with a deadline.
IV · Why you can’t hand Frame to an agent
The obvious move in 2026 is to ask a model to frame, too. It will produce something that looks exactly like the intent above, in less time than it took you to read it. That’s the problem.
When an intent is vague at the top, it’s usually not because nobody thought hard enough. It’s because two people with authority want different things, and the vagueness lets both of them sign. Improve onboarding is what sales (enterprise deals closed faster) and product (self-service for the long tail) can agree on precisely because it doesn’t choose.
Vague intent is written-down stakeholder conflict. An agent can’t absorb that kind of ambiguity. It resolves it — by picking a side implicitly, at speed, and producing something plausible enough that nobody notices which side lost until the numbers come in.
That’s why Frame needs a human with a mandate. Not because humans write better frames, but because closing a frame means accepting a trade-off on behalf of the organization. The agent can draft the options, surface the evidence, even fill in the CREATE table. Someone with the authority to say we’re doing (b), and here’s what we’re giving up has to close it.
If you use coding agents, you already know the pattern. The planning step feels like a delay. Spending more time there is also the single most reliable way to get a better result — and it’s where the blind spots surface, while they’re still cheap. Anthropic’s playbook makes plan mode the default starting point and has the engineer ask which options Claude chose not to take. Frame is plan mode for the organization.
V · Framing when the information is thin
Most frames start with less information than the onboarding example. A few moves help:
Talk to the people behind the signals — the support agent who filed the tickets, their peers, the implementation lead. The cluster is a summary; they have the details.
Look for the pattern across segments. Does the same issue show up in other countries, other industries, other customer sizes? If it doesn’t, that’s a signal too.
Run small experiments on more than one option to find the lever with the most pull, before committing to the expensive one.
Close an early feedback loop with customers and internal experts, so the intent stays reversible if it turns out you framed the wrong problem.
One warning from the book that matters more than it looks: “Silence is a signal. When someone asks a question in a meeting and no one replies, it could be an indicator of disagreement, misalignment, or lack of psychological safety.” The first time a team runs a customer-problem investigation like this, I’ve found silence often means something simpler: uncertainty about what’s really being asked. The fix is to bring the intent of the investigation with you — we want to make sure we’re solving the real problem, not the one on the dashboard.
VI · Did you actually pull a lever?
Elisabeth and Joel have a test that every frame should carry with it:
“If you make a choice—change something—and the system does not change at all, whatever choice you made was not a lever within the system.”
That means a frame isn’t finished when we’ve decided what to do. It’s finished when we’ve also decided how we’ll know whether it worked. For the onboarding case: implementation days per deal and first-quarter expansion for tenants above fifty users, checked after eight weeks. If neither moves, (b) wasn’t a lever — and we learned that in a month, not a year.
And there’s the second measurement, the one Cochran and colleagues named: time from idea to clear intent. Start the clock when a cluster crosses whatever threshold makes someone say “we should do something about this.” Stop it when a frame exists that a named owner has accepted: outcome hypothesis, constraints, at least two options, a choice, and a way to check whether the choice was a lever.
Three questions to run on Monday, no tooling required:
Take your last five shipped features. For each, can someone state the outcome hypothesis in one sentence — and name the option you didn’t choose?
For one recent initiative, count the days from the first cluster or complaint to a decision a named person actually owns. If the answer is “it’s complicated”, that’s your answer.
Pick one decision from last quarter. Did the system change afterwards? If nobody checked, you don’t know whether it was a lever.
Close
For thirty years we made building cheaper. Then AI made sensing cheaper, the argument of The Feedback Problem Is Solved. The step between them — turning what we observe into what we intend — is now the scarcest capability in most organizations, and it doesn’t respond to more compute.
Coding was never most of the 281 days. Frame might be.
The next piece picks up what follows: once a frame is closed, who carries the intent? That’s where Team Topologies comes in — and where agents start changing the answer.
Sources
Elisabeth Hendrickson, Joel Tosi: Signals & Levers: Systems Thinking Tools to Unblock Software Delivery. IT Revolution, 2026. Adapted as Signals and Levers: How to CREATE Real Change, Enterprise Technology Leadership Journal, Spring 2026.
Timothy Cochran, Bryan Finster, Tim Ottersburg, Scott Prugh, Amy Willard: When Coding is Free, Where is the Bottleneck? A Guide for Leaders Building Agent-Ready Delivery Systems. Enterprise Technology Leadership Journal, Fall 2026.
Zach Davis, Michelle Gill, Elisabeth Hendrickson, Angie Jones, Sha Ma, Randy Shoup, James Wickett: Agentic AI and Code Reviews: Toward a Pattern Language for Code Reviews in the Age of Agentic AI. Enterprise Technology Leadership Journal, Fall 2026.
Louis Claxton (Anthropic): The AI-Native SDLC Playbook. Anthropic, 2026.
The Enterprise Technology Leadership Journal is published by IT Revolution under CC BY-NC-SA 4.0.
Part of the Intent Architecture body of thought — About.