Who's Responsible? Building a Living Tech Ownership Map

When a small failure becomes everyone’s problem

The episode opens in a scene that feels familiar to anyone responsible for building operations: the security desk goes quiet, lobby badge readers go dark, the line at the front desk grows, and nobody can tell the receptionist who to call. That is the moment this conversation is built around. Alex Morgan and Michael Harrington use that scenario to explain why many incidents drag on far longer than they should. The technical fault may be small, but the operational damage multiplies when ownership is unclear.

Michael frames the issue with a simple question: what breaks if this goes down? In the lobby example, the answer is immediate. People cannot get in, tenant operations stall, and the front desk turns into a crisis hub. He shares a striking contrast from experience: a repair that should have taken about 90 minutes can spiral into 48 hours of chaos when teams do not know who owns what.

The three failure modes behind slow response

A major theme in the episode is that long outages are rarely caused by one dramatic technical issue. More often, they come from ordinary gaps in process and documentation. Michael breaks the problem into three practical failure modes:

• Undocumented handoffs after projects close
• Gray-area responsibilities between facilities and IT
• Changes that never make it back into documentation

Those blind spots are what make incidents expensive. A project may end with an email or handshake, but if no one updates the system record, the asset effectively becomes ownerless. The same thing happens when power, cabling, and edge devices sit between departments. In an outage, each team can honestly believe the issue belongs to someone else. Add in vendor swaps, panel moves, or tenant installations that never get documented, and teams lose precious hours just trying to understand the environment.

A practical example: the added card reader

One of the clearest examples in the episode is a card reader added during renovations. The installer wires it and assumes facilities will cover power. Facilities assumes it owns the network side. No one adds the device to the asset register. Later, when the reader fails, the response turns into finger-pointing. Each team says it is outside their scope, and the vendor contract is hard to find. That back-and-forth damages both response time and credibility.

The point is not that people are careless. It is that undocumented assumptions create operational risk. Tenants do not care which team believes it owns the issue. They care whether they can get in and get to work.

Why overengineering makes the problem worse

Alex challenges Michael on the idea of keeping the map simple. Some teams ask for highly detailed maps, down to ports. Michael’s answer is balanced: if there is a specific reason to go that deep for high-risk assets, do it. But for most environments, excessive granularity creates a maintenance burden that teams will not sustain.

His argument is memorable: a 500-column spreadsheet that never gets updated is worse than a short, accurate map. Instead of trying to document everything at the same level, he recommends practical tiers:

• Critical service owners
• System owners
• Vendor contacts

The key questions are operational, not academic: who responds in the first hour, who owns remediation, and who owns capital replacement? That keeps effort aligned with risk.

The minimum viable ownership map

For teams that want to start immediately, Michael lays out a minimum viable approach. He says the map should answer the first three questions people ask during an outage: what, who, and who next?

• 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 within the documented window

If the service is outsourced, add a short vendor note. That is enough to make the document useful in the moment that matters.

He then gives a concrete badge reader example:

• Asset: lobby badge reader, with ID and rack location
• Owner: security team, with primary contact and on-call rotation
• Escalation: network team after 30 minutes for link issues
• Vendor: hardware vendor after 90 minutes
• Dependency note: PoE from switch 3B, with a 4-hour truck roll SLA

With just those lines, the front desk knows who to call, internal teams know when to step in, and the vendor knows its response window.

Use timing windows that reflect business impact

The episode also explains that escalation windows should not be fixed across every asset. They should be tiered by criticality. Life safety and access control deserve tighter windows. Non-critical systems such as digital signage can have wider ones.

The goal is to document timing that matches real tenant impact and contract constraints. By putting those expectations directly into the map, teams avoid confusion during incidents and reduce the emotional debate that often replaces decision-making when a service is down.

How to keep the map current without creating bureaucracy

The cultural challenge is not building the map. It is keeping it current. Michael’s advice is to make it part of the operating rhythm, not a separate admin task.

He recommends a simple structure:

• A one-page view for critical systems
• A deeper register for less-used detail
• Ownership tied to incident reviews and capital planning

This is where accountability matters. If an owner repeatedly fails to update entries, that gap should appear in the next review. More importantly, it should affect budget prioritization. In other words, make the consequence real. If missing updates influence planning and spending decisions, the documentation becomes a live operating tool instead of a stale file.

Two stories that show what works and what fails

The episode closes the framework with two short examples.

In the positive case, a suburban office building created a one-page critical asset map for access control, HVAC cores, and network systems. When an HVAC controller failed on a Friday afternoon, the team had the owner and vendor immediately. Repair time dropped from what could have become a prolonged disruption to under three hours, and tenants barely noticed.

In the cautionary case, a healthcare campus had a large, polished register that looked excellent on paper but had not been updated. During a failure, teams trusted the document and missed a recent vendor change. The result was false confidence and eight hours of downtime.

That contrast reinforces the episode’s central lesson: accuracy matters more than volume.

Three actions to take this week

Michael leaves listeners with a short starter plan:

• 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 each entry to a sentence
• Add a 15-minute quarterly ownership review to the change control meeting

He also warns teams what to avoid: do not overengineer, do not use ownership as a dodge, and never rely on memory alone.

The episode notes that a one-page ownership map template is available on the show site to help teams run that first sweep. The invitation is practical: download it, run the exercise, and share what you learn.

This is a useful episode for operators, facilities leaders, IT teams, and property stakeholders who want faster repairs, fewer tenant disputes, and clearer capital planning. The message is simple and operationally grounded: keep the map visible, keep it small, and connect it to outcomes.

Why technology failures last longer than they should

Many building incidents do not become expensive because the root cause is especially complex. They become expensive because the first ten minutes are wasted on a basic question: who owns this system?

That is the core problem explored in this episode of Built, Wired, and Secured. Alex Morgan and Michael Harrington start with a clear operational scenario. The security desk goes quiet. Badge readers in the lobby are dark. The queue at the front desk doubles. The receptionist cannot get a clear answer on who to call. Vendors are on hold. Managers start pacing. Hours slip by while people look at each other.

It is a vivid example because it captures the real cost of unclear ownership. The technical issue might be limited to one device or one dependency, but the business impact spreads immediately. Access slows. Tenant operations stall. The front desk becomes a crisis hub. What should have been a contained repair starts affecting trust, workflow, and the perception of control inside the building.

As Michael explains, he always starts with the same question: what breaks if this goes down? That framing matters because it forces teams to think beyond the asset itself and focus on downstream impact. In the lobby case, the impact is immediate and public. That is why unclear ownership can turn what might have been a planned 90-minute fix into 48 hours of chaos.

The hidden reasons incidents drag on

One of the strengths of this conversation is that it avoids abstract governance language and gets practical quickly. Michael identifies three failure modes that repeatedly slow response and create unnecessary downtime.

The first is undocumented handoffs. A project ends, an email is sent, or a conversation happens in the field, but nobody updates the official record. The asset is technically live, yet operationally invisible.

The second is responsibility living in gray areas between departments. Facilities may own one part of a system, IT another, and neither side may have a complete picture of power, cabling, or edge devices. During normal operations, that ambiguity can stay hidden. During an incident, it becomes the main problem.

The third is undocumented change. Vendors get replaced. Panels get moved. Tenants install equipment. Network dependencies shift. If those changes do not make it back into documentation, response teams start with bad assumptions.

That combination is what creates long delays. Before anyone can fix the issue, they have to reconstruct reality.

The card reader example shows how small gaps become big delays

A particularly useful example in the episode is a card reader added during renovations. The installer wires it and assumes facilities will own power. Facilities believes it will own the network side. No one creates a clean asset register entry. Later, the reader fails.

At that point, each team can say the same thing: not my scope. The vendor contract is hard to find. No one is wrong in a narrow sense, but the organization still loses time. And tenants do not experience that as a documentation gap. They experience it as an operational failure.

This is an important distinction. Ownership maps are not about making spreadsheets look better. They are about reducing the delay between detection and action.

Why a smaller map often performs better

Alex presses on a common objection: should teams document everything in extreme detail, even down to ports? Michael’s answer is practical rather than ideological. If a specific asset carries enough risk to justify that level of detail, document it. But do not impose that level of detail on the entire environment by default.

The risk with overengineering is simple. The more fields and columns a system requires, the less likely it is to stay current. A large ownership spreadsheet can become impressive but unusable. Michael puts it bluntly: a 500-column spreadsheet that never gets updated is worse than a short, accurate map.

That idea is central to the episode. Accuracy beats exhaustiveness. A lean document that people trust during an outage is more valuable than a large document no one can maintain.

Instead of aiming for uniform depth everywhere, he recommends practical tiers. Start by identifying critical service owners, system owners, and vendor contacts. Then ask three operational questions: who responds in the first hour, who owns remediation, and who owns capital replacement? That structure keeps the work aligned with actual risk and actual response needs.

What to include in a minimum viable ownership map

For teams that want a lightweight starting point, the episode lays out a minimum viable ownership map. It is intentionally simple. Every entry should answer the first questions people ask when a service fails: what is it, who owns it, and who is next if the first person cannot resolve it?

The core fields are straightforward:

• Asset identity, including what it is and where it sits
• Owner, team, and primary contact for first response
• Escalation path if the issue is not resolved inside the documented window

If the asset is outsourced, add a short vendor note. That is enough to make the map useful without turning it into a documentation project that never ends.

The badge reader example from the episode makes this concrete. A useful entry would identify the lobby badge reader, note its ID and rack location, assign it to the security team, list a primary contact and on-call rotation, escalate to the network team after 30 minutes for link issues, and escalate to the hardware vendor after 90 minutes. It would also note that the device receives PoE from switch 3B and that the vendor SLA is a four-hour truck roll.

That is not a giant system. It is a short operational guide. And in a live incident, that is exactly what teams need.

Escalation windows should reflect tenant impact

Another practical point from the episode is that not every asset deserves the same response clock. Escalation windows should be tiered by criticality. Access control and life safety systems need tighter windows because the operational and tenant impact is immediate. Digital signage or a non-critical display can tolerate a wider response window.

This sounds obvious, but documenting it matters. During incidents, teams often default to assumptions or debate. By defining escalation windows ahead of time, the organization makes expectations explicit. That helps internal teams coordinate faster and prevents conflict with vendors whose contract terms may shape what is realistically possible.

Put simply, the ownership map is not just a contact list. It is a way to operationalize response expectations.

How to keep the map alive without adding bureaucracy

The hardest part of any documentation effort is maintenance. Michael addresses that directly by arguing that ownership mapping should become part of the normal operating rhythm, not a separate administrative burden.

He recommends maintaining a one-page view for critical systems and a deeper register for less-used details. That way the most important information stays visible and usable, while secondary detail remains available without cluttering the first-response view.

More importantly, he ties ownership updates to existing business rhythms: incident reviews and capital planning. If a documented owner repeatedly misses updates, that should show up in the next review. If the organization wants the map to remain real, missing updates must have consequences that matter. In the episode, Michael points to budget prioritization as one of those consequences.

That is a smart operational move. It prevents ownership documentation from becoming a compliance exercise and turns it into something linked to funding, planning, and accountability.

Two stories that underline the difference

The episode offers two short stories that show why this approach works.

In one suburban office building, the team created a one-page critical asset map covering access control, HVAC cores, and network systems. When an HVAC controller failed on a Friday afternoon, the team immediately knew the owner and vendor. Repair time came in at under three hours, and tenants barely noticed.

In contrast, a healthcare campus had a large register that looked polished but had not been updated. During a failure, teams trusted it and missed a recent vendor change. The result was eight hours of downtime caused not by lack of documentation, but by misplaced confidence in stale documentation.

That contrast says a lot. The goal is not to produce more pages. The goal is to produce a reliable operating reference.

A simple three-step plan to start this week

The episode ends with a practical starter plan any team can adopt.

• Run a 30-minute sweep with facilities, IT, and security to identify the top 20 critical assets and assign owners
• For each asset, add an escalation window and a vendor contact, keeping each entry to a sentence
• Add a 15-minute quarterly ownership review to the change control meeting

Just as important are the warnings. Do not overengineer. Do not let ownership become a way for teams to dodge responsibility. And never rely solely on memory, especially in environments where vendors, equipment, and tenant needs change over time.

The episode also notes that a one-page ownership map template is available on the show site, making it easy for teams to run that first sweep and start with something practical.

Listen for the operating lesson, not just the template

The real value of this conversation is not the form itself. It is the operating mindset behind it. Buildings and business environments become more resilient when the path from incident to action is short, visible, and trusted.

A living technology ownership map does not need to be large to be effective. It needs to be current, visible, and tied to outcomes. Faster fixes, fewer tenant disputes, and clearer capital planning all start from that same discipline.

If your team has ever lost time asking who owns a failing system, this episode is worth a listen. It offers a practical way to reduce confusion without creating more process than the organization will actually maintain. Listen to the full episode here: https://builtwiredsecured.com/episodes/living-tech-ownership-map-building-operations