Shortening an operation off the critical path does not change total time

What it is

If an operation's completion time is shorter than the slack the critical path allows it, compressing it all the way to zero still does not change when the task finishes. Optimization must target the critical path, or move the operation off it. This card is the most direct corollary of "total time is determined by the critical path": understanding the critical path itself is theoretical knowledge, but knowing which optimization work would be wasted effort is the practical conclusion that can actually change how a team allocates its resources.

Why it happens

The root cause of "optimized it, but nothing changed" is the slack that exists in a parallel task: during the wait for a system response, if a user can also finish a hand movement, read a hint, or expand a submenu, and those activities take less time than the response itself, they are effectively "hidden" inside the wait — shortening them further only leaves more slack, it does not make the task finish any sooner, because what determines the finishing moment was never those activities, it was the longer system response. Only three kinds of optimization can genuinely shorten the total time: directly compressing an activity that already has zero slack (genuinely reducing system response time), finding a way to break a dependency that was thought unbreakable (proving that a step assumed to require seriality can actually run in parallel), or redesigning the overall structure of the flow. Before optimizing anything, it is essential to honestly compute the slack of every activity and how it propagates to the finishing moment — otherwise it is easy to pour effort into something conspicuous that has no bearing on the outcome at all.

Where it stops holding

An activity being off the critical path is not a reason to abandon optimizing it entirely — while it does not affect completion time, it can still affect perceived smoothness, the actual error rate, or cognitive load during the operation, all metrics worth attention independently of "completion time." The boundary that genuinely needs drawing is about the goal: if the team's current objective is specifically "make the task finish faster," then pouring resources into optimizing an off-critical activity is, objectively, wasted work, and those resources should flow first to zero-slack activities. In addition, the critical path itself shifts with the strategy a user actually adopts — the same activity can be non-critical under one strategy and become part of the critical path under another — so before judging "is this activity worth optimizing," it is necessary to confirm which user strategy's critical path is currently being used as the basis, rather than reusing a one-time conclusion computed earlier.

Applying it

• List each activity's duration and its corresponding slack explicitly, and rank the results by whether slack exists and how much remains.
• Order optimizations strictly by zero slack first: system response, blocking input, unavoidable confirmation steps, and long hand movements are the categories most likely to sit on the critical path.
• For an activity confirmed to be off the critical path, make only low-cost, opportunistic improvements, or find a way to parallelize it or push it to the background — do not pour significant resources into polishing it.
• How to check: recompute the critical path after every change, and use real measurement to confirm whether the task's finishing time actually shortened — if optimizing a non-critical activity leaves completion time unchanged, that itself is a validation of the model's judgment, confirming the slack estimate was accurate, rather than proof the optimization was wasted.

Related

• Same group: B4.13.1 Perceptual, cognitive, and motor resources can be occupied in parallel during skilled performance · B4.13.2 Total time is determined by the critical path, not the sum of all operation times · B4.13.4 The model applies only to highly skilled performance; novice behavior is not parallel · B4.13.5 Critical-path analysis explains why removing steps did not make the task faster
• Nearby: B4.12 Keystroke-Level Model and Operator Constants · R2 Engineering Delivery
• Search terms: slack time · off-critical optimization · bottleneck · wasted effort