TL;DR
The same weakness looks like a different problem depending on how closely you look at it. At organisation level it appears as a capability gap. At workflow level it appears as friction at a handover. At task level it appears as hours going somewhere nobody accounted for. Most improvement work fails on altitude, not on effort, because the diagnosis was made at one level and the action taken at another. Choosing the altitude is a separate decision from choosing the work, and it should be made deliberately.
A managing director once told me his problem was culture. His people were not taking ownership.
We looked at one workflow for an afternoon. What we found was that the step he cared about most required a decision nobody had been given the authority to make, so it went to him. He was the bottleneck he was describing, and he had diagnosed it at the wrong altitude.
That is the common failure in improvement work, and it has almost nothing to do with effort. A problem gets named at one level and acted on at another. Culture programmes are launched at weaknesses that live in a single handover. Workflow redesigns are commissioned for problems that sit across the whole organisation and will reappear in the next workflow along. Task-level automation is bought for a constraint that was never about the task.
The same weakness, three ways
Take one weakness: nobody is sure who owns a particular decision.
At organisation level it shows up as a capability gap. Decisions are slow across several parts of the business, escalation rates are higher than the rules require, and the leadership team reports that things get stuck. Nothing specific is named, because at this altitude nothing specific is visible.
At workflow level it shows up as a handover that returns work. The stage before sends it on, the stage after sends it back, and both teams believe the other one is the problem. Elapsed time is dominated by waiting, and the waiting is concentrated at one point.
At task level it shows up as a person spending four hours a week chasing an answer. That time appears in no report. If you asked them what they do, chasing would not make the list, because each instance is short and unremarkable.
One weakness, three appearances. The reason this matters is that each appearance suggests a different remedy, and two of the three would be wrong.
What each altitude is good for
Altitude is a choice about resolution, and each one answers a question the others cannot.
Organisation level answers where to look. It compares parts of the business against each other and against what the coming change will demand, and it produces a shortlist. It cannot tell you what to do, and organisations that treat it as though it can end up with a heat map and no actions.
Workflow level answers what is actually happening. It is the altitude where cause and effect are still visible, because you can see the step before and the step after. Most useful improvement work happens here, and it is also the level businesses skip most often, going from a board-level concern straight to a technology purchase.
Task level answers where the time goes and what is worth automating. It is the only altitude that produces a number a finance team will accept without argument, because hours multiplied by frequency is a calculation, not a judgement.
The failure modes
Each altitude has a characteristic way of going wrong, and they are recognisable once you know them.
Diagnosing too high produces a programme with no specifics. The finding is real and the action is a training course, a values statement or a new framework, none of which touches the constraint. Twelve months later the symptom is unchanged and the conclusion drawn is that the people did not engage.
Diagnosing too low produces a local fix that moves the problem. The task is automated, the hours come out, and the bottleneck relocates to the next step, which now receives work faster than it can process it. Total elapsed time is unchanged and everyone involved did good work.
Diagnosing at the right altitude and acting at the wrong one is the most common of the three. The workflow analysis is sound, the handover is clearly the constraint, and the action taken is a system change because that is what there was a budget for.
How to choose
Three questions settle it in most cases, and they are worth asking in this order.
Is the symptom appearing in more than one workflow? If it is, the constraint is probably organisational, and fixing one workflow will teach you something useful while leaving the cause in place. If it appears in one workflow only, start there.
Can you name the step where it happens? If you can point at a handover, a decision or a wait, you have a workflow-level problem and you should stay at that altitude. Vagueness here is usually a sign the diagnosis came from too far up.
Is the question what to change, or how much it is costing? The first is a workflow question. The second is a task question, and it needs counting instead of mapping.
Starting at the wrong altitude on purpose
There is one case where deliberately choosing the wrong altitude is the right move.
If the business has no shared view of where its problems are, and the leadership team disagrees about it, an organisation-level assessment is worth running even though it will not produce an action. Its value is agreement. Five people scoring the same ten elements independently, then comparing, surfaces the disagreements faster than discussion does, and the elements where they disagree most are more informative than the ones they agree are weak.
Equally, a task-level count is worth running when the argument is about money. Nothing settles a debate about whether something matters like knowing it consumes thirty hours a month.
Both of those are legitimate. What makes them work is knowing you are choosing the altitude for what it will settle, instead of expecting a fix it was never going to produce.
Why this belongs in a discipline
Choosing an altitude is a judgement that gets made repeatedly, which is exactly the kind of judgement an organisation should get better at, instead of rediscovering it each time.
That is the argument for Business Evolution as a named practice: the deliberate, continuous building of organisational capability at the rate a business’s ambition requires. Deliberate means designed instead of assumed. A business that has done this a dozen times knows which altitude to reach for, and it knows because somebody kept the record.
The alternative is the pattern most organisations run. Every improvement effort starts from scratch, the altitude is chosen by whoever is convening the meeting, and the lesson from the last attempt left with the person who ran it.
Where to start
Take the symptom currently bothering you most and write it down in one sentence.
Then ask whether it appears in more than one workflow, and whether you can name the step where it happens. Those two answers put you at an altitude. Do the work there, and resist the pull towards the level where the budget happens to sit.
Write down the symptom bothering you most, in one sentence. Then answer two questions about it. Does it appear in more than one workflow, and can you name the step where it happens? Those two answers put you at an altitude. The common error from here is drifting towards the level where the budget sits.
Series navigation
This is the first of five articles setting out the case for Business Evolution. Each stands on its own, and they build in order.
Previously: Why transformation programmes keep failing the businesses that buy them. The structural reason programmes decay after closure, and what a sustainable rate requires instead. Read it at Why transformation programmes keep failing businesses
What a management discipline needs before it earns the name. Naming something is not the same as establishing it. What has to exist before a practice can be called a discipline. Read it at
The full definition sits on the pillar page: What Business Evolution is.
The five
- Your AI business case assumes a capability you may not have.
- Capability is the connective tissue between AI spend and business value.
- Why transformation programmes keep failing the businesses that buy them.
- Three altitudes of change: organisation, workflow, task. You are here.
- What a management discipline needs before it earns the name.
Organisation, workflow and task. Organisation level compares parts of a business and produces a shortlist of where to look. Workflow level shows what is actually happening, because cause and effect are both visible. Task level shows where the hours go and what is worth automating.
Usually because the diagnosis was made at one altitude and the action taken at another. A weakness identified across the organisation gets addressed with a training course. A workflow constraint gets addressed with a system purchase, because that is where the budget was. The analysis can be correct and the action still misses.
Ask whether the symptom appears in more than one workflow, which points to an organisational cause. Ask whether you can name the step where it happens, which points to a workflow cause. And ask whether the question is what to change or how much it is costing, because the second is a task-level counting exercise.
The bottleneck relocates. The task is automated, the hours come out, and the next step now receives work faster than it can process it. Total elapsed time is unchanged, everyone involved did good work, and the improvement does not show up where it was expected.
Sometimes, when the leadership team has no shared view of where the problems are. Scoring the same elements independently and then comparing surfaces disagreement faster than discussion does, and the elements people disagree about most are often more informative than the ones they agree are weak.
Alastair Jupp writes on organisational capability and the practical adoption of AI. The argument here is developed at length in Workflows, Decisions, Discipline: The Operating System Behind Every High-Performing Business, published by Edge151 later this year. Details and publication updates.
Discover more from Edge151
Subscribe to get the latest posts sent to your email.