Show Notes
The Maintenance Window Nobody Scheduled
A routine update is scheduled for 6:00 PM. It should take 20 minutes. At 6:12, the console reports complete. At 7:05, a tenant reports several rooms are getting warm. The access desk sees an unexpected warning, and nobody is sure who can call the vendor back or reverse the change. The update was small. The operational footprint was not.
This episode of Built, Wired & Secured explores the uncomfortable gap between finishing technical work and proving the building is actually okay — and what teams can do before a change ever reaches the calendar.
What Makes a Maintenance Window Real
A change request marked "routine maintenance" is not automatically safe to slot into any available window. Before anyone picks a date, three questions need clear answers:
- What exactly is changing — the specific component, service, or sequence being touched, not just the system name
- What should the system do while the work is happening
- What should normal look like afterward
If those answers are fuzzy, the calendar is getting ahead of the plan.
Operational Footprint: Who Notices and Who Responds
A change may involve one controller, but the effect can show up as comfort complaints, an altered access workflow, a delayed alert, or a service interruption that matters to a tenant's business. The conversation before approval should consider the human effect — not by inviting every occupant into a technical meeting, but by ensuring someone with operational ownership has thought through who might notice and who can respond.
The key distinction: pull in the person who owns the affected operation, the person doing the work, and someone who can observe the result. Inform — but do not necessarily pull in — the groups that may experience a temporary effect. The review should expand with the risk, not with someone's fear of missing a distribution list.
Environment Matters as Much as the Equipment
6:00 PM on a quiet day is not automatically safe. The team should consider: Is the building occupied? Is there a major event? Is the engineering team already handling another problem? Is the next person in the response chain actually reachable? The equipment may be identical, but the risk changes with the environment. Vendor availability is one input — not the decision. A window that is available in theory but unsupported in reality because the person who verifies the building is leaving is a plan waiting to fail.
The Go Decision: What Makes It Real
A maintenance window becomes a real go decision when the team can say:
- We know what success looks like and what normal looked like before the change
- We know the evidence that would make us pause or roll back
- The people who own the affected operation are present or reachable
If any of those pieces is missing, the work may still be possible — but the team should be honest that it is proceeding with uncertainty. The baseline does not need to be a giant report. Recording important normal conditions — a schedule, an expected response, a few operating readings, or a workflow check — gives the team something to compare before and after. Without that, verification becomes somebody saying "it seems fine."
Console Check Is Not Operational Check
A dashboard may look normal while people are seeing something else. Verification means asking the operations team, asking the service owner, and using occupant feedback when it is relevant. The person reporting a symptom may be providing the first useful verification. The team also needs to observe long enough to catch the next normal sequence — a command can execute correctly and still fail when the schedule changes, the building fills, or the system has to hand information to another system.
When Something Goes Wrong After the Window
When someone reports a problem after the checklist is already marked complete, the response should start with curiosity: What changed? What was observed? When did it start? Is it still happening? Do not begin by deciding who was at fault. Blame makes people defend their version of events. A good response gets the building stable and preserves the facts.
The review is not a courtroom. Maybe the technical work was correct and the timing was poor. Maybe the plan named the equipment but missed the operating sequence. Maybe the observation period ended too soon. Trust the process — but improve the process when reality shows a gap.
The Five-Minute Conversation Before Any Change
For a lower-risk change, a team can run through five questions in minutes:
- What are we touching? What should happen during and after the work?
- What could be affected? Not just equipment — systems, occupants, services, and workflows that do not appear on the original work request
- Who needs to be named? The person doing the work, the person observing operations, and the person who can say pause or roll back — possibly the same person on a small task, possibly three different people on a connected change
- What will prove success and how long will we observe? If nobody can answer that, the work is not complete when installation ends
- What do we communicate and where does an unexpected effect go?
Five questions, not five layers of approval. The deeper the dependency or the greater the occupied impact, the deeper the review.
Escalation Should Be Ordinary
If the window runs long, a condition moves outside the expected range, or a responsible person cannot be reached, the team should already know what happens next. Escalation is not an emergency — it is a planned part of the process.
The Action for Listeners
Pick one upcoming change. Bring together the relevant facilities, IT service, and contractor contacts. In a short conversation, write down who approves, who communicates, who verifies, and who responds if the result is different from the plan. The best day in operations is the one nobody notices — and that quiet result was usually prepared in advance.
At 5:40 in the afternoon, a building team is still comfortable with the plan. A routine update is scheduled for 6:00. The work should take 20 minutes. At 6:12, the console says complete. At 7:05, a tenant reports that several rooms are getting warm. The access desk sees an unexpected warning and nobody is sure who can call the vendor back or reverse the change.
The update was small. The operational footprint was not.
That is the uncomfortable gap between finishing the work and proving the building is okay. And the first question is not "did the update install" — it is "what breaks if this goes down?" Then: who notices first, and who is prepared to respond?
This is the subject of the latest episode of Built, Wired & Secured, where we talk with Michael Harrington and James Rogers about creating maintenance windows that protect building operations without treating every change as an emergency.
The Calendar Is Not the Plan
A request marked "routine maintenance" is not automatically safe to slot into any available window. Before anyone chooses a date, three answers need to be clear: what exactly is changing — the specific component, service, or sequence being touched, not just the name of the system; what the system should do while the work is happening; and what normal should look like afterward.
If those answers are fuzzy, the calendar is getting ahead of the plan.
The operating impact belongs right beside that question. A change may involve one controller, but the effect can show up as comfort complaints, an altered access workflow, a delayed alert, or a service interruption that matters to a tenant's business. The point is not that every occupant joins a technical meeting. The point is that someone with operational ownership has considered the human effect before approval.
Pull In the Right People, Not Everyone
There is a real risk here: if every possible stakeholder is pulled into every small task, people start treating the process as bureaucracy and then work around it. But operational review is not the same thing as inviting the whole building.
The rule is straightforward. Pull in the person who owns the affected operation, the person doing the work, and someone who can observe the result. Inform — but do not necessarily pull in — the groups that may experience a temporary effect. If the change has no meaningful dependency and no occupied impact, the conversation can be short. The review should expand with the risk, not with someone's fear of missing a distribution list.
The question is not "how many people can we copy." It is "whose decision or response would change if this work went differently than expected?"
The Environment Changes the Risk
6:00 in the evening on a quiet day is not automatically safe. The team should ask: Is the building occupied? Is there a major event? Is the engineering team already handling another problem? Is the next person in the response chain actually reachable?
The equipment may be the same, but the risk changes with the environment. Vendor availability should not drive the window by itself — it is one input, not the decision. A window that is available in theory but unsupported in reality because the person who verifies the building is leaving is a plan waiting to fail.
This exact shape of plan is familiar: everyone is technically assigned, the person with the useful knowledge is in another meeting, the facilities engineer gets pulled into a separate call, and the update finishes before anyone has agreed on what to watch. The work starts at 6:00. By 6:20, the technical screen looks normal. At 6:40, the person expected to watch the next operating sequence is pulled away. The following morning, a few spaces are uncomfortable. Now the team is trying to reconstruct what happened from memory because nobody recorded the baseline or named a rollback trigger.
What a Real Go Decision Looks Like
A maintenance window becomes a real go decision when the team can say three things. First, we know what success looks like and what normal looked like before the change. Second, we know the evidence that would make us pause or roll back. Third, the people who own the affected operation are present or reachable.
If any of those pieces is missing, the work may still be possible — but the team should be honest that it is proceeding with uncertainty.
The baseline does not need to be a giant report. Recording the important normal conditions — a schedule, an expected response, a few operating readings, or a workflow check — is enough to compare before and after. Without that, verification becomes somebody saying "it seems fine."
And a console check is not the same as an operational check. The dashboard may look normal while people are seeing something else. Ask the operations team. Ask the service owner. Use occupant feedback when it is relevant. The person reporting a symptom may be providing the first useful verification.
Observation also needs enough time to catch the next normal sequence. A command can execute correctly and still fail when the schedule changes, the building fills, or the system has to hand information to another system.
When Something Goes Wrong After the Window
What happens when someone reports a problem after the checklist is already marked complete? Start with curiosity: What changed? What was observed? When did it start? Is it still happening? Do not begin by deciding who was at fault. Blame makes people defend their version of events. A good response gets the building stable and preserves the facts.
A review is not a courtroom. Maybe the technical work was correct and the timing was poor. Maybe the plan named the equipment but missed the operating sequence. Maybe the observation period ended too soon. Trust the process — but improve the process when reality shows a gap.
The Five-Minute Conversation
If a team has five minutes before a lower-risk change, here is the conversation that should happen:
What are we touching, and what should happen during and after the work?
What could be affected? Not just equipment — systems, occupants, services, and workflows that do not appear on the original work request.
Who needs to be named? The person doing the work, the person observing operations, and the person who can say pause or roll back. They may be the same person on a small task or three different people on a connected change.
What will prove success, and how long will we observe? If nobody can answer that, the work is not complete when installation ends.
What do we communicate, and where does an unexpected effect go?
Five questions, not five layers of approval. The deeper the dependency or the greater the occupied impact, the deeper the review.
Escalation Is Ordinary
If the window runs long, a condition moves outside the expected range, or a responsible person cannot be reached, the team should already know what happens next. Escalation should be ordinary — a planned part of the process, not a panic move.
Technology should support operations, not complicate them. And the best day in operations is the one nobody notices. Usually, that quiet result was prepared in advance. When people do notice, they should notice an organized response, clear ownership, honest expectations, and a path back to normal.
What to Do Next
Pick one upcoming change. Bring together the relevant facilities, IT service, and contractor contacts. In a short conversation, write down who approves, who communicates, who verifies, and who responds if the result is different from the plan. That small piece of preparation is what turns a routine maintenance window into a controlled operation — and what keeps a small change from becoming an avoidable operational event.
Listen to the full episode of Built, Wired & Secured to hear the complete conversation.