Show Notes
When constrained operations force hard choices
This episode of Built, Wired, and Secured tackles a problem that gets very real very fast: what happens when power, network capacity, or another critical resource is limited and multiple systems all need to stay online at the same time? Alex Morgan frames the issue with a sharp scenario. A campus is dealing with a partial utility outage. Backup power is limited. Lobby doors, clinical pumps, and network switches all want the same feed. The question is not theoretical. What stays on, what gets shed, and how do you explain that decision to the people affected by it?
The discussion stays focused on practical operations. Michael Harrington and James Rogers make the point that constrained events become chaotic when teams have to invent priorities in the moment. Their answer is a repeatable system built on preassigned tiers, fast verification checks, documented exceptions, and regular practice.
Why teams end up in this position
Michael outlines several common causes that repeatedly put facilities and operations teams under pressure:
- Utility brownouts or scheduled curtailments
- Partial generator failures
- Aging battery systems
- Human error during switching sequences
- Cascading failures after a UPS or controller issue
One of the most useful distinctions in the episode is tempo. Not every event unfolds at the same speed. A utility brownout may give a team minutes or even a few hours to act. A switchgear failure can demand immediate action. That difference matters because it changes the playbook. Slower events allow staged shedding, tenant communication, and more deliberate sequencing. Faster events require rules that were approved in advance.
The takeaway is simple: teams should not classify systems only by how they are wired. They need to classify them by consequence. If one failure can trigger several others, the response has to be based on impact, not just equipment layout.
A four-part decision matrix for rapid triage
Michael recommends keeping prioritization simple enough to use under stress. He breaks the decision matrix into four plain dimensions:
- Life safety
- Critical services that prevent irreversible loss
- Revenue impact systems
- Recovery speed, meaning which loads help restore everything else faster
That structure gives teams a fast way to defend difficult decisions. If a system supports life safety, it belongs at the top. If it prevents permanent damage or loss, it stays high on the list. If it directly affects tenant operations or revenue, it needs to be evaluated accordingly. And if keeping a load online materially speeds recovery, that matters too.
James adds a second layer that is just as important: make the tiers tenant facing. In the episode, he suggests clear categories such as Tier A for life safety and clinical care, Tier B for critical systems and high revenue tenants, and Tier C for convenience. He also recommends publishing the exception process in advance for labs, data closets, and other special cases. Transparency reduces friction when service has to be cut back.
How to stop lobbying during the event
One of the most practical parts of the conversation is the discussion about mid-event pressure. When systems are down, managers and tenants will try to elevate their own needs. Michael's fix is procedural and concrete:
- Require a preregistered exception form
- Require two-person signoff for any mid-event reclassification
- Timebox the approval window
- Default to the pre-agreed tier if approval does not happen in time
- Log every request and the rationale for post-event review
That approach keeps the incident commander from getting pulled into ad hoc negotiations while the system is under stress. It also creates a clear paper trail for future improvements.
The two-minute verification that keeps a bad plan from getting worse
James warns that some teams skip simple checks that can make a shedding plan fail before it even starts. His two-minute verification process is short and disciplined:
- Confirm generator auto start
- Verify transfer switch positions
- Check key breaker loads against expected baselines
If any of those checks fail, the team has found a technical blocker early enough to adjust before flipping breakers and compounding the problem. The point is not to add complexity. It is to make sure the first move is grounded in current conditions.
Both guests tie this back to preventative maintenance. Maintenance is what makes quick verification meaningful. If the systems are not tested and the procedures are not practiced, a checklist alone will not save the day.
Two examples that show the cost of getting this wrong
The episode includes two examples that make the framework tangible.
In the first, Michael describes a mixed-use campus facing a utility curtailment that threatened to overload a single generator. The team followed a pre-agreed shedding plan. Life safety systems and core emergency communications closets stayed online. They shed nonessential lighting, reduced HVAC, and isolated two noncritical data closets, touching about 60 circuits. Because tenants already understood the tiers, the operations team could move quickly. What might have become a two-day outage was reduced to less than eight hours.
In the second example, James shares a hospital-related failure. A lab freezer had not been listed as an exception and was shut down during a shed. Roughly 1,200 samples were lost, wiping out weeks of research and creating a costly recovery effort. The corrective action was not complicated, but it was disciplined: require exception registration, connect those exceptions to the escalation log, and script tenant messages with exact wording and timelines.
One more operational point comes from Michael: vendor readiness. A vendor truck at the gate does not help if the team has not handled access, keys, scope, or contact windows. That kind of logistics work belongs in drills too.
Three actions to take this week
The episode closes with specific next steps for facilities leaders and operations teams:
- Map systems into simple tiers and publish them to tenants
- Run the two-minute verification on transfer switches and key breakers
- Collect exception requests and move them into a documented escalation log
Michael adds one more step: build a one-page decision matrix for the incident commander using life safety, critical services, revenue impact, and recovery speed, then get stakeholder signoff. After that, schedule a quarterly tabletop that includes vendors and tenant representatives. If teams do not practice the technical, political, and communication sides together, they will still be improvising when the pressure hits.
What listeners should take away
The core idea in this episode is that fast decisions become safer and more defensible when the work is done in advance. Priorities should be defined before the outage. Exceptions should be registered before the emergency. Communication should be written before the first complaint comes in. The goal is not to keep everything running. The goal is to preserve what matters most, reduce avoidable damage, and make the response controlled instead of chaotic.
For teams responsible for buildings, technology, and tenant experience, this is a useful framework because it applies whether the problem is power, capacity, or another constrained resource. The mechanics may vary by building, but the discipline is the same: classify by consequence, verify quickly, document exceptions, and practice the process until it is routine.
When power is constrained, priorities matter more than hardware specs
Most organizations do not fail during an outage because they lack equipment. They fail because they have not agreed in advance on what matters most.
That is the central message in this episode of Built, Wired, and Secured. Alex Morgan opens with a scenario that feels uncomfortably familiar to anyone responsible for a building, campus, or critical operation. A utility issue creates a partial outage. Backup power is limited. Several important systems all want to stay online at once. Lobby doors need power. Clinical pumps need power. Network switches need power. You cannot keep everything running, so what stays on?
Michael Harrington and James Rogers argue that the answer cannot be improvised in the moment. When teams wait until an event is underway to sort out priorities, they lose time, create confusion, and make decisions that are harder to defend later. Their solution is a compact operational framework built around consequence, tempo, verification, and communication.
Start with consequence, not just connection
One of the strongest ideas in the conversation is that teams should not categorize systems only by where they are connected. They should categorize them by what happens if they fail.
Michael walks through the kinds of events that repeatedly push operations teams into hard tradeoffs: utility brownouts, scheduled curtailments, partial generator failures, aging battery systems, and switching mistakes caused by human error. On paper, those may look like technical problems. In practice, they become prioritization problems.
The reason is that failures do not stay neatly contained. A UPS issue can reboot multiple building automation controllers. A power problem can turn into a network problem. A network problem can affect communications, access, tenant operations, or recovery itself. Once that cascade begins, the fastest path forward is not to debate equipment diagrams. It is to understand consequences.
That is why the episode keeps returning to the same point: classify systems by operational impact. If a load supports life safety, that is obvious. If a load prevents irreversible loss, that belongs near the top. If a system directly affects tenant revenue or keeps recovery moving, that matters too.
Tempo changes the response
Another useful distinction in the episode is tempo. Not every constrained event unfolds at the same speed, and speed changes what kind of response is possible.
A utility brownout may give a team enough time to stage load shedding, coordinate internally, and message tenants before service reductions are felt. A switchgear failure does not offer that luxury. In a fast event, every minute spent debating priorities is a minute lost.
James frames this well. Slow events allow more sequencing and communication. Fast events require preapproved rules. That difference should shape the playbook. If a team knows the event type and knows its preassigned tiers, it can act decisively instead of trying to build consensus during the incident.
This is one reason regular tabletops and simple checklists matter so much. Practice does not remove pressure, but it does remove guesswork. The panel lights up, people move, and the response follows a process instead of a panic.
A decision matrix that works under pressure
Michael recommends a four-part matrix that is simple enough to use during a live event:
- Life safety
- Critical services that prevent irreversible loss
- Revenue impact systems
- Recovery speed
The value of this structure is clarity. It gives incident leaders a way to sort demands quickly and explain why one system stays on while another gets shed. It also keeps the conversation grounded in business and operational outcomes rather than personal preference.
That last point matters more than many teams realize. During an outage, someone will argue that their area deserves priority. Maybe they are right. Maybe they are not. Either way, the decision should run through a framework that already exists.
Michael suggests a practical control for this. If someone wants to change a system's status in the middle of an event, require a preregistered exception form and two-person signoff. Put a time limit on that review. If approval does not happen within the window, the system stays in its pre-agreed tier. Then log the request and the rationale for after-action review.
That procedure does two things. It protects the incident commander from getting dragged into political fights while time is tight, and it creates accountability after the event.
Make tiers visible before anyone needs them
James pushes the framework one step further by making it tenant facing. In the discussion, he outlines a clear tier model:
- Tier A for life safety and clinical care
- Tier B for critical systems and high revenue tenants
- Tier C for convenience
He also recommends publishing exception categories ahead of time, including labs, research spaces, and data closets that may need higher priority than they first appear. When tenants understand the rules before something goes wrong, the response becomes less political and more predictable.
That kind of transparency is not just about avoiding complaints. It shortens recovery because operators spend less time defending decisions and more time executing them.
The two-minute check that can save the whole plan
For all the emphasis on planning, the episode does not lose sight of the basics. James points out that some teams skip simple verification steps that would reveal technical blockers before the first breaker is moved.
His two-minute check is straightforward:
- Confirm generator auto start
- Verify transfer switch positions
- Check key breaker loads against expected baselines
If any of those checks fail, the team has found a problem early enough to adjust. If they skip the check and start shedding loads blindly, they may create a second problem while trying to solve the first.
This is where disciplined maintenance shows up again. Quick checks only work when systems are tested, records are current, and the team trusts what the baseline should be.
Real examples, real consequences
The examples in the episode show both sides of this framework.
Michael describes a mixed-use campus facing a utility curtailment that risked overloading a single generator. Because the team had a pre-agreed shedding plan, they kept life safety systems and core emergency communications closets online, shed nonessential lighting, reduced HVAC, and isolated two noncritical data closets across roughly 60 circuits. Tenant expectations were already aligned with the tier structure, so the operations team could move quickly. The result was significant: what might have stretched into a two-day outage was cut to under eight hours.
James shares the opposite kind of lesson. A lab freezer had not been documented as an exception and was powered down during a shed. Around 1,200 samples were lost, wiping out weeks of research and triggering a costly recovery effort. The fix afterward was administrative but powerful: require exception registration, connect those exceptions to the escalation log, and script tenant messages with exact wording and timelines.
That story is a reminder that operational resilience is not only about generators and breakers. It is also about records, communication, and the discipline to keep special cases current.
Do not forget vendor logistics
Michael adds a detail that often gets overlooked until it causes a delay: vendor readiness. A vendor at the property does not help if they cannot get through the gate, do not have keys, or are unclear on scope. Those logistics should be part of drills, contact trees, and access planning.
In other words, response readiness is broader than technical readiness. The handoffs around the work matter too.
What teams should do next
The episode closes with practical next steps that most facilities and operations leaders can begin this week:
- Map systems into simple priority tiers
- Publish those tiers to tenants and stakeholders
- Run the two-minute verification on transfer switches and key breakers
- Collect and document exception requests
- Build a one-page decision matrix for the incident commander
- Get stakeholder signoff before the next event
- Run a quarterly tabletop that includes vendors and tenant representatives
This is where the conversation lands hardest. Teams do not need a perfect model to improve. They need a usable one. A one-page matrix, a short checklist, and a documented exception process will do more for recovery than a shelf full of plans nobody has practiced.
If your building, campus, or operation depends on limited backup power or other constrained resources, this episode offers a good starting point. Define the tiers now. Collect the exceptions now. Practice the communication now. Then when the next outage hits, your team is not inventing priorities under pressure. It is following a system.
Listen to the full episode for the complete framework and the examples behind it. It is a compact discussion, but it gives owners, facilities leaders, and operations teams a practical way to make high-pressure decisions more controlled, more defensible, and easier to execute.