Illustrative Use Cases

Three worked examples — with real numbers you can reproduce in the tools — showing how to turn a vague "we're overloaded" into a specific, fixable bottleneck.

About these examples. The scenarios below are illustrative and hypothetical — teaching examples, not case studies of named clients. But the scores are not made up: each one is computed with the tool's published formula, so you can plug the same inputs into the calculator and get the same number. Each is also tied to a primary research source.

1. The engineering team that's exhausted by Thursday

The situation: A development team assumes the code is simply getting harder. But the coding itself feels fine in the moment — the drain is something else.

Model it in the Task Complexity Classifier: Score the daily deployment, not the coding. A manual deploy with 12 steps, 2 decision points, and automation level 1 gives:

TES = (1.2 × 12) + (3.0 × 2) − (0.8 × 1) = 14.4 + 6 − 0.8 = 19.6 → Moderate. Notice where the score comes from: 14.4 of it is raw step count, not decision-making. That's the signature of procedural bloat — lots of mechanical steps, little real judgment.

The fix and its effect: This is the classic split between intrinsic difficulty and extraneous load in Cognitive Load Theory (Sweller, 1988) — the steps add load that was never essential to the work. Automate the pipeline down to 3 steps at automation level 4 and the same formula gives (1.2 × 3) + (3.0 × 2) − (0.8 × 4) = 6.4 → Simple. The fatigue source, not the coding, was the deploy.

2. The support team that "needs more training"

The situation: Agents make frequent ticket-routing errors. Management's first instinct is another training session.

Model it in the Task Complexity Classifier: Score the routing procedure. Documentation full of vague "if it seems urgent… unless…" branches means many decision points. With 6 steps, 5 decision points, automation level 1:

TES = (1.2 × 6) + (3.0 × 5) − (0.8 × 1) = 7.2 + 15 − 0.8 = 21.4 → Moderate, and 15 of those points are decisions. The problem isn't the agents' knowledge — it's a high-entropy bottleneck forcing them to guess.

The fix and its effect: Human-factors research ties ambiguous decision points (not effort) to error (Reason, 1990). Replace the vague branches with an explicit Yes/No checklist, cutting decision points from 5 to 2: (1.2 × 6) + (3.0 × 2) − (0.8 × 1) = 12.4 → Simple. More training wouldn't have moved this number; removing the branching did.

3. The manager who is busy all day but ships nothing

The situation: Nine-hour days, constantly busy, almost no deep work done.

Model it in the Attention Focus Meter: A morning fragmented by three scattered meetings looks like a 60-minute usable session, distraction level 4, motivation 4:

AF = (0.3 × 60) − (2.5 × 4) + (1.8 × 4) = 18 − 10 + 7.2 = 15.2 → Moderate. The distraction term (−10) is eating most of the session — the calendar, not the person, is the problem.

The fix and its effect: Scattered interruptions leave attention residue that outlasts each meeting (Leroy, 2009). Batch the three meetings into one afternoon block to recover a protected 120-minute morning at distraction level 1: (0.3 × 120) − (2.5 × 1) + (1.8 × 4) = 40.7 → High Focus. Same workload, same responsibilities — only the arrangement changed.

Run it on your own numbers. These three follow one method: (1) score the process, not the person; (2) read which input drives the score; (3) change that input and recompute. Try it with the Cognitive Load, Attention Focus, and Task Complexity tools — every formula is shown on its page, so any number here is reproducible.

References