The contest can look ready because one organizer knows how to rescue it.

That person has the platform credentials, remembers which room opens late, knows who can approve a data change, and can reach the judge who never checks the main channel. The event succeeds. The system remains fragile.

Across contest releases, regional sites, training camps, World Finals operations, and local events, I have learned to look for work that is real but absent from the plan. Invisible work becomes an invisible single point of failure.

Trace the event through decisions

A schedule lists activities. An operating map lists decisions.

For a programming contest, someone must decide that the problem set is ready, that the data matches the accepted solutions, that accounts work, that the room can open, that an announcement is authoritative, and that an incident is serious enough to pause the contest.

I write the decision points in time order and attach an owner to each one. The owner is the person permitted to decide, not merely the person most likely to notice.

This exposes gaps that a task list hides. “Set up Kattis” may be assigned. The authority to change a problem after the release candidate is frozen may still be unclear.

Find the private control surfaces

An event often depends on resources the organization does not control.

The registration form belongs to a volunteer’s personal account. The only copy of a contact list lives in an inbox. One laptop contains the final problem package. A room reservation can be changed only by a faculty member who is traveling.

I inventory the control surfaces before the event:

  • credentials and account ownership;
  • source files and release artifacts;
  • rooms, networks, power, and physical access;
  • contact channels and announcement authority;
  • judging, scoring, and incident controls;
  • payment, travel, or vendor dependencies.

For each one, I ask who can act, who can recover access, and how the next person knows the current state.

The backup should be tested. A second administrator who has never logged in is a name, not a recovery path.

Write the exception path

Normal operation receives most of the planning. Exceptions consume most of the judgment.

What happens when a problem statement is ambiguous after the contest begins? When one site loses power? When a participant cannot authenticate? When the scoreboard is wrong? When a trainer misses a flight?

The plan cannot enumerate every incident. It can establish who decides, which facts must be preserved, how participants receive an authoritative update, and what conditions justify a larger intervention.

I use a short incident record:

Time observed, affected surface, current impact, decision owner, action taken, next checkpoint.

The record reduces parallel improvisation. It also supports an honest review after the event.

Move knowledge into the operating surface

A long manual written after the event is often too late and too broad.

I prefer to place knowledge beside the action. The release checklist links to the exact artifact. The room plan includes the access contact. The judging dashboard names the escalation channel. The final handoff lists unresolved items and their owners.

The test is simple: can a prepared replacement perform the next action without calling the original organizer?

If the answer is no, I identify the missing fact. Sometimes the system needs documentation. Sometimes it needs permission. Sometimes the process itself is too dependent on judgment that has never been made explicit.

Use the event to train the replacement

Redundancy is expensive if two people merely watch one person work.

I assign the second person a real decision before the event. They may run a release rehearsal, own one site, lead a problem review, or operate the communication channel during a smaller session. The experienced organizer reviews the result.

This creates evidence that the handoff works. It also finds instructions that made sense only to their author.

Succession should happen while the first owner is available to observe it.

Close the event while evidence is fresh

The most useful review happens before the team disperses.

I ask each owner to record one condition that differed from the plan, one decision that lacked enough information, and one dependency that still has a single owner. The response should change a checklist, permission, artifact, or assignment for the next event.

Praise and frustration both fade into stories. A changed operating surface survives.

My closeout questions are:

  1. Which decision had no explicit owner?
  2. Which action required private access?
  3. Which exception depended on an undocumented relationship?
  4. Which backup path was actually tested?
  5. What can the next organizer operate without asking the current one?

An event is stronger when fewer rescues are necessary. An institution is stronger when the ability to rescue it is no longer private.