Show Notes
When One Person Holds the Operating Context
A building can have current service contracts, capable teams, working systems, and complete equipment records while still carrying a serious operational weakness: one person may be the only reliable bridge between building automation, security, connectivity, and tenant operations. This episode examines the knowledge transfer gap that appears when the person who understands “what normal looks like” is suddenly unavailable.
The issue is larger than a missing password or an outdated drawing. Critical judgment often accumulates in one person’s memory over time: why an alarm is expected after a particular event, which schedule adjustment affects a comfort complaint, what service history matters, what information a provider needs to troubleshoot, and when a team should stop and escalate rather than make a change.
Why Knowledge Gaps Appear at the Seams
Individual systems may be documented, but the relationship between systems often is not. That is where operational knowledge becomes especially valuable and especially vulnerable.
- A temperature complaint may appear to be a controls issue but actually relate to a schedule change made during an occupancy adjustment.
- A security event may be technically normal, yet the property team still needs to know who communicates with the tenant.
- A service provider may need specific history before troubleshooting can begin.
- An alarm may be ordinary after a known event, while a similar alarm may require an immediate escalation.
These are not merely technical distinctions. A delay of 20 minutes can matter when occupants are waiting for a comfortable workspace, normal access, or a clear answer about what is happening. The eventual fix may be simple, but unclear context, communication, and ownership can turn a manageable condition into a disruptive experience.
Transfer Judgment, Not Just Access
During construction, commissioning, and routine service work, unusual problems get solved quickly. Someone may explain the solution over a phone call, leave a note somewhere, and move on. Because that person knows the history, they become the person everyone calls. It is efficient in the moment, but over time the building begins to depend on an individual instead of a repeatable operating method.
A strong handoff does not mean preserving every workaround forever. Some workarounds may be outdated or inappropriate. The practical sequence is to capture the reason behind the workaround first, validate it second, and then decide whether it belongs in the operating guide. The objective is not a museum of old decisions. It is usable knowledge that lets the next responsible person make a safe decision.
What Usable Operating Knowledge Looks Like
More pages do not necessarily create more readiness. A massive binder, shared folder, or note-taking requirement can become difficult to use when the team needs one current instruction during an outage. A shorter guide organized around real situations may be far more effective.
- What does normal look like?
- What has changed from the original design or operating pattern?
- What should an operator check first?
- What should be verified after a service visit?
- Which system is authoritative for the condition?
- What can this role do safely?
- What should make the operator stop and escalate?
- Who communicates with the property team and affected occupants?
- Who records the decision and confirms normal service has returned?
Knowledge continuity also needs ownership. Someone must confirm that the guide remains current, review changes, and provide backup coverage. Without ownership, operating documentation can age faster than the equipment record.
A Practical Test for This Week
Choose one critical system and ask: who could operate this tomorrow if the primary expert were unavailable? The question is not who can find the manual. It is who can recognize the condition, take the approved first step, communicate the impact, and escalate with useful information.
Listen for sequence when the primary expert explains their process. What do they verify before acting? Which system do they check? What condition would make them stop? If the answer is “I usually just know,” treat it as a visibility signal rather than a criticism. The judgment needs to become visible enough for another qualified person to use safely.
Test the Receiving Team, Not the File Transfer
A service transition example illustrates the difference. An incoming technician sees a temperature alarm that the outgoing team recognizes as common after a seasonal schedule change. Before changing a set point, the incoming team should compare the operating schedule, check the last approved change, review recent service notes, and confirm the escalation path.
Receiving credentials and an equipment list is not the same as receiving judgment. The handoff is complete when the receiving team can repeat the scenario in its own words: what it would check, what it would document, and when it would call for help.
Build Role-Appropriate Readiness
Backup coverage does not require every person to become an expert in every system. The realistic target is role-appropriate readiness: recognize normal conditions, take the safe first step, avoid making the situation worse, and involve the right specialist with the right information.
Run a short rehearsal through a planned absence, service transition, quarterly review, or major system update. Let the backup person pause and ask basic questions. Avoid rescuing the exercise so quickly that the gap remains hidden. A rehearsal can expose outdated contacts, obsolete screen references, unclear escalation paths, or two teams waiting for each other to act.
Protect Sensitive Information While Improving Continuity
Usable knowledge does not mean sharing sensitive layouts, detailed security information, or every system detail with everyone. The goal is to make the right roles ready with the right information while maintaining appropriate access controls. Clarify responsibilities, dependencies, approved procedures, and escalation paths without creating a new security risk.
Three Practical Moves
- Identify one critical system where a single person is the only reliable path to action.
- Capture decision context: what normal looks like, what has changed, and when to escalate.
- Test the handoff with someone who was not part of the original project or service history.
Choose one system, one backup person, and one realistic scenario. Make one improvement someone can actually use when it matters.
The Knowledge Transfer Gap Is an Operational Risk
Many buildings appear organized until an exception occurs. The systems are functioning. Service contracts are current. Equipment records exist. The team is capable. Then a critical alarm appears after a weekend power event, a service vendor asks whether it is expected, and the person who understands the normal operating pattern is unavailable.
At that moment, the immediate failure may not be the equipment. It may be the organization’s confidence about what to do next. Should the team acknowledge the alarm? Change a setting? Call for help? Wait for more information? Who should communicate with the property team or affected occupants?
This is the knowledge transfer gap: the operational risk created when essential context, judgment, and decision sequence live primarily in one person’s memory. It is common across building automation systems, physical security, connectivity, and tenant operations because the most important knowledge often develops over time at the seams between systems and teams.
Documentation Is Necessary, but It Is Not the Whole Answer
When organizations think about a knowledge gap, they often think about missing passwords, drawings, credentials, or equipment inventories. Those items matter, but they are only part of continuity.
The more difficult knowledge is judgment. An experienced person may know that one alarm is common after a particular event while another requires immediate escalation. They may know why a schedule was adjusted, which recent service note changes the meaning of an alert, or what information a provider needs before troubleshooting begins. To the expert, that context can feel obvious. It often never becomes part of a formal handoff.
The result is a building where individual systems are documented but the relationships between those systems are not. A temperature complaint may look like a controls problem but stem from a schedule change made during an occupancy adjustment. A security event may be technically normal, but the team still needs to know who communicates with the tenant. A technically correct response can still fail operationally when communication and ownership are unclear.
That matters because occupants experience delays immediately. They are waiting for a comfortable workspace, a normal entry experience, or a clear answer about what is happening. Even when the eventual technical fix is straightforward, uncertainty can create a poor tenant or workplace experience.
Why Capable People Become Single Points of Failure
Single-person dependency is usually not a personal failure. In many cases, the central person became central because they were capable, committed, and familiar with the building’s history.
During construction, commissioning, or service work, an unusual issue gets resolved. The solution may be explained on a call, recorded in an informal note, or remembered by the person who coordinated the work. The next time a related issue occurs, that same person is contacted because they know the history. It is efficient in the short term. Repeated over time, however, the operating model becomes dependent on an individual rather than a repeatable method.
The appropriate response is not to blame the expert or demand that every detail be documented immediately. It is to give that person time and support to transfer what matters, clarify ownership, and create meaningful backup coverage. A single-person dependency is a design issue in the operating model.
Capture Context Before Preserving a Workaround
Not every historical workaround deserves to become institutional knowledge. Some workarounds may reflect an old condition, an outdated limitation, or a habit that should be retired. But removing a workaround before understanding why it exists can destabilize operations.
A more useful approach follows three steps:
- Capture the reason behind the workaround.
- Validate whether the reason still applies.
- Decide whether the instruction belongs in the operating guide.
This prevents teams from creating a permanent archive of bad habits while still preserving the operational history needed to make safe decisions. The goal is not to copy every old instruction. It is to give the next responsible person enough context to understand the condition, stay within their role, and know who to involve.
Build a Guide for Real Operating Situations
When a knowledge gap becomes visible, organizations sometimes overcorrect. They create a giant binder, a broad shared folder, and a requirement to record every meeting. The effort may be well-intentioned, but it can produce a collection of information that is difficult to use under pressure.
A shorter operating guide can be more valuable when it is organized around real situations. It should help a person answer practical questions quickly:
- What does normal look like for this system?
- What has changed from the original design or normal operating pattern?
- What should be checked first when an alarm or complaint occurs?
- Which system is authoritative for the condition?
- What can this role do safely without additional approval?
- What conditions should trigger an escalation?
- Who communicates with the property team and occupants?
- Who records the decision and confirms service has returned to normal?
The quality test is not whether the team produced more pages. It is whether another responsible person can make the next decision safely.
Test for Readiness, Not Just Access
A practical continuity test begins with one critical system. Ask a direct question: who could operate this tomorrow if the primary expert were unavailable?
The answer should not be “someone can locate the manual.” The person should be able to recognize the condition, take an approved first step, communicate the impact, and escalate appropriately. If the expert says, “I usually just know,” that is a useful signal. The judgment exists, but it is not yet visible enough for a backup to use.
Ask the expert to describe the sequence they follow. What do they verify before acting? Which source do they trust for the current condition? What would make them stop instead of changing a setting? What information would they provide to a specialist? This turns vague expertise into a repeatable decision path.
The communication test is equally important. Who tells the property team? Who contacts affected occupants? Who documents the decision? Who confirms that normal service has returned? A technically sound action can still create operational confusion if these responsibilities are unclear.
Use Scenario-Based Handoffs
A building automation service transition offers a useful example. An incoming technician sees a temperature alarm. The outgoing team knows the alarm often appears after a seasonal schedule change, but the incoming technician interprets it as a possible sensor problem.
Before changing a set point, the incoming team should compare the operating schedule, check the last approved change, review recent service notes, and confirm the escalation path. That sequence is the difference between transferring access and transferring judgment.
Credentials and equipment lists are important, but they do not establish operational readiness on their own. A stronger handoff asks the receiving team to repeat the scenario in its own words. What would it check? What would it document? At what point would it call for help? The handoff is complete when the receiving team can demonstrate understanding, not when a file has been transferred.
Make Continuity Role-Appropriate
The backup person does not need to become an expert in every building system. The realistic standard is role-appropriate readiness. They should be able to recognize normal conditions, take the safe first step, avoid making the situation worse, and bring in the right specialist with useful information.
Planned absences, service transitions, quarterly reviews, and major system updates all provide opportunities to test that readiness. Let the backup person pause. Let them ask basic questions. Avoid stepping in so quickly that the exercise hides the knowledge gap. A short rehearsal may expose an outdated contact, obsolete screen reference, unclear escalation path, or two teams waiting for each other to act.
Improve Continuity Without Expanding Security Risk
Continuity should not mean publishing sensitive layouts, detailed security information, or every system detail to everyone. The objective is to make the right roles ready with the right information while maintaining appropriate access control.
Organizations can document responsibilities, dependencies, approved procedures, and escalation paths while limiting sensitive technical details to authorized personnel. Good continuity reduces operational risk without creating a new security exposure.
Start with One Useful Improvement
A practical first step is simple: choose one critical system, one backup person, and one realistic scenario. Identify where one person is the only reliable path to action. Capture what normal looks like, what has changed, what should be checked first, and when escalation is required. Then let the backup person walk through the scenario.
The best operating day is usually the one nobody notices. Good preparation keeps a routine absence, service change, or difficult alarm from becoming a buildingwide event. For more practical discussion on building technology, operational continuity, and the systems that support commercial properties, listen to this episode of Built, Wired & Secured.