By Daniel “Fiber Dan” Molloy
Managing a crisis is like being on drugs.
Hear me out.
You can read about a drug. Study its chemistry. Have someone explain what it does to perception, attention, and your sense of time. You can understand the description intellectually without knowing what the experience actually feels like from the inside.
Reading about an altered state does not put you in that state.
That is the exact gap between intellectual understanding and lived experience that we ignore when designing emergency operating procedures (EOPs) for mission-critical infrastructure.
In a quiet conference room during a tabletop exercise, you are an analytical systems architect. You have time to read the 40-page PDF, consider the branches, parse the optical butterfly schematics, and ask clarifying questions. You are calm, with room to think.
Then, a civil excavator severs a fiber cable.
Your phone finds you.
Then come the alert storms, the ticket cascades, the bridge calls, and the question everyone wants answered immediately: “What’s the impact?”
Somewhere in your document system is an approved emergency procedure. It has a revision number, a distribution list, and a diagram someone spent considerable time getting right.
Can the person responding use it right now? I call the confidence that document creates paper courage. We have a plan. We passed the compliance review. We checked the box. But paper courage often fails when it matters most—because an emergency procedure has to work for the operator holding the phone when everything else is demanding their attention.
1. The Neurobiology of Operational Failure
To understand why well-funded engineering teams falter during systemic emergencies, you have to look at how people process information under pressure.
Acute stress can impair working memory, attention regulation, and flexible thinking—the same abilities a complicated emergency procedure demands.[1] The procedure may be unchanged. Our capacity to use it is not.
We write the plan in one cognitive state and expect people to execute it in another.
The mental effort required to retrieve and execute a complex procedure peaks precisely when your attention is most fractured. When execution gets messy, management asks why the responder didn’t follow the document. Before blaming the responder, look at what the document demanded of their cognitive load.
2. The Failure Cascade
To ground this in hyperscale reality, consider this illustrative campus scenario: The Fiber Failure Cascade.
A contractor damages a fiber cable. Devices downstream lose connectivity. Core switches flap, triggering state churn.
The monitoring infrastructure broadcasts dozens of down/recovery events, which generate overlapping tickets and repeated emails. The result is an instantaneous Signal-to-Noise Ratio (SNR) collapse. Instead of notifying the operator of a single physical-layer rupture, the system fragments reality into dozens of discrete micro-crises.
Meanwhile, the perfectly formatted Fiber Restoration EOP points to an escalation contact who left the company six months ago. The carrier’s circuit reference number differs from the label the technician sees in the field. The current optical drawing takes three searches to locate in the shared drive.
Every one of those gaps consumes cognitive bandwidth that should be spent on diagnosis and recovery.
3. Engineering for the Ergonomics of Chaos
We would never engineer an optical link assuming an unlimited power budget. We should apply the same rigorous discipline to the attention and cognitive load we require from an operator.
If an operational control plane is to survive catastrophic disruption, it should be engineered around the limitations of the operator under pressure.
- Group Related Alarms
A monitoring system should avoid exposing raw machine states directly to an incident commander. If a shared dependency fails, an operator should see the related alarms together. The first view must collapse the cascade into one actionable summary:Campus network incident — shared fiber path suspected.
Multiple downstream devices affected. Alternate-path status awaiting verification. Field confirmation pending.
Keep the raw telemetry available for the engineers to investigate, but give the incident commander a concise view of impact, uncertainty, and the next action. - Put the Next Action Within Reach
In an altered physiological state, file directories, authentication gates, and multi-tier folder trees represent obstacles that consume time and attention. The first screen should answer: Who is leading? Which maintenance provider do we call? What identifier will they need?
Primary carriers and site PMs should appear as tap-to-call contacts beside the relevant circuit identifiers. If a responder has to type a ten-digit phone number or reconstruct ownership from memory, the interface has failed. - Make Time Visible
Under acute stress, it is incredibly difficult to accurately track time. During a busy response, “I thought someone sent the update” is an entirely preventable failure. Put the notification obligation where the team can see it: a countdown showing the triggering event, the deadline, the assigned person, and a verified record of whether the message was actually sent. Visible deadlines reduce reliance on memory and make ownership clear. - Keep the Plan Operational
A plan begins aging as soon as it is approved. People change roles. Vendors reorganize. Circuits move. Readiness should be subject to automated continuous testing. A named responder whose internal HR account is disabled, or a circuit record that no longer matches the vendor’s API, should automatically flag the EOP as degraded. But a working mailbox does not prove the recipient can dispatch a restoration crew. Readiness still requires human validation through drills that force people to use the actual tools under realistic temporal pressure.
4. Two Views: Response and Readiness
Translating these axioms into reality requires divorcing the response view from the governance view. Trying to squeeze both into a single dashboard makes both harder to use.
- View 1 (Response): Maintained on a focused, phone-friendly canvas for immediate crisis actions. It accommodates uncertainty by answering: What is affected? What do we know? Who owns the next action, and when is it due? While this tactical display is focused entirely on the immediate moment, it must seamlessly preserve the timeline and decisions for the post-incident record.
- View 2 (Readiness): Reviewed weekly by executive leadership. It tracks which dependencies remain untested, which contacts are overdue for verification, and which corrective actions are aging.
Conclusion: Escaping Paper Courage
The defining mistake of modern infrastructure management is the assumption that people have the same attention and working memory available in every operating condition.
The leadership question I put on the table for every infrastructure team is simple: What does the responder have to do before they can do the work?
Count the searches. Count the handoffs. Count the phone numbers copied between screens.
Remove the friction you can, rehearse what remains, and test the result under realistic conditions. You cannot read your way into knowing exactly how a crisis will feel. But you can build a response architecture that asks less of your memory when the pressure arrives.
That is where paper courage becomes operational confidence.
References
[1] Amy F. T. Arnsten, “Stress signalling pathways that impair prefrontal cortex structure and function,” Nature Reviews Neuroscience 10, 410–422 (2009).
Social Profiles