Show Notes
When a Small Failure Becomes Everyone’s Problem
The episode opens on a scene that will feel familiar to anyone responsible for building operations: the security desk goes quiet, badge readers in the lobby go dark, the front desk line grows, and no one can tell the receptionist who to call. What should have been a contained system issue quickly turns into a building-wide operational problem.
That opening frames the central point of this conversation: many incidents last far longer than they should because ownership is unclear. Instead of moving directly into diagnosis and repair, teams lose time figuring out scope, responsibility, vendor contracts, and escalation paths. In the example discussed here, that confusion can stretch a fix from a planned 90 minutes into 48 hours of chaos.
This episode focuses on a practical answer to that problem: a living technology ownership map. Rather than building a giant documentation project, the goal is to create a lightweight, current reference that tells teams what the asset is, who owns first response, and who comes next if the issue is not resolved quickly.
The Three Failure Modes That Slow Everything Down
Michael Harrington breaks the problem into three practical failure modes that repeatedly show up during incidents:
- Undocumented handoffs after project work closes
- Responsibilities that sit in the gray area between facilities and IT
- Changes that never make it back into documentation
That framework is one of the strongest parts of the episode because it moves the conversation away from abstract “communication problems” and toward specific operational gaps.
The first issue, undocumented handoffs, happens when a project ends with an email, a verbal assumption, or a handshake, but the underlying ownership information never gets updated. The system may be installed and working, but the operational record is incomplete from day one.
The second issue is the gray area between teams. Power, cabling, edge devices, and related infrastructure often sit between departments. Facilities may assume IT owns part of it. IT may assume facilities owns it. During an outage, that ambiguity becomes visible immediately.
The third issue is silent change. Vendors change, panels move, tenant installs get added, and no one updates the record. The system in the field no longer matches the documentation teams trust.
Together, those three failures create delay, finger-pointing, and false confidence.
A Simple Example: The Added Card Reader
To make the issue concrete, the conversation uses a straightforward example: a card reader added during renovations. The installer wires it and assumes facilities will cover power. Facilities assumes it will own the network side. No entry gets added to the asset register. Later, when the reader fails, every team’s first reaction is the same: it is not clearly in their scope, and the vendor contract is not easy to find.
That short example explains why tenants and front desk staff often experience outages very differently than technical teams do. Tenants do not care which team owns power, network, or hardware. They care that they cannot get in and that no one seems ready to respond. The cost is not just downtime. It is lost credibility.
Why Overengineering Backfires
One of the most useful tensions in the episode is the challenge around granularity. Some teams want deep spreadsheet detail, potentially down to ports. Michael’s argument is not that detail is bad. It is that detail becomes harmful when it creates a maintenance burden so heavy that no one keeps the document current.
His warning is clear: a 500-column spreadsheet that is never updated is worse than a short, accurate map.
That does not mean teams should ignore high-risk systems. The recommendation is to use practical tiers. If there is a real reason to map to a lower level of detail for a specific asset, do it there. But for most environments, the ownership map should stay focused on what matters operationally during the first hour of an incident:
- Critical service owners
- System owners
- Vendor contacts
The key questions are simple: who responds first, who owns remediation, and who owns capital replacement? That framing keeps effort aligned to risk instead of turning documentation into bureaucracy.
The Minimum Viable Ownership Map
For teams that want to start small, the episode gives a minimum viable structure. Each entry should contain:
- Asset identity: what it is and where it sits
- Owner, team, and primary contact for first response
- Escalation path if the primary cannot fix it in the documented window
- A short vendor note if support is outsourced
That is intentionally lean. It answers the first three questions people ask in an outage: what is it, who owns it, and who is next?
The badge reader example makes this especially clear. An entry could include the lobby badge reader, its ID and rack location, the security team as owner, a primary contact with cell number and on-call rotation, a network escalation after 30 minutes for link issues, and a hardware vendor escalation after 90 minutes. Add a short note that power comes from switch 3B via PoE and that the vendor SLA is a four-hour truck roll, and the front desk now has something operationally useful.
That kind of clarity does not eliminate every outage, but it sharply reduces the time spent guessing.
Tiered Escalation Beats One-Size-Fits-All Rules
Another practical point in the conversation is how to set escalation windows. The answer is not to apply the same timing everywhere. Windows should be tiered by criticality.
Life safety and access control should have tighter response expectations than non-critical displays or signage. The map should reflect tenant impact and contract reality so teams are not improvising expectations during a live incident.
That matters because escalation is not just a list of names. It is a timing decision. If the map documents when the next team or vendor takes over, incident response becomes more predictable and less emotional.
How to Keep the Map Current Without Creating Busywork
The cultural challenge is maintenance. Most teams do not want another administrative obligation. The episode’s answer is to stop treating the map as a separate chore and instead tie it to operating rhythm.
The suggested approach is to maintain a one-page view for critical systems and a deeper register for less-used details. Ownership updates should be tied to incident reviews and capital planning. If an owner repeatedly misses updates, that should surface in the next review and influence budget prioritization.
That is an important insight: documentation stays live when accountability is tied to outcomes. If missing updates affect incident response and budgeting, teams have a reason to keep the map current.
Two Short Stories, Two Very Different Outcomes
The episode closes the case with two contrasting examples. In one suburban office building, a one-page critical asset map covered access control, HVAC cores, and network. When an HVAC controller failed on a Friday afternoon, the team had the right owner and vendor immediately. Repair time dropped from 48 hours to under three hours, and tenants barely noticed.
The cautionary example is just as strong. A healthcare campus had a large register that looked excellent on paper, but it had not been updated. During a failure, teams trusted it, missed a recent vendor change, and lost eight hours of downtime because the document created false confidence.
The lesson is straightforward: smaller and current beats bigger and stale.
Three Starter Actions for This Week
The episode ends with three immediate actions listeners can take:
- Run a 30-minute sweep with facilities, IT, and security to list the top 20 critical assets and assign owners
- For each asset, add an escalation window and a vendor contact, keeping entries to a sentence
- Add a 15-minute quarterly ownership review to the change control meeting
It also offers a final warning: do not overengineer, do not let ownership become a dodge, and never rely solely on memory. Document the critical few, keep the map visible, and connect it to real operational outcomes. Faster fixes, fewer tenant disputes, and clearer capital planning are not byproducts. They are the reason the map matters.
Why Unclear Ownership Turns Minor Building Failures Into Major Operational Problems
A building incident does not always begin with a dramatic systems failure. Sometimes it starts with silence.
In this episode of Built, Wired & Secured, the opening scene is immediate and practical: the security desk goes quiet, the badge readers in the lobby go dark, the queue at the front desk doubles, and no one can tell the receptionist who to call. Vendors are on hold. Managers are pacing. Hours pass while people look at one another.
That image captures a truth many property teams, facilities leaders, and technology stakeholders already know: the hardest part of some incidents is not the technical repair. It is the confusion around ownership.
When no one is clear on who owns a system, who responds first, or when a vendor should be engaged, a contained problem can turn into a building-wide disruption. This conversation with Michael Harrington lays out a practical solution: a living technology ownership map that is lightweight enough to maintain and useful enough to matter when things break.
The Real Cost of Ownership Confusion
One of the most striking points in the episode is how quickly uncertainty adds time. In the lobby access-control scenario, a repair that should have taken around 90 minutes can stretch into 48 hours of chaos. That is not because the hardware suddenly became more complex. It is because teams lose time locating responsibility, checking assumptions, reviewing contracts, and navigating gray areas between internal teams and outside vendors.
That delay creates several kinds of impact at once. Tenant operations stall. Front desk staff become the de facto crisis center. Managers get pulled into escalation. Vendors lose time waiting for direction. And the organization starts paying in credibility as well as downtime.
The core message is simple: tenants do not care which team believes a device falls into its scope. They care that the issue is resolved quickly and competently.
The Three Failure Modes Behind Long Incidents
Michael organizes the problem into three practical failure modes, and that structure gives the episode much of its value.
The first is undocumented handoffs. Project work gets completed, but the operational ownership does not get formally updated. A system may be installed, accepted, and live, yet no one has clearly recorded who owns response, maintenance, or replacement.
The second is the gray area between facilities and IT. This is where many issues live: power, cabling, edge devices, and systems that touch both physical and digital infrastructure. Each team may hold part of the answer, but if the boundaries are not explicit, response slows down when the incident starts.
The third is documentation drift. Vendors change. Panel locations move. Tenants add systems. Equipment gets swapped. If those changes never make it back into the record, teams go into an outage trusting information that is no longer true.
That final point matters because stale documentation is not neutral. It can be worse than no documentation at all if it gives teams false confidence.
A Better Way to Think About Documentation
The episode pushes back on the idea that better ownership always means more detail. Some organizations react to past failures by trying to document everything in exhaustive spreadsheets. On paper, that sounds responsible. In practice, it can create an asset nobody maintains.
Michael’s warning is memorable: a 500-column spreadsheet that is never updated is worse than a short, accurate map.
This is not an argument against detail where detail is warranted. If a specific high-risk system justifies deeper technical mapping, then map it at that level. But the episode argues for practical tiers instead of total coverage by default. Documentation should match operational risk.
The most important ownership questions are not endless. They are direct:
- Who responds in the first hour?
- Who owns remediation?
- Who owns capital replacement?
If the document cannot answer those questions quickly, it is not doing the job it was created to do.
What a Minimum Viable Ownership Map Should Include
For teams starting from scratch, the episode offers a deliberately lean framework. Each critical asset entry should include four things:
- What the asset is and where it sits
- The owner, team, and primary contact for first response
- The escalation path if the issue is not resolved within the documented window
- A short vendor note if outside support is involved
That structure is useful because it mirrors what people actually need during an outage. What is failing? Who owns the first call? Who is next if this does not get fixed in time?
The badge reader example makes the framework tangible. An entry might list the lobby badge reader, the asset ID, and rack location. It would name the security team as owner and include a primary contact with cell number and on-call rotation. It would also state that the network team gets involved after 30 minutes for link issues, while the hardware vendor gets escalated after 90 minutes. A short note that the reader receives PoE from switch 3B and that the vendor SLA is a four-hour truck roll gives everyone involved a realistic operating picture.
That is not overbuilt documentation. It is focused, actionable context.
Escalation Windows Should Reflect Business Impact
Another valuable point in the episode is that escalation timing should not be uniform. Critical systems need tighter windows than lower-impact systems.
Life safety and access control deserve a different response expectation than digital signage or non-critical displays. The point is not just to set a timer. It is to make expectations explicit before an incident starts. If tenant impact is high, the map should show that. If a vendor contract limits response options, the map should show that too.
When teams document timing up front, they reduce the friction that usually comes from mid-incident debate. Instead of arguing over whether the next team should already be engaged, people can follow the agreed operating model.
How to Keep the Map Alive
The hardest part of any ownership map is not creating it. It is keeping it current without creating another administrative burden that gets ignored.
The lean answer in this episode is to make ownership maintenance part of existing operating rhythm. Maintain a one-page view for critical systems and keep deeper details in a broader register. Then connect updates to the places where consequences already exist: incident reviews and capital planning.
That accountability matters. If owners repeatedly fail to update entries, that gap should show up in review cycles and budget conversations. Documentation becomes real when missing updates have real operational consequences.
This is one of the strongest management insights in the conversation. The map should not survive on goodwill alone. It should live where operational and financial decisions already happen.
Why Current Beats Comprehensive
The episode reinforces its argument with two contrasting stories.
In one suburban office building, the team created a one-page critical asset map covering access control, HVAC cores, and network. Later, when an HVAC controller failed on a Friday afternoon, the owner and vendor were identified immediately. What could have become a long, tenant-visible disruption was repaired in under three hours. Tenants barely noticed.
The cautionary story comes from a healthcare campus that had the opposite problem. Its register looked complete and professional, but it had not been updated. During a failure, teams relied on it, missed a recent vendor change, and lost eight hours of downtime because the document was wrong when it mattered most.
The takeaway is clear: comprehensive documentation is only valuable if it remains trustworthy. A smaller map that stays current can outperform a larger system that drifts out of sync with the real environment.
A Three-Step Starter Plan
For listeners who want to act quickly, the episode closes with three simple moves that can happen this week.
First, run a 30-minute sweep with facilities, IT, and security to identify the top 20 critical assets and assign owners. The point is not to solve the entire estate. It is to document the systems whose failure would immediately affect operations.
Second, add an escalation window and vendor contact to each of those entries. Keep each line short. A sentence is enough if it tells teams when to escalate and who to call.
Third, add a 15-minute quarterly ownership review to the existing change control meeting. This is what turns the map from a one-time exercise into a living tool.
The warnings are just as useful as the action items. Do not overengineer the fields. Do not let “ownership” become a way for teams to avoid responsibility. And do not rely on memory when the stakes are operational.
The Bigger Operational Payoff
What makes this episode practical is that it never treats documentation as an end in itself. The ownership map matters because it changes outcomes. It cuts incident time, reduces tenant disputes, and makes capital planning clearer. It gives the front desk an answer. It gives technical teams a path. It gives managers something better than guesswork during a live problem.
Most importantly, it reframes ownership from a background administrative exercise into a visible operating control. When the map is small, current, and tied to consequences, it stops being shelfware.
That is the real lesson here. If a building depends on systems that cross facilities, IT, security, and vendors, then ownership clarity is not optional. It is part of uptime.
If this episode’s opening scenario sounds familiar, it may be time to start with the critical few: identify the asset, name the owner, define the next call, and keep that record live. Then listen to the episode for the full conversation and use it as a prompt to run your own first sweep.