Show Notes
When a Building Looks Fine but Operations Are Not
This episode of Built, Wired & Secured examines a problem that rarely announces itself with a major outage. A building can be open, occupied, and apparently functioning while key routines depend on manual steps, handwritten reminders, informal phone calls, or one person’s memory. The discussion starts with a simple but revealing scenario: everything appears normal at 6:40 on a Monday morning, yet one routine only happens because someone remembers a note tucked into a control room binder. When that person is absent, the building does not collapse all at once. It simply stops behaving the way everyone assumed it would.
From there, the conversation defines the workaround trap. A temporary bypass, manual check, or informal process may restore service quickly, but if it remains invisible, indefinite, or disconnected from ownership, it becomes operational debt. The point is not that every workaround is bad. In many cases, teams are acting responsibly to stabilize comfort, access, or continuity. The real issue is what happens after the immediate problem is contained.
What a Workaround Really Means
One of the most useful distinctions in the episode is the difference between a sensible contingency and a second operating model that nobody formally approved. That distinction comes down to visibility. The team should know:
- Why the exception exists
- What outcome it protects
- Who is responsible for it
- When it will be reviewed
- Whether someone else can perform it
Without that visibility, a quick fix can quietly become the process people trust more than the intended system. What looked temporary starts becoming normal.
The speakers also make an important point about operational debt. It is not simply a backlog of broken things. It is the cost of keeping an imperfect condition alive without making that cost visible. That cost may show up as extra labor, inconsistent service, uncertainty during an emergency, a physical security exception, or a tenant-facing process that relies on one person’s memory.
How Temporary Fixes Become Permanent Risk
The episode walks through a common example in building operations. After a building transition, a scheduling issue in the building automation system causes some areas to run warmer than expected during the first hour of occupancy. The team responds appropriately by making a manual adjustment each morning so occupants remain comfortable. That immediate action is practical and responsible.
The problem appears later. Because the manual adjustment works, people stop thinking of it as temporary. A new operator learns it as part of the morning round. Property management hears only that comfort is stable. The project team assumes the issue was resolved. Six months later, the system is technically online, but the intended sequence is no longer the process the team trusts.
That is the workaround trap in action. Service is restored, but the organization slowly accepts a hidden dependency.
When a Useful Response Crosses into Risk
The discussion frames this transition in a practical way. A workaround becomes riskier when it has no owner, no review point, and no clear path back to normal. Consequence matters as much as documentation. A low-consequence manual check is different from an exception that affects:
- Access control
- Alarm response
- Critical environments
- Occupant comfort
- The ability to verify that a process actually occurred
The key question is simple: what breaks if this goes down? That question helps leaders distinguish an inconvenience from a dependency that deserves urgent attention.
The episode also avoids a false choice between restoring service fast and restoring it correctly. In the field, teams often have to stabilize the situation before every question is answered. That is not failure. The failure is allowing the emergency response to become the only response people can still see.
What Good Documentation Actually Looks Like
Another strong point in the conversation is that saying something is documented does not necessarily mean the risk is visible. A vague note such as monitor as needed can create false confidence while leaving the real operating condition unchanged.
The minimum useful record can still be brief. In plain language, it should say:
- What changed
- What the operator is doing
- What condition should trigger escalation
- Who is coordinating the next decision
- When the workaround will be reviewed or what event ends it
The value is not paperwork for its own sake. The value is preventing the workaround from blending into normal operations.
How to Spot Invisible Dependencies
Many workarounds do not first appear in a dashboard. They appear in behavior. Supervisors are encouraged to listen for clues during normal rounds, including:
- A repeated handwritten reminder
- A taped instruction
- A device always operated differently from its peers
- A technician saying, I check that one twice
- A comment like, You already know about that
Those small signals reveal where the official process and the lived process have drifted apart.
The episode also points out that tenant-facing teams often notice the consequences before anyone sees a technical exception. They know what takes longer than it should, what must be requested manually, and what only works when a certain person is present. A building dashboard may say a device is available while the operation itself is expensive, inconsistent, or dependent on memory.
How Leaders Should Prioritize Multiple Workarounds
If a review uncovers multiple exceptions, the recommendation is to prioritize by consequence, not annoyance. Leaders should focus first on the conditions most likely to interrupt critical operations, create uncertainty during emergencies, affect physical security, disrupt comfort, or rely on one person alone.
A helpful test is to imagine the worst ordinary day, not the once-in-a-decade disaster. Think of a busy morning, a sick technician, a delayed service call, and a weather change happening together. If the workaround collapses under that level of ordinary pressure, it is not a stable contingency. It is an invisible dependency waiting to surface.
A Simple Framework to Use This Week
The episode closes with a practical framework leaders can use right away. Start by identifying one temporary process in the building or organization. Then ask:
- What are we doing today that is different from the intended process?
- What happens to the building, its occupants, or continuity if that workaround fails?
- Who owns the decision to keep it, change it, or retire it?
Finally, add a review date. Even if the answer is that the workaround is still necessary for now, the review date tells the next person that the condition is known, intentional, and still under active management.
The central message of the episode is clear: restoring service quickly is responsible. Restoring visibility and an exit path is what keeps that responsibility from turning into tomorrow’s operational risk.
The Workaround Trap Is Not About Failure. It Is About Visibility.
Buildings rarely stop working in one dramatic moment. More often, they drift. A manual step gets added to compensate for a system issue. A control point is bypassed to keep operations moving. A routine check gets written on paper because the system cannot yet be trusted to do what it is supposed to do. None of that necessarily means the team is careless. In many cases, it means the team is doing exactly what responsible operators do under pressure: restoring service fast enough to keep the building functional.
The problem begins when that temporary response becomes normal without anyone clearly owning it, reviewing it, or planning its retirement.
That is the core idea behind this episode of Built, Wired & Secured. The conversation explores how workarounds emerge, why they become invisible, and what leaders can do before a useful temporary fix turns into permanent operational risk.
Why Temporary Fixes Feel Safe
The episode opens with a powerful scenario. At 6:40 on a Monday morning, the building is open, the lights are on, and every dashboard looks normal. Yet one routine only happens because of a handwritten reminder inside a control room binder. When the person who knows to follow that reminder calls in sick, the building does not fail all at once. It simply stops behaving the way everyone assumed it would.
That image captures why workarounds can be hard to detect. They often sit underneath apparently normal conditions. Occupants still enter the building. Comfort may still be acceptable. Support may still be delivered. From the outside, the building looks stable. Inside operations, however, stability may depend on extra effort, repeated memory, and informal knowledge transfer.
That is why temporary fixes can feel safe for so long. They work. They help people get through the day. They reduce visible disruption. They create just enough success that the organization stops treating them like exceptions.
The Difference Between Contingency and Operational Debt
One of the clearest insights in the episode is the distinction between a sensible contingency and an unapproved second operating model. Both may involve an exception to the intended process. The difference is visibility.
A sensible contingency is visible enough that the organization can answer basic questions. Why does the exception exist? What outcome is it protecting? Who is responsible for it? When will it be reviewed? Can someone else perform it if the regular person is unavailable?
When those questions go unanswered, the workaround starts creating operational debt.
The discussion makes clear that operational debt is not simply a list of broken assets. It is the ongoing cost of keeping an imperfect condition alive without making that cost visible. That cost might appear as extra labor, inconsistent service, uncertainty during emergencies, a physical security gap, or a tenant-facing process that only works because one person remembers to do something special.
In other words, the building may be technically available while the operation behind it is becoming more fragile.
How Good Intentions Create Long-Term Risk
The episode offers a realistic example from building automation. After a transition, a scheduling issue causes several areas to drift warmer than expected during the first hour of occupancy. The team needs to restore comfort quickly, so someone manually adjusts the schedule each morning. Occupants get through the day. No one is trying to avoid the real fix. The manual step is simply the fastest available path to a stable outcome.
At first, that looks like good operations.
Then time passes. The manual adjustment works well enough that people stop calling it temporary. A new operator learns it as part of the morning round. Property management hears that comfort is stable. The project team assumes the issue was resolved. Six months later, the building automation system is still online, but the intended sequence is no longer the process people trust.
That moment matters because it shows how risk accumulates quietly. The workaround has become part of the building’s actual operating model, but without the governance that should come with any real operating model.
Restoring Service Fast Is Not the Problem
A useful tension in the discussion is the balance between speed and completeness. In the field, operators cannot always wait for a perfect repair before stabilizing conditions. If an area is uncomfortable, they act. If an automated step cannot be trusted, they create a controlled manual process. That is practical, not reckless.
The problem is not fast restoration. The problem is stopping there.
The conversation frames the complete job in two parts. First, restore the outcome. Second, restore visibility and an exit path. That second part is what keeps a short-term adaptation from hardening into long-term risk.
This is a valuable distinction for leadership teams. It prevents them from criticizing necessary field improvisation while still holding the organization accountable for what happens afterward.
Why Documentation Often Fails to Solve the Real Problem
Another theme in the episode is that documentation is only useful when it actually makes the condition visible. A vague work order note can create the appearance of control without changing the risk. If the note says only monitor as needed, future operators may know something unusual exists, but they still may not know what changed, what action is being taken, when to escalate, or who owns the next decision.
The speakers propose a more practical minimum standard. In plain language, the record should state what changed, what the operator is doing, what condition should trigger escalation, and which person or team is coordinating the next step. It should also include a review date or expiration trigger.
That does not require a major reporting burden. The point is not to turn every field adjustment into a project charter. The point is to keep temporary actions from disappearing into routine.
Invisible Workarounds Usually Show Up in Behavior First
One of the strongest operational takeaways in the episode is that leaders should look for extra effort, not just technical faults. A taped instruction, a repeated handwritten note, a device that is always handled differently, or a technician saying, I check that one twice, are all signals. They indicate a gap between the official process and the lived process.
Tenant-facing teams also provide useful evidence. They know what takes longer than it should, what has to be requested manually, and what only works when a certain individual is present. That matters because dashboards often reflect system availability, not operational strain. A device may look fine in software while multiple people are quietly compensating for it every day.
The episode also highlights how risk can hide between departments. Property teams may focus on whether occupants can enter and work. Facilities may focus on whether the building can be operated across shifts. IT and security may focus on visibility and recoverability. None of those perspectives is wrong. The problem appears when they do not meet.
How to Prioritize Workarounds When Everything Cannot Be Fixed at Once
Most leaders do not face one workaround at a time. They face many. The episode recommends starting with consequence rather than irritation. The most urgent issues are the ones that could interrupt critical operations, create uncertainty during an emergency, affect physical security, reduce occupant comfort, or prevent the organization from verifying that something actually occurred.
A particularly useful test is the idea of the worst ordinary day. Do not imagine a once-in-a-decade catastrophe. Imagine a busy morning, a sick technician, a delayed service call, and a weather change all arriving together. If the workaround breaks under those ordinary pressures, it is not a stable contingency. It is a hidden dependency.
This framing is practical because it matches how buildings actually fail: through combinations of ordinary stress, not only through dramatic single events.
A Better Habit for Building Leaders
The episode closes with a simple operating discipline leaders can use immediately. Identify one process that is currently different from the intended design. Ask what happens if that workaround fails. Name who owns the decision to keep it, change it, or retire it. Then assign a review date.
That review date matters more than it first appears. Even if the organization still needs the workaround for now, the date signals that the condition is known, intentional, and subject to re-evaluation. It keeps the workaround from becoming historical background.
Just as important, the speakers recommend placing that review inside meetings that already exist, such as maintenance planning, service reviews, shift handoffs, or project closeout. That keeps the process manageable and makes review part of operational rhythm instead of a separate administrative exercise.
The Real Risk Is Not the Workaround. It Is the Unseen Dependency.
The clearest lesson from this conversation is that a workaround is not automatically a failure. In many situations, it is the responsible first move. Risk appears when the workaround becomes invisible, indefinite, or disconnected from ownership.
If leaders want more resilient buildings, they do not just need functioning systems. They need visibility into how those systems are really being operated day to day. A building can look normal while depending on fragile routines no dashboard will ever fully explain.
This episode offers a useful reminder for property, facilities, security, and technology leaders alike: restoring service is only half the job. The other half is making sure the exception is visible, owned, communicated, and retired when normal conditions return.
If this topic sounds familiar in your environment, this episode is worth a listen. It provides a practical way to identify invisible operational debt before it turns into a continuity problem people only recognize after something slips.