Managers escalating every decision has three possible causes. Here's the test that separates them, the frame each implies, and what you can measure.
This is one of the most common briefs an L&D consultant gets, and one of the easiest to get wrong. A sponsor says their managers escalate everything. They want a decision-making programme. The budget is there. The temptation is to start designing.
Stop for an afternoon first, because the sentence describes a behaviour, not a cause. There are three ordinary reasons a competent manager escalates a decision, and they lead to three different programmes, aimed at three different units, with three different things you can honestly promise to measure.
Pick the wrong one and the programme will be well built and useless. Worse, it will test well. People will like the workshop and still escalate.
Here is how to tell them apart. If the symptom on your desk is a different one, the symptom-to-framework decision guide covers five others.
Cause one: they cannot decide this. The capability or the authority for this specific decision is genuinely absent. New to the role, new to the decision type, or nobody ever told them where their limit is.
Cause two: they can decide, and deciding costs them something. They have learned that owning a call is dangerous, or that being the person who says no damages something they care about more than they care about speed.
Cause three: the system does not want them to decide. Approval chains, audit requirements, a senior leader who reverses calls, or an incentive that punishes a wrong decision far harder than it punishes a slow one.
Only the first is a training problem in the ordinary sense. The second is designable, but it looks nothing like a decision-making course. The third is not a training problem at all, and saying so out loud is often the most valuable thing you deliver.
Ask these four questions, in this order, with the sponsor in the room. You are looking for evidence that rules a cause out, which is faster and more honest than looking for evidence that confirms one.
1. Do these same people decide confidently anywhere else in their work? If yes, the capability exists. Cause one is ruled out for decisions of that class, and you have cause two or three.
2. Can the sponsor state, in one sentence, what these managers are allowed to decide alone? If they cannot, you do not have a development problem yet. You have an undefined decision right, and no programme fixes that. Write the decision-rights map first and keep it out of the training budget.
3. Has anyone visibly paid a price for a decision that went wrong? If yes, ask what happened to them and who saw it. Fear in this population is usually not generalised. It is a specific memory with a name attached.
4. If every manager started deciding tomorrow, whose job gets harder? If the honest answer is someone senior, you have cause three. A training request is standing in for a conversation nobody wants to have.
If you have not yet had the conversation that produces the symptom in the sponsor's own words, that comes first. The six-stage diagnostic conversation is the input to all of this.
Ask for the last twenty escalations that reached the sponsor. Not a sample, the last twenty, with the date and one line on what was being asked.
Then classify each one:
Count the four columns. It takes a sponsor about two hours to assemble and it will tell you more than a 200-person survey. Two things happen almost every time. The fourth column is larger than the sponsor expected, which changes the size of the problem. And the split between the first three is rarely even, which means the single-cause programme the sponsor asked for was never the right shape.
Put the counts in the design document. It is the cheapest credibility you will ever buy, and it makes the measurement plan arguable rather than aspirational.
The frame is Hersey and Blanchard. Their "Life Cycle Theory of Leadership" appeared in the Training and Development Journal, volume 23, in May 1969. It matches the leader's behaviour to the follower's standing on a single variable, for one task at a time, rather than to the follower as a person.
The vocabulary matters more than it looks, and it has a cost attached. The 1969 paper's variable was maturity. The familiar word readiness came later: in subsequent editions of Management of Organizational Behavior the continuum was changed from maturity levels to follower readiness, and by the ninth edition it was relabelled performance readiness. Separately, in the late 1970s and early 1980s Hersey and Blanchard developed diverging versions, and Blanchard's uses competence and commitment under the term development level.
Three consequences for you. First, if you write "Hersey and Blanchard's readiness model, 1969" in a design document, you have dated a term to a paper that does not contain it, and anyone who checks will find it. Second, those three words belong to two different commercial lineages, so the word you choose quietly points the client at a particular vendor's licensed instrument and materials. Decide that on purpose, before procurement decides it for you. Third, the task-by-task logic is the part worth keeping. The model is useful as a shared language for a delegation conversation. It is not a label you hang on a manager.
Unit of intervention: the individual manager, per class of decision.
Modules that follow: decision-rights mapping, so the limit is written down; delegation calibration against that map; practice on real decisions from the escalation audit, with a named escalation threshold; and a manager-of-manager session, because the person above has to stop taking the decision back.
What you can measure, and it is clean: escalation volume and decision cycle time, on the defined class of decision, against the audit baseline you already built. That is an observable behaviour, so it is a Level 3 measure you can actually defend. Building the chain from a Level 2 item to a Level 4 KPI is the separate piece of work, and it is where most measurement plans quietly break.
Say what the evidence is worth. Situational leadership is the most widely taught model in this article and the most contested. A 2024 article in Management Teaching Review opens: "Situational leadership is a popular management training tool, yet scholars criticize the model's limitations and conflicted empirical support." Use the model for what it is good at, which is giving two people a shared vocabulary for a delegation conversation. Do not present it to a client as validated science.
One more caution on the citation itself. Nobody on our side has read the 1969 article in the original. Secondary indexes disagree about its page range, giving 26–34 and 26–35. If you need the pages in a client document, get the journal, not a reference list.
The frame is Kegan and Lahey. In "The Real Reason People Won't Change" they write: "Resistance to change does not reflect opposition, nor is it merely a result of inertia. Instead, even as they hold a sincere commitment to change, many people are unwittingly applying productive energy toward a hidden competing commitment."
A manager who escalates is often honouring a second commitment they have never said out loud. In the later book, a competing commitment is described as "a commitment to keep the thing we are afraid of from happening," and the authors are explicit that it is protective rather than irrational: "we do not merely have these fears; we sensibly, even artfully, protect ourselves from them."
Underneath it sits the thing that makes the programme designable. A big assumption is defined as "ways we understand ourselves and the world...that we do not see as mental constructions. Rather, we see them as truths, incontrovertible facts."
That is your module content, and it is not a course about decision-making. The sequence in the book is: surface the fear behind the behaviour, convert it into the commitment to self-protection it really is, notice how that makes the counterproductive behaviour sensible, then design a test. The test has its own steps: pick an assumption that can be tested, plan a specific behaviour change that challenges it, decide in advance what evidence would call it into question, run it, and collect what happened outside and inside.
Unit of intervention: the individual, examined against the system they sit in. The second half of that sentence is not optional. If the big assumption is "if I decide and I am wrong, I lose my standing here," and that assumption is correct, then the honest output of the programme is a change to the system, not to the manager.
Modules that follow: surfacing the competing commitment, naming the big assumption, one designed low-stakes test on real work, structured reflection, and a conversation with the manager's own manager that changes the cost of deciding.
What you can measure, stated honestly, and this is the part to refuse ambiguity on. You cannot promise a measured behaviour change at Level 3 inside a quarter on this cause. What you can commit to is counting the tests designed and attempted, and reporting what the participants learned from them. Write that in the proposal. A sponsor who is told at the start that behaviour evidence arrives later will accept it. A sponsor who is told at month nine will not.
When this frame is wrong: applied to a genuine capability gap it produces a lot of uncomfortable and well-reviewed dialogue, and no new skill.
If the escalation audit's third column is the big one, you do not have a development problem. You have approval chains, a reversal habit, or an incentive that makes slow look safer than wrong.
There is one case worth separating out, because it looks like fear and is designed differently. If managers are not raising problems or taking visible calls because the team is not a safe place to be wrong, the relevant construct is psychological safety, and it is a property of the team, not of the person. Amy Edmondson defines it as "a shared belief that the team is safe for interpersonal risk taking" (p. 354), and she set out to test "whether beliefs about the interpersonal context vary between teams in the same organization" (p. 352). They do: she reports that "it is particularly noteworthy that new measures such as team psychological safety and team learning behavior have high ICCs (.39 and .33, respectively)" (p. 365).
So the unit is the intact team, with its actual leader in the room. She also notes that "team leader coaching is also likely to be an important influence on team psychological safety" (p. 356), which is the same point from the other side. A programme that pulls one manager each from forty teams into a workshop on speaking up is intervening at a level the construct does not live at. It will be defensible on paper and produce nothing.
If the cause is structural rather than interpersonal, the deliverable is a one-page note to the sponsor: here are the twenty escalations, here is the share that nobody was allowed to decide, here is what would have to change. That note is worth more to them than the programme they asked for, and it is the sort of thing that gets you called back.
Mixed causes are the normal case, and the instinct is to build one programme that gestures at both. Do not. A design that nods at two frames commits to no claim about cause, and then nothing can be measured, because you can no longer say what the programme was supposed to change.
Sequence instead, and say so in the design document:
Name which stage each measure belongs to. Half the measurement arguments in this work come from a single evaluation plan being asked to carry three different causes.
If you have one meeting and no audit, ask three questions and listen for the answer rather than the agreement.
Those three answers pick the frame. Everything after that is design.
Try this on a real brief. The Diagnostic Conversation Coach is free, takes no signup and no email, and runs this diagnosis against a gap you describe in your own words, including which frame the symptom points to and what it commits you to measuring. If it does not sharpen the way you run a discovery call, nothing else here will interest you.