The Hidden Risk in Building Operations

Some buildings seem resilient right up until the moment the one person who understands a critical system is unavailable. That is the core problem explored in this episode of Built, Wired, and Secured. The discussion opens with a realistic overnight scenario: it is just after 3:00 a.m., a building automation alarm appears, a critical area is moving outside its normal range, and the usual engineer is unreachable. In that moment, the real question is not whether the building has technology. It is whether the operation can make a safe first decision without depending on one person’s memory.

Alex Morgan is joined by Michael Harrington and James Rogers to unpack what they call the “3 a.m. test.” The idea is simple but important: if the usual expert is unavailable, can the next person recognize the issue, take a safe first step, and reach the right support? If the answer is no, the organization has found a continuity gap.

Why Expertise Becomes a Hidden Dependency

One of the episode’s strongest points is that this is not an argument against expertise. Expertise matters. The problem is when essential operational judgment exists only in one person’s head. In many buildings, the most critical knowledge is not always held by the person with the biggest title. It is often held by the engineer who knows which alarms matter, which ones are recurring noise, and which vendor or support path needs to be called first.

The conversation makes clear that this dependency is not always technical. Sometimes it is judgment-based:

• Knowing whether an alarm is real or expected during a schedule transition
• Knowing whether it is safe to monitor a condition or whether escalation is urgent
• Knowing who owns the next decision and who needs to be informed about business impact
• Knowing which workaround has become permanent even though it was originally temporary

These are the kinds of details that often never make it into a formal manual, yet they heavily shape what happens during an after-hours event.

How to Identify Key-Person Risk

The guests offer a practical way to identify operational dependency before it creates a larger problem. One approach is to start with the situation rather than the person. Pick a specific event such as a temperature alarm, communication failure, equipment fault, or access issue. Then ask what decision must be made in the first ten minutes. Another approach is to start by identifying who everyone calls when that event happens. If the same name keeps appearing, that is an early warning sign.

Together, those methods create a more useful picture. Teams should identify both the person and the decision they are carrying. That helps separate what belongs in a handoff from what still requires qualified support. The goal is not to flatten expertise. It is to make sure the first minutes of uncertainty do not depend on private memory alone.

A Realistic Example of a Continuity Gap

The episode offers a bounded example that many listeners will recognize. A controlled area shows a temperature alarm at 3:20 a.m. The system display shows a change, but the area is also moving through a scheduled operating mode transition. The on-call person cannot tell whether the alarm is expected, whether waiting is safe, or whether a technician needs to be dispatched. The person who knows the history is asleep, and the escalation contact list is outdated.

That scenario is not just a training issue. It is a continuity problem. The missing piece is not a complete explanation of the entire system. It is a short, usable decision path that answers a few urgent questions:

• What does this symptom likely mean in this operating mode?
• What can the on-call person safely verify?
• What should they not change?
• When does the situation become urgent?
• Who owns the next escalation?

That kind of short reference is the difference between trapped knowledge and shared operational context.

Why Giant Manuals Fail at 3 A.M.

The conversation draws a sharp distinction between documentation that exists and documentation that works under pressure. Most teams already know they need guidance, but they often swing between two extremes: no documentation at all or a giant manual that no one will open during an overnight event.

The guests argue for something much more focused: a decision aid for the first few minutes. It should help the on-call person answer:

• What am I seeing?
• What may I safely observe?
• What action is allowed?
• What has to wait?
• Who owns the next decision?

Good documentation should also distinguish clearly between observation, action, and escalation. It should define authority, not just tasks. A card or reference sheet that tells someone what to do without clarifying what they are allowed to do can create false confidence and increase risk.

Just as important, the guidance has to be current. A polished procedure with an outdated escalation path is not resilience. The owner, backup owner, preferred contact channel, and expected response path all need regular review.

How to Test Whether the Process Actually Works

The episode emphasizes that teams should not wait for a real emergency to discover whether their documentation is usable. Instead, they should test it with someone who did not help create it. Give that person a realistic scenario and ask them to identify the symptom, explain the first decision, and show where they would escalate.

This kind of exercise does not need to be heavy or formal. It can happen in 15 minutes after planned maintenance. The point is not to prove someone can become the expert overnight. The point is to reveal ambiguity before the next overnight event does.

The conversation also stresses that this testing has to stay non-punitive. If every review becomes an investigation into who missed something, people will protect knowledge instead of sharing it. The purpose is to strengthen the operation, not blame the individuals who have been carrying it.

Questions to Ask After Maintenance or an Incident

One of the most practical parts of the episode is the short list of review questions teams should ask after maintenance or an incident:

• What did we expect?
• What did we actually see?
• Which decision depended on experience?
• What would confuse someone new?
• What should change before the next cycle?

These questions help capture the real lesson, not just the formal closeout. A work order may be marked complete while the most important learning still sits in someone’s head. The guests compare this to preventative maintenance: preventative knowledge sharing reduces the likelihood of avoidable emergency response later.

The Four-Part 3 A.M. Test

The episode closes with a simple framework leaders can use this week:

• Name the dependency: identify the person, decision, contact, or workaround carrying more weight than the organization realizes.
• Capture the decision path: document what the next person should recognize, what they may safely do, and what must be escalated.
• Assign the owner and backup: make the escalation route current, clear, and easy to find.
• Test it with someone unfamiliar: let them use the reference and explain what they would do.

That is the real 3 a.m. test. Operational resilience is not just about redundant equipment or connectivity. It is also about whether the building still makes sense when the usual expert is unavailable. If a process only works when one person is awake, reachable, and available, there is a design improvement waiting to be made.

The 3 A.M. Test: Can Your Building Run Without Its One Expert?

Many buildings look stable during normal business hours. Systems are online, teams know their routines, and the people who understand the quirks of the property are close at hand. But resilience does not reveal itself at noon. It reveals itself after hours, under pressure, when an alarm appears and the one person who usually knows what it means cannot be reached.

That is the premise behind the “3 a.m. test” discussed in this episode of Built, Wired, and Secured. The question is straightforward: if the usual expert is unavailable, can the next person recognize the issue, make a safe first decision, and reach the right support? For property leaders, facilities teams, and technology stakeholders, that question gets to the heart of operational continuity.

The conversation is not really about whether expertise is valuable. It is. Every building depends on people with deep experience. The problem starts when essential judgment, escalation logic, and historical context live in only one person’s memory. At that point, the operation may function, but it is more fragile than it appears.

When Hidden Dependency Becomes Visible

The episode opens with a scenario that feels uncomfortably familiar. It is just after 3:00 a.m. An alarm appears on the building automation system. A critical area is drifting outside its expected range. The usual engineer is on vacation. The person on call tries one escalation number, gets no answer, tries a second number, and then pauses. Is the alarm meaningful? Is it safe to wait? Who has authority to decide?

In that moment, a hidden dependency becomes visible. The building may have modern systems, but if the response relies on one person’s memory, the operation is not fully resilient.

This is an important distinction for commercial real estate and building operations teams. Redundancy is often discussed in terms of equipment, network links, and backup systems. Those matter. But resilience also depends on whether people can understand what is happening well enough to make the next safe decision. If only one person knows how to interpret a recurring alarm, distinguish real urgency from expected behavior, or identify the right vendor path, then the organization has an operational single point of failure.

The Risk Is Often Not on the Org Chart

One of the best insights in the episode is that the critical expert is not always the person with the highest title. In many environments, the most operationally important knowledge belongs to the engineer, technician, or long-tenured team member who has lived through years of workarounds, seasonal patterns, vendor changes, and one-off decisions.

That person may know:

• Which BAS alarm is meaningful and which one is normal noise
• How a system behaves during a scheduled operating mode transition
• Which issue can be monitored and which requires immediate escalation
• Which workaround was supposed to be temporary but quietly became permanent
• Who actually responds after hours when the documented contact does not

None of that knowledge is trivial. In fact, it may be what keeps the building functioning smoothly. But if it remains private knowledge, the organization inherits risk every time that person is off-site, asleep, unavailable, or eventually leaves.

Why This Is More Than a Training Problem

It is easy to describe this challenge as a training gap, but the episode argues that it is something broader: a continuity gap. The issue is not that every on-call person should become a deep technical expert in every system. That is unrealistic and unnecessary. The goal is not to replicate expertise everywhere. The goal is to make sure the next person has enough shared understanding to avoid making the situation worse and to move the issue to the right owner quickly.

That means teams need a way to separate three things clearly:

• What someone can safely observe
• What action they are allowed to take
• What must be escalated to qualified support

Without that separation, organizations create either paralysis or overconfidence. In one case, no one acts because no one is sure what is allowed. In the other, someone takes action outside their safe boundary because the procedure made the task sound simpler than it really is.

How to Find the Pressure Points

The discussion offers a practical way to identify key-person dependency. One method is to start with the event. Instead of asking broadly what systems are critical, choose a specific scenario: a temperature alarm, a communication failure, an equipment fault, or an access issue. Then ask what decision has to be made in the first ten minutes.

Another method is to start with the people. Ask who everyone calls when that event happens. If the same name appears repeatedly, that is a strong signal that the organization depends heavily on one person’s memory or judgment.

The most useful approach combines both. Identify the person, then map the event, the decision, and the safe operating boundary they are carrying. That tells you what belongs in a handoff and what still needs specialist involvement.

Documentation That Works Under Pressure

The episode makes a compelling case against the “giant manual” approach. Big documents may contain useful information, but they often fail when people are under time pressure. At 3:00 a.m., the on-call person does not need an encyclopedia. They need a fast route through uncertainty.

A useful reference should answer a few immediate questions:

• What symptom am I seeing?
• What should I verify first?
• What should I not change?
• When does this become urgent?
• Who owns the next escalation?

It should also include the business context. If the issue affects a tenant-facing service, communication cannot stop at the equipment level. Someone needs to understand the operational consequence, the communication path, and when leadership needs to be informed.

Most importantly, the document must define authority. Knowing what to do is not enough if the on-call person does not know what they are allowed to do. Good guidance prevents false confidence by drawing a clear line between observation, safe first action, and escalation.

Why Escalation Paths Matter as Much as Procedures

A polished procedure is not continuity if the contact information is wrong. That point lands clearly in the conversation. Teams often focus on the procedure itself while overlooking the quality of the escalation route behind it.

For a reference to be operationally useful, it needs current ownership information, a backup owner, a preferred channel, and a realistic response expectation. In other words, the path to help has to be as maintainable as the technical instructions.

This is a good reminder for building operators and property leaders alike. Operational resilience is not just about whether the system can send an alarm. It is about whether the organization can convert that alarm into an informed, timely response.

Test Before the Next Overnight Event

The episode also offers a practical testing model: hand the reference to someone who did not help create it. Ask them to work through a realistic scenario. Can they identify the symptom? Can they explain the first safe decision? Can they find the escalation path?

If they hesitate, misread the symptom, or need repeated interpretation, that is valuable information. It does not mean the person failed. It means the process still depends on memory.

This kind of validation does not need to become a large exercise. It can be done quickly after maintenance or during a brief post-incident review. What matters is the habit. Teams should continually look for the points where understanding is trapped in people instead of embedded in the operation.

The conversation wisely notes that this must stay non-punitive. If every test becomes a blame exercise, people will guard what they know. If the goal is continuity, then the culture has to reward shared understanding.

A Simple Four-Step Framework

To make the concept actionable, the episode closes with a four-part framework:

• Name the dependency.
• Capture the decision path.
• Assign the owner and backup.
• Test it with someone unfamiliar.

That framework is useful because it is small enough to apply immediately. A team does not need to document every system at once. It can start with one alarm, one handoff, or one after-hours decision this week.

If the answer to the 3 a.m. test is no, that is not evidence of failure. It is evidence of an opportunity to improve the design of the operation.

Why This Matters for Business Continuity

For commercial real estate and operational leaders, this topic goes beyond maintenance. Buildings increasingly depend on connected systems, integrated controls, remote monitoring, tenant-facing technology, and overlapping vendor relationships. As those environments become more complex, continuity depends less on individual heroics and more on whether knowledge can be transferred, validated, and used safely under pressure.

That is the broader lesson from this episode. A resilient building is not just one with backup systems. It is one where the operation still makes sense when the usual expert is unavailable.

If you are responsible for facilities, property operations, or the technology that supports them, this episode offers a practical place to start: choose one process, one recurring alarm, or one overnight decision point and ask whether the next person could recognize the issue, take the safe first step, and reach the right support. If not, you have identified a real design improvement worth making.

To hear the full conversation, listen to this episode of Built, Wired, and Secured.