Business Bottleneck
Two Kinds of Stalled: A Better Way to Diagnose Business Bottlenecks
A better way to diagnose business process bottlenecks. Not every stalled process is the same problem, and confusing the two makes your fix make things worse.
Sometimes that works. Often it does not, and nobody understands why the same intervention that unstuck the last project does nothing for this one.
The reason: not all stalls are the same problem wearing different clothes.
Research from Samina Karim, Chi-Hyon Lee, and Manuela N. Hoehn-Weiss, published in MIT Sloan Management Review and grounded in a two-decade study of 28 of the largest U.S. carriers, draws a hard line between two categories of bottleneck. Task bottlenecks. Resource bottlenecks. Confuse them and your fix makes things worse.
The structure problem
Task Bottlenecks: A Structure Problem
A task bottleneck shows up when work is waiting on other work. Nothing missing. Just queued behind a dependency.
Two variables drive it: how centralized the workflow is, and how complex the task sequence is. Centralized systems route many activities through one chokepoint, useful for coordination, dangerous when volume spikes. Complex sequences are long chains of dependent steps, and the longer the chain, the more places it can break before it loops back to start.
The researchers' finding cuts against the instinct to always decentralize: short, simple task cycles perform better centralized. Long, complex ones need to run in parallel. Match the wrong structure to the wrong complexity and the bottleneck is already built into the design.
This is a Work Demand Design problem. It has nothing to do with whether the people doing the work are capable, tired, or under-resourced. It is the architecture of the work itself.
The access problem
Resource Bottlenecks: An Access Problem
The second kind is different. The task is not waiting on another task. It is waiting on something to become usable, and usable breaks into two conditions that both have to hold.
Fungibility: can this resource be applied to this task. Slack: is it available right now.
A specialist who can only do one kind of work is not fungible outside that lane. A generalist who is fully booked has fungibility with no slack. Neither converts to output.
Slack alone does not improve performance unless the resource is also fungible. Fungibility alone does not improve performance unless there is also slack to draw on. You need both, at the same time, or you have a resource sitting there doing nothing for you.
Read that again and it should sound familiar. It is the same logic underneath the causal spine behind Capacity Intelligence™: skill existing is not the same as skill being accessible. A person can have the exact capability a task requires and still be the bottleneck, because their capacity state at that moment will not let them deploy it.
Green-zone skill sitting behind a Red-zone person is fungibility with no slack. Looks like a skills gap from the outside. Isn't one.

Case in point
Why the Distinction Matters More Than the Fix
Most diagnostic work goes wrong at the same point: it stops at "things are stalled" and jumps straight to a remedy, usually more headcount or more training, before confirming which kind of stall is actually in front of it.
The airline data makes the cost of that mistake concrete. Every major U.S. carrier flew into the same December 2022 storm. Most absorbed it and recovered within a day or two. Southwest did not. On December 26, with the weather no longer the driver, Southwest logged almost 3,000 cancellations attributed to its own operations, then ran three more days of cancellations in the thousands, a collapse that ultimately cost the airline millions of dollars in federal fines and passenger reimbursements.
The planes and crews were not missing. Southwest ran a point-to-point network instead of the hub-and-spoke model its rivals used, so aircraft and crews ended up scattered across the system with no slack to reposition them and no parallel route around the gap. Long complexity chains. Thin slack. No way around a broken link. That is a resource bottleneck compounding a task bottleneck, exactly the interaction the study was built to explain.
One stalled point cascading through an entire system until a single-day weather event turns into a four-day operational collapse.
Structure problem first. Resource problem second. Fixing the wrong one first buys nothing.
This is exactly why Emergent Skills runs the Four Tests before naming a cause. Skip that gate and you will "solve" a task bottleneck by hiring into a resource problem that does not exist, or you will try to redesign a workflow when the real issue is that your best people have no slack left to give it.
- Baseline shift
- Load signature
- Shared conditions
- Reversibility
Where to start - Bottleneck Effect
The Diagnostic, Not the Symptom
Task bottlenecks and resource bottlenecks interact. A misaligned workflow keeps resources locked up in unfinished work, which starves other tasks downstream. A resource shortage stalls a task even in a perfectly designed workflow. You cannot fully fix one without checking the other.
That is the whole point of diagnosing before spending. Not which department to blame. Not which team needs more people. Which kind of stall is in front of you, structural or access, before a single dollar moves.
If a stalled priority is sitting on your desk right now and you are not sure which kind it is, that is a 90-minute conversation, not a project.
Find Out Which Kind of Stall You're Looking At
The Stalled Priority Snapshot traces one stalled priority to its cause in 90 minutes: a labor-cost number and a 14-day routing experiment, not a project.
Source: S. Karim, C.-H. Lee, and M.N. Hoehn-Weiss, "Improve Workflows by Managing Bottlenecks," MIT Sloan Management Review, Dec. 10, 2024, drawing on "Task and Resource Bottlenecks: A Holistic Examination of Task Systems Through an Organization Design Lens."