Show Notes
When operational knowledge becomes a building risk
A building automation alarm at 6:40 on a Monday morning can expose a problem that has nothing to do with a failed device. The dashboard may show an issue, the equipment may sound normal, and the one engineer who understands the familiar seasonal workaround may be unreachable—or about to leave the organization. At that point, the operational risk is not simply whether equipment is working. It is whether anyone else can determine if the condition is routine, serious, or safe to leave alone.
This episode examines key-person risk in building operations: the risk created when crucial knowledge about a property, system, tenant need, or decision process lives primarily in one person’s memory. The discussion focuses on practical ways to identify concentrated knowledge, transfer useful judgment, and verify that a backup operator is actually prepared to respond.
Documentation is not the full operating story
Buildings collect years of operating history. Drawings, manuals, equipment lists, vendor contacts, shared drives, and binders all matter. But they do not always explain how a system behaves in real conditions.
- A drawing can show where a component is located.
- A manual can describe what the component is supposed to do.
- An experienced operator may know that a reading drifts for a few hours every spring after a schedule change.
- That same operator may know what to compare first, what not to adjust, and when an expected pattern becomes an escalation.
The gap between documented information and operating judgment can be expensive. Organizations may believe they have coverage because multiple people are assigned to a system. In reality, only one person may understand its history, recurring symptoms, temporary measures, escalation paths, and business consequences.
Tenants experience that gap quickly. Response slows, comfort changes, routine issues begin affecting the workday, and the property team may be unable to provide a clear explanation of what is happening.
Find where knowledge is concentrated
The episode recommends beginning with consequences, not paperwork. Identify systems and tasks where a delayed or incorrect decision could affect safety, tenant operations, comfort, building access, or business continuity.
A useful question is: if the usual person were unavailable at 2:00 in the morning, who could make the next sound decision?
That question goes beyond an organizational chart. It reveals who is actually relied on during an issue and whether the team has real operational depth. Look for answers to questions such as:
- Who gets called first when the issue occurs?
- Who knows which condition is recurring and which condition is new?
- Who can explain the system to a new service team?
- Who understands the business consequence of taking the system offline?
- Where does the latest usable record actually live during a disruption?
Phrases such as “just call me” and “I usually handle that” are not inherently negative. They often reflect dependable people doing valuable work. But they can also signal that a process exists inside one person’s memory rather than across the operating team.
Transfer reasoning, not just tasks
The goal is not to document every instinct or turn routine work into a giant paperwork exercise. Judgment developed over years cannot be reduced completely to a checklist. However, the conditions that shaped that judgment can be made visible.
Instead of attempting to capture everything, document what another responsible operator needs to make the next sound decision. This includes the patterns, dependencies, decision points, and consequences that matter when normal conditions change.
Effective knowledge transfer happens around real work. Passive shadowing alone is not enough. The backup operator should explain:
- What they are seeing.
- What they think is happening.
- What they would do next.
- What would cause them to escalate.
- Who needs to be informed and when.
The experienced operator can then correct the reasoning in the moment. This creates a more meaningful handoff than simply reviewing documents or checking off completed tasks.
Use realistic continuity exercises
A tabletop exercise can help facilities, IT, building systems, and property teams practice a real operational decision. Give the backup operator the records and channels they would actually use: maintenance history, approved records, escalation contacts, and normal communication paths.
Then present a plausible scenario. For example, a recurring springtime alarm appears on the morning of a tenant event. There have been three prior service calls. Can the backup operator determine whether this is a familiar seasonal pattern or a condition that requires escalation? Can they communicate the operational impact and identify who owns the next decision?
The test should happen before a departure becomes urgent. Choose a routine disruption rather than the most complicated disaster imaginable. Do not rescue the backup operator too quickly. Observe how they investigate, when they pause, whether they can find the needed history, and whether they can reach the appropriate decision-maker.
Ownership, access, and maintenance history
A continuity plan needs an owner. It should name the responsible role, backup role, decision points, and review date. It should cover normal conditions, warning signs, recent changes, schedule changes, and escalation responsibilities—without exposing sensitive layouts or credentials.
Access should also be reviewed through normal governance. Authorized roles need the access necessary to perform authorized work, and ownership must be adjusted when personnel or service relationships change. Readiness does not require publishing secrets in a checklist.
Maintenance history is especially valuable because it reveals how equipment behaves over time. It should capture the condition that led to each service call, any temporary measure used, and whether the issue returned under a particular season or load. This context supports better capital decisions by helping teams determine whether a short-term adjustment masked a larger concern or whether an asset was operating as expected.
Practical next step
Identify one critical building system or operational task that depends heavily on one person. Transfer the reasoning through active shadowing and a realistic scenario. Then validate the handoff by watching the backup operator act, communicate, and escalate using the resources that truly exist.
When a knowledgeable person leaves and the building continues operating safely and predictably, that is not luck. It is continuity planning working as intended.
The Knowledge Exit Plan: Protecting Building Operations When Experience Walks Out the Door
Operational knowledge is one of the most valuable assets in a building, but it is often one of the least visible. It does not always appear in a drawing set, equipment manual, shared drive, vendor list, or maintenance binder. It may live in the judgment of the facilities engineer who knows which automation alarm is routine every spring, the property manager who understands a tenant event’s operational sensitivity, or the service partner who remembers why a temporary adjustment was made last year.
That knowledge becomes an operating risk when it is concentrated in one person and that person becomes unavailable. They may be on a flight during an alarm, out sick, changing roles, or leaving the organization entirely. The immediate question is not only whether a system has failed. It is whether anyone else can make the next sound decision.
A building automation dashboard may report an alarm while the equipment sounds normal. Is the issue a known seasonal pattern that can be observed? Is it the early warning of a serious condition? Should the team intervene, notify stakeholders, call specialized support, or wait? When the answer depends on one person’s memory, key-person risk has become operational risk.
Why binders and folders can create false confidence
Most organizations have some form of documentation. They may have system drawings, manuals, maintenance records, vendor contacts, shared folders, and checklists. These artifacts are important, but they are not the same as operational readiness.
A drawing can identify where a component is located. A manual can explain its intended function. Neither necessarily explains that a reading drifts for a few hours after a seasonal operating schedule change, what an experienced operator compares first, what should not be adjusted, or when the familiar pattern has crossed into something that needs escalation.
The operating story is usually larger than the documentation. It includes recurring symptoms, informal escalation paths, past service calls, temporary measures, tenant expectations, schedule changes, and the business consequence of taking a system offline. These small decisions are often never recorded because they arise during real work, under time pressure, and through years of pattern recognition.
This can create a misleading picture of coverage. An organization may show two people assigned to a system, but only one understands its history. The chart says the system is supported. The operation says otherwise.
Tenants feel the difference quickly. A slower response, a comfort issue, a building-access problem, or a routine disruption affecting a workday can all expose the absence of shared operational context. Continuity planning is not about diminishing the value of experienced people. It is about ensuring the building does not become fragile because their experience is not shared.
Start with consequences, not documentation volume
It is neither practical nor useful to document every task, decision, or instinct. A massive documentation project can create paperwork without creating resilience. The better approach is to focus on what another responsible operator needs to make the next sound decision.
Start by listing systems and operational tasks where delay could affect safety, tenant operations, comfort, access to the building, or business continuity. Then ask a practical question: if the usual person were unavailable at 2:00 in the morning, who could make the next sound decision?
This question uncovers dependencies that an organizational chart may hide. It prompts a more useful set of questions:
- Who is called first when the issue occurs?
- Who knows whether the condition is recurring or new?
- Who can explain the system’s history to a new service team?
- Who understands the business consequence of taking the system offline?
- Where would someone actually find the latest usable record during a disruption?
Pay attention to phrases such as “just call me” or “I usually handle that.” Those statements often come from dependable people who have earned trust. They are not automatically a problem. They are, however, a useful signal that an important process may live in one person’s memory instead of inside the operating team.
Transfer judgment through active work
Judgment cannot be fully transferred through a checklist. Pattern recognition develops through experience, and it would be unrealistic to pretend that every instinct can be written down. But the conditions behind that judgment can be exposed.
Ask the experienced operator what conditions they watch, what changes their decision, what they compare first, and what would make them escalate. These questions turn invisible operating knowledge into practical guidance for another operator.
Active shadowing is more effective than passive observation. Rather than simply watching someone handle a task, the backup operator should explain what they see, what they think is occurring, and what they would do next. The experienced operator can correct the reasoning in the moment. That is where the transfer of useful judgment occurs.
This approach also brings operational priorities into the conversation. A backup operator needs more than equipment knowledge. They need to understand communication and consequences. If a comfort issue appears during a tenant event, who decides whether to adjust the operation, notify the property team, or call for specialized support? A technically correct response without an operational response is only half a response.
Test readiness with a realistic scenario
The strongest way to determine whether a handoff is complete is to let the backup operator work through a plausible disruption using the resources that actually exist.
A tabletop exercise can provide the structure. Give the backup operator approved records, maintenance history, an escalation list, and normal communication channels. Then introduce a scenario tied to the property’s real operating conditions. For example, present a recurring springtime alarm, three prior service calls, and a tenant event scheduled that morning.
The goal is not to create a high-pressure performance test. The goal is to learn whether the team can distinguish a known seasonal pattern from a condition that needs escalation. Observe whether the backup operator can find relevant history, interpret it, identify who owns the next decision, and communicate the impact appropriately.
Do not wait for a departure to make this test urgent. Choose one routine disruption rather than the most complex disaster imaginable. Do not rescue the backup operator too quickly. Watch how they investigate, when they pause, and whether they can use the available information to move the response forward.
The resulting gaps should be treated as improvements, not failures. If the backup cannot find the history, improve the records. If they can find it but cannot interpret it, improve training. If they know what should happen but cannot reach the decision-maker, improve ownership or escalation. This is how continuity becomes an operating habit rather than an abandoned folder.
Make ownership and access part of the plan
A document without an owner will eventually become stale. A practical continuity plan should identify the responsible role, the backup role, key decision points, and a review date. It should describe normal conditions, warning signs, recent changes, schedule changes, and escalation responsibilities.
The plan should also respect security and governance. It does not need to expose sensitive layouts or credentials. Instead, it should confirm that authorized roles have the access required to perform authorized work and that ownership is managed through normal governance when personnel or service relationships change.
Maintenance history deserves particular attention. An equipment list tells a team what exists. History explains how it behaves. For each relevant service call, the useful context includes the condition that led to the call, any temporary measure used, and whether the issue returned under a particular season or load. That information can shape capital decisions by showing whether a short-term adjustment masked a larger concern or whether an asset was performing as expected.
Build continuity before the transition
The objective is simple: identify one critical system or task where knowledge is concentrated, transfer the reasoning through active work, and verify readiness by observing a backup operator act, communicate, and escalate with the resources that are truly available.
The best day in building operations is often the one nobody notices. When a familiar operator is unavailable and the building continues to run safely, predictably, and responsively, that outcome is not accidental. It is the result of disciplined maintenance, shared knowledge, clear ownership, and a continuity plan that has been tested before it is needed.
For more on protecting the operational knowledge that keeps buildings steady, listen to this episode of Built, Wired & Secured.