You are learning to make overload explicit.
You will receive a concrete workload with durations, deadlines, dependencies and delegation limits. First you will see the scheduling math and a worked example. Then conditions change until all desirable work no longer fits. Your job is to preserve the system—not the appearance of being busy.
Heroic speed, stress tolerance, perfect memory, or a fake “workload score.”
Start from the work that actually exists.
A university observatory is preparing its next target when a weather review comes due. One trained operator has the enclosure controls. A trainee can perform approved software tasks after a one-minute handoff. The learner does not need to memorize any of this; the Operating Brief will remain available throughout the exercise.
21:03. One operator can perform only one attention-locked task at a time.
| Task | Duration | Deadline / trigger | Who can do it | Consequence if late |
|---|---|---|---|---|
| Weather decision | 1 min | By 21:04 | Operator | Enclosure-protection decision delayed. |
| Close enclosure | 3 min | Only if threshold crossed; complete by 21:08 | Operator | Equipment remains exposed after the closure threshold. |
| Data checkpoint | 2 min | Complete by 21:07 | Operator or trainee after 1-min handoff | Current observation metadata becomes unrecoverable. |
| Next-target slew | 4 min | Start in time for 21:10 acquisition | Operator | Next observation opportunity is lost. |
| Quick-look plot | 3 min | No hard deadline | Operator or trainee | Scientific convenience delayed. |
| Shift log | 4 min | Before 21:30 handoff | Operator; trainee may draft | Handoff record incomplete if never recovered. |
Make the schedule visible before making a priority judgment.
“Important” is too vague. Workload decisions improve when the learner can see time-to-deadline, required uninterrupted work, dependencies and whether someone else can legitimately carry the task.
The equations and worked example remain available later. You are not being tested on memorizing them.
deadline − required duration − required setup / handoffThe latest time a task can begin without already depending on luck.
latest safe start − current timePositive slack means the task can still move. Zero slack means it must start now. Negative slack means the original plan is already impossible.
high consequence + short time-to-effect + no substituteProtection is qualitative; do not invent a universal score.
delegate / defer / drop when consequence is boundedEvery shed task keeps an explicit owner or an explicit accepted loss.
Suppose closure has become required. Closing takes 3 minutes and must finish by 21:08.
latest safe start = 21:08 − 3 min = 21:05slack at 21:04 = 21:05 − 21:04 = 1 minThe data checkpoint takes 2 minutes and must finish by 21:07. If the operator personally performs it first, 21:04 + 2 min = 21:06, which is already after the enclosure's latest safe start. The two tasks cannot both be done sequentially by the operator without missing a deadline. If the trainee is available, a one-minute handoff from 21:04–21:05 lets the trainee checkpoint 21:05–21:07 while the operator closes 21:05–21:08.
Before the weather result, decide what you are protecting.
At 21:03 the closure is not yet required. The weather decision is due in one minute. Build the first plan without assuming the alert will worsen.
Prematurely abandoning the next target is not automatically competent.
1. What must happen first?
The answer should follow from the earliest non-delegable decision clock.
2. Which work is the best delegation candidate if conditions worsen?
Use authority and deadline—not status or prestige.
3. Which task can safely wait without consuming a hard deadline?
New evidence changes the workload.
At 21:04 the weather review crosses the enclosure-closure threshold. Closing now becomes required by 21:08. The trainee is available. Recalculate before acting.
21:04.
21:04–21:05: operator hands the data checkpoint to trainee.
21:05–21:07: trainee checkpoints data while operator closes enclosure.
21:05–21:08: operator completes enclosure closure.
This preserves both protected tasks, but there is no operator capacity left for the next-target slew. The observation opportunity must be deliberately shed.
What is the coherent plan now?
Now the plan breaks.
At 21:05, just as the handoff finishes, the trainee's terminal loses access. The trainee cannot perform the checkpoint. The operator is now the only person who can act, and enclosure closure still requires the full 21:05–21:08 interval.
21:05. Data checkpoint deadline 21:07. Enclosure deadline 21:08.
The capacity equation is now impossible.
Operator time available before the data deadline: 2 minutes. Data checkpoint needs 2 minutes. But using those 2 minutes would delay enclosure closure until 21:10, two minutes past its required completion. Doing enclosure first consumes 3 minutes and makes the data checkpoint deadline impossible.
This is the moment task shedding becomes a real capability. The learner must choose the loss explicitly instead of pretending every objective remains available.
Which loss do you accept?
What happens to the next-target observation?
Task shedding ends when the overload ends.
At 21:08 the enclosure is closed and stable. The current observation metadata was lost. The next-target opportunity is gone. Capacity has returned, so the learner must rebuild the queue rather than remain in permanent emergency mode.
Stabilized ≠ finished. Restore legitimate deferred work and document accepted losses.
What should happen next?
What does the accepted loss mean?
Same capacity law. Different work.
A Black Knight observation-instrument service window is open. The surface details change, but the learner still has to use durations, deadlines, authority and consequence. This is a training simulation, not a canon event.
Recognize overload structure without copying the observatory answer.
| Task | Duration | Deadline | Authority | Consequence |
|---|---|---|---|---|
| Restore instrument-bay seal | 3 min | Complete by 22:28 | Operator only | Service window cannot close correctly. |
| Capture diagnostic bundle | 2 min | Complete by 22:26 before node reboot | Operator or service partner | Current diagnostic state lost. |
| Optional calibration sweep | 4 min | Useful only before seal restoration | Operator | Calibration opportunity lost. |
| Configuration log | 3 min | By 22:40 | Either; operator reviews | Later handoff weakened if omitted. |
diagnostic latest safe start = 22:26 − 2 min = 22:24seal latest safe start = 22:28 − 3 min = 22:25configuration-log latest safe start = 22:40 − 3 min = 22:37The optional calibration sweep takes 4 minutes and must occur before seal restoration, but it has no protected deadline. One operator means these actions must be scheduled sequentially. Use the same protect / defer / drop logic to decide what still fits.
Choose the cross-context plan.
Make the workload decision reconstructable.
A useful record preserves what was protected, deferred, delegated, or deliberately lost; what evidence changed the plan; and which obligations return after stabilization. It reveals the trade rather than rewarding busyness.
Prioritization and task-shedding reasoning in this simulation.
Use ordinary overloaded work.
On a bounded workday, project or rehearsal, write down durations, deadlines, dependencies and who can legitimately carry each task. When overload appears, make the shed/defer/delegate decision explicit and review what actually happened.
If “everything is priority one,” if dropped work disappears silently, or if stabilization never leads to recovery of deferred tasks, the capability is degrading.