Show Notes
Why building technology failures become tenant incidents
This episode focuses on a simple but expensive truth: outages get worse when teams have not practiced the response. The conversation opens with a realistic overnight failure scenario. A storm knocks out a transformer. The backup generator does not start. Power drops. Access control goes offline. Elevators stop between floors. The help desk gets flooded with calls from tenants who cannot badge in. What should have been a manageable outage turns into a four hour tenant incident because nobody on duty has one consolidated playbook.
That setup frames the main argument of the episode. Tabletop exercises are not about pretending systems never fail. They are about rehearsing the human side of recovery so teams do not improvise under pressure.
The three gaps tabletop exercises expose fast
Michael Harrington explains that when a property team has not run exercises, three problems usually show up right away.
- Undocumented dependencies. Building systems rely on other systems, and those links are often not visible until something breaks. A card reader may depend on a PoE switch, and that switch may depend on a network closet with a different maintenance schedule.
- Single points of failure. Teams often tolerate fragile components because they work most of the time. That confidence disappears the moment the one device or one power path fails.
- Silos between teams and vendors. IT, facilities, security, property management, and third party vendors often keep different contact lists and different assumptions about who owns escalation.
The value of a drill is that it brings those hidden assumptions into the open before a real outage does it for you.
A practical example of risk discovery
One of the clearest moments in the episode is an example of a partial power loss exercise. Facilities believed the UPS covered the access control servers. IT believed those servers were cloud hosted. Once the scenario was walked through, the team discovered the access control database was actually local to a rack and supported by a single UPS that was not on the critical maintenance list.
That one exercise changed the plan. The team moved the risk to a redundant UPS and updated maintenance windows. The point was not theoretical. The drill answered a hard operational question before the building had to answer it in production.
How to design a useful tabletop without disrupting tenants
A strong section of the episode covers scope and format. The advice is direct: start with discussion based scenarios. Do not toggle live systems. Do not trigger failovers. Use the exercise to probe decisions without creating real tenant impact.
Realism comes from the conditions you add around the scenario, not from touching production. The recommended approach includes:
- Use time of day constraints
- Assume incomplete vendor staffing
- Add simultaneous failures or conflicting information
- Keep the scope narrow to one subsystem or one failure mode
- Limit the session to 60 to 90 minutes
The roles matter too. Harrington recommends including the facilities lead, IT lead, security lead, a vendor representative, and a tenant representative when tenant facing services are involved. That mix gives the room enough operational reality to test decision making.
A simple tabletop format teams can use right away
The episode gives listeners a practical template for running a first exercise.
- Minutes 0 to 10: scenario briefing and role assignments
- Minutes 10 to 40: primary injects such as power loss, partial network outage, or credential replication failure
- Every 10 minutes: add a new inject that forces a decision, like delayed vendor arrival, conflicting vendor advice, or a tenant escalation
- Final 20 minutes: after action review to capture decisions, unknowns, and immediate mitigations
That structure makes the session manageable while still surfacing weak spots in communication, logging, ownership, and external messaging.
The metrics that make an exercise worth repeating
The discussion does not stop at running the drill. It moves into how to measure whether the exercise was useful. The guidance is refreshingly practical. Track operational metrics that leadership can understand and teams can improve.
- Time to decision for critical calls
- Time to first vendor contact
- Number of undocumented dependencies discovered
- Percentage of injects with a clear owner
- Clarity of communication during the session
- Whether roles were understood
- Whether the runbook steps were actually actionable
These metrics matter because they turn a discussion into evidence. They also give teams a better basis for capital requests and operational prioritization.
Turning tabletop findings into action
The episode outlines two outputs every exercise should produce. First is a short executive summary. Second is an operational runbook.
The executive summary should fit on one page and include the top three risks discovered, recommended fixes with rough cost estimates, and the expected reduction in downtime. That document helps leadership make decisions quickly.
The operational runbook needs more detail. It should include:
- Roles and responsibilities
- Contact lists with primary and backup numbers
- A decision tree
- Safe state procedures
- Quick fallback steps
The runbook also needs versioning, scheduled rewalks, and assigned owners to close findings on a 30, 60, or 90 day schedule.
Case studies that changed spending and operations
Two examples show how small exercises can support real change. In one downtown office, repeated badge failures during peak hours were traced to a single PoE switch in a riser serving two floors. Replacing that switch and adding a small redundant uplink reduced similar incidents from monthly to nearly zero. The capital request was approved because the exercise showed expected operational hours saved.
In another case, a campus with mixed vendor contracts discovered it had no single escalation path for generator testing. The resulting runbook created one vendor on call rotation and a documented test checklist. Vendor response times improved and the facilities team reduced emergency labor costs.
The three actions to take in the next 90 days
The episode closes with a clear sequence for listeners who want to start now.
- Within 30 days, run a one hour tabletop with cross functional leads and a simple power loss inject.
- Within 60 days, produce a one page executive summary with the top three fixes and assigned owners.
- Within 90 days, convert the highest priority fix into a runbook step and schedule a follow up exercise to validate the change.
The message is consistent from start to finish: start small, keep the scenario realistic, and ask one hard question repeatedly. What breaks if this goes down? Teams that can answer that question before an outage are far more likely to control the outage when it happens.
Tabletop exercises are how building teams turn outages into controlled recovery
Buildings rarely fail in neat, isolated ways. A power event can become an access problem. An access problem can become an elevator problem. A tenant communication problem can become the biggest problem of all. That is the point at the center of this episode of Built, Wired, and Secured. The systems in a modern building are interconnected, but many response plans are still fragmented by department, vendor, or assumption.
The episode opens with a realistic overnight scenario that makes the stakes clear. A storm knocks out a transformer. The backup generator fails to kick in. Power drops. The access control system goes offline. Elevators stop between floors. The help desk starts taking calls from tenants who cannot badge in. Nobody on duty has one consolidated playbook. Vendors sit on different call lists. The facilities lead is left trying to figure out what is impacted and who owns which decision.
That is how a manageable outage becomes a four hour tenant incident.
The central argument in the conversation is simple: tabletop exercises exist to rehearse the human side of recovery. They do not repair broken hardware. They do not replace redundancy. What they do is expose assumptions, reveal coordination gaps, and give teams a way to practice decision making before a real incident forces it on them.
Where property teams usually get caught off guard
Michael Harrington identifies three recurring gaps when he walks into a property team that has not been running exercises.
The first is undocumented dependencies. Building systems do not operate in isolation, and teams often do not have a clean map of what relies on what. A card reader may depend on a PoE switch. That switch may depend on a specific network closet. That closet may be on a different maintenance schedule than the systems the team thinks it supports. When the dependency chain is unclear, troubleshooting gets slower and risk stays hidden until failure makes it visible.
The second gap is single points of failure that nobody has tracked because they seem fine most of the time. If a system works on a normal day, it is easy to let fragile architecture linger. A single switch, one UPS, one uplink, one local database, or one escalation path can remain in place for years because nothing forces the team to confront the consequence of losing it.
The third gap is silos. IT, facilities, security, property management, and outside vendors often operate with different assumptions about ownership and escalation. Each group may know its own process, but that is not the same thing as having one response plan. A real incident punishes those gaps fast.
That is why discussion based exercises matter. They surface these issues without forcing the team to learn them during a live outage.
A good exercise starts narrow and stays realistic
One of the best parts of the episode is the advice on how to make a tabletop useful without making it disruptive. The recommendation is not to start with live failovers or system toggles. Start with a discussion based scenario. That lets teams test judgment, coordination, and communication without touching production or creating tenant risk.
Realism comes from the conditions surrounding the scenario. Add time of day constraints. Assume incomplete vendor staffing. Introduce simultaneous failures. Create conflicting inputs that force people to choose what to do next. Those details make the exercise feel real enough to pressure the decision process while keeping the environment safe.
The scope should stay tight. Pick one subsystem or one failure mode per exercise. Keep it to 60 or 90 minutes. Include the people who actually influence the outcome. The episode calls out a practical set of participants: the facilities lead, IT lead, security lead, a vendor representative, and a tenant representative when tenant facing services are involved. That is enough to make the conversation operational rather than abstract.
A simple framework any team can run
The scenario framework shared in the episode is intentionally straightforward.
The first 10 minutes are for scenario briefing and role assignments. Everyone needs to understand what event is being simulated and what role they are playing in the response.
The next 30 minutes focus on primary injects. Those could include a power loss, a partial network outage, or a credential replication failure. Every 10 minutes, the team introduces a new inject that forces a decision. Maybe a vendor arrival is delayed. Maybe two vendors give conflicting advice. Maybe a tenant escalation lands before the team has internal clarity. These injects are not there to make the exercise dramatic. They are there to expose who calls whom, what gets logged, who owns external messaging, and where confusion starts to build.
The session closes with an after action review. That final block is where the value gets captured. Teams document the decisions they made, the unknowns they discovered, and the immediate mitigations they can take.
Without that review, the exercise becomes an interesting conversation. With it, the exercise becomes an operational input.
What to measure so the drill changes something
The episode also pushes back on vague success criteria. If a tabletop is going to justify time and budget, it needs measurable outputs.
The suggested metrics are practical. Track time to decision for critical calls. Track time to first contact with vendors. Count how many undocumented dependencies the exercise uncovered. Note the percentage of injects that had a clearly identified owner. Those are the kinds of measures that tell you whether the team is actually getting more ready.
There are also qualitative signals worth capturing. Was communication clear? Did people understand their roles? Were the runbook steps usable, or did they fall apart the moment someone tried to apply them to a realistic situation?
Those findings matter beyond the operations room. They help leadership see where downtime risk comes from and what type of investment will reduce it.
From exercise to runbook to capital decision
A strong theme in the episode is that the value of a drill is not the drill itself. It is what happens after.
Michael Harrington recommends two concrete outputs from every exercise. The first is a one page executive summary. That summary should list the top three risks found, the recommended fixes with rough cost estimates, and the expected reduction in downtime. It is short on purpose. It is meant to be read and acted on.
The second output is an operational runbook. That runbook should spell out roles, contact lists with primary and backup numbers, decision trees, safe state procedures, and quick fallback steps. It should be versioned. It should be reviewed again. And each finding should have an assigned owner with a 30, 60, or 90 day closeout target.
This is where tabletop exercises become more than planning theater. They create a path from simulation to operational discipline and, when necessary, to defensible capital requests.
What changed in the examples shared on the episode
The two case studies in the conversation make that point well.
In one downtown office, repeated badge failures during peak hours turned out to hinge on a single PoE switch in a riser serving two floors. The response was not a massive redesign. It was a targeted replacement of that switch and the addition of a small redundant uplink. That change reduced similar incidents from monthly to nearly zero, and the capital request was approved because the exercise gave the team a credible way to show operational hours saved.
In another case, a campus with mixed vendor contracts found that generator testing had no single escalation path. The resulting runbook created one vendor on call rotation and a documented test checklist. The impact was practical: faster vendor response times and reduced emergency labor costs for the facilities team.
Neither example depended on vendor hype or oversized transformation language. Both came from drilling a realistic scenario, finding the weak point, and fixing it with a measurable operational case behind it.
How to start in the next 90 days
The closing advice in the episode is one of its most useful parts because it gives listeners a sequence they can actually follow.
In the next 30 days, convene a one hour tabletop with the right leads and run a simple power loss inject. In 60 days, turn that session into a one page executive summary with three prioritized fixes and named owners. In 90 days, convert the highest priority fix into a runbook step and schedule a follow up exercise to test whether the change holds.
That progression matters because readiness does not come from one meeting. It comes from repeating the cycle of scenario, finding, fix, and validation.
The line that sticks with the episode is the question listeners are encouraged to keep asking: what breaks if this goes down? That question changes how teams think about maintenance, escalation, redundancy, and communication. It also changes how they justify spend. Instead of buying on instinct, they can prioritize based on how a real operational failure would unfold.
If your building technology stack touches tenant access, power continuity, network connectivity, or coordinated vendor response, this episode is a practical reminder that recovery does not start during an outage. It starts before the outage, when the team decides to practice. Listen to the full episode for the scenario structure, metrics, and runbook guidance discussed in detail.