Show Notes
Episode Overview
In this episode of Built, Wired, and Secured, Alex Morgan and Michael Harrington examine a problem that hides behind a surprising number of outages in multi-tenant buildings: no one has clearly defined ownership of shared infrastructure. The conversation focuses on risers, telecom closets, cabling paths, power feeds, and automation touchpoints that sit between landlords, tenants, contractors, and service providers. The core point is simple: when shared infrastructure fails, the technical issue is often easier to solve than the ownership confusion around it.
The episode opens with a realistic scenario. A contractor working on a fit-out pulls a riser panel inside a telecom closet. Two floors lose phone service, building automation trips, and a point-of-sale system goes dark. Leasing calls facilities, facilities calls IT, and the response stalls because no one knows who owns the riser, which work scope covered the change, or which vendor controls access to the closet. That sets up the larger theme of the episode: unclear governance turns manageable technical failures into expensive operational events.
Why Ownership Gets Fuzzy
Michael identifies three repeatable causes behind ambiguous ownership in shared building systems.
Contract silos: lease agreements, construction scopes, and service contracts are often written by different teams with no single reconciled source of truth for shared assets.
Short-term incentives: during a fit-out, it is faster and cheaper to push responsibility to the other side, with decisions framed as tenant scope or landlord scope and then never revisited.
Documentation decay: drawings, change orders, and access lists end up scattered across different systems, and once vendors leave the site, operational knowledge disappears with them.
Together, those forces create a slow-moving risk that may stay hidden until someone changes a circuit, re-terminates fiber, or accesses a closet without understanding the downstream impact.
A Real Example of Documentation Decay
One anonymized example in the episode makes the risk concrete. A tenant installed a private fiber path from the basement riser to its floor. That path crossed landlord-controlled spaces, but the installation was documented only in the tenant's handover binder. Two years later, a landlord contractor working on a lighting upgrade re-terminated fiber in the same riser and severed the tenant's path. The result was hours of internet downtime, emergency technician work, rerouting efforts, and a tenant retention negotiation.
The lesson is not that private tenant infrastructure is inherently a problem. The lesson is that hidden dependencies inside shared spaces eventually surface as real business interruptions.
Centralized Control vs. Tenant Autonomy
The episode does not argue for a single model in every property. Instead, it lays out a practical trade-off.
Centralized control makes sense when scale, uptime, and standard maintenance boundaries matter most. This is especially relevant in multi-tenant office environments with shared fiber, centralized security, and common service expectations.
Tenant autonomy is valuable when tenants have specialized needs such as unique network topologies, colocation requirements, or specialized automation.
Michael's framework is to lock down the interfaces where failures are most costly while preserving flexibility where problems are easier to remediate. That balance matters because over-centralization can slow tenant innovation, while too much autonomy can create invisible risk inside shared pathways and closets.
Why Handoffs Matter
One of the most practical sections of the episode covers transitional ownership. Shared infrastructure often falls into limbo during fit-outs and contractor-to-operations handoffs. To address that, Michael recommends explicit, time-boxed handoffs in the project plan. His example is a control point at the riser boundary with a named responsible party and a 30-day acceptance window. During that period, the installing contractor remains available to validate connections and documentation. After the window closes, ownership transfers to operations.
That structure matters because accountability should not depend on memory or goodwill. It should be built into the project process before the project closes out.
Two Incident Patterns to Watch
The episode also highlights two anonymized incidents that show how governance failures surface in daily operations.
Security camera outage: a camera feed went dark over a weekend after a contractor temporarily repurposed a riser circuit without updating access lists. Warning signs had existed in advance, including inconsistent closet labeling, multiple vendors carrying separate key sets, and informal workarounds tracked only in email threads.
Building automation faults: a tenant experienced intermittent control issues during peak season because responsibilities were split across shared building automation controllers. Tenant-side logic called vendor-side endpoints, but no one owned end-to-end testing. The warning signs were repeated service tickets bouncing between parties and the absence of a single troubleshooting runbook.
These examples show that governance problems rarely appear out of nowhere. They leave operational signals long before a major outage.
The Four-Pillar Prevention Framework
Michael recommends a 90-minute ownership mapping workshop supported by a four-part checklist.
Asset cataloging: list risers, closets, feeders, and control points, including physical location, patching details, and vendor contacts.
Decision ownership matrix: define who can make changes, who signs off on work, and who responds to emergencies for each asset.
Maintenance boundaries: document who maintains cabling, who owns power feeds, and who handles labeling and access control.
Minimum contractual language: require handoff documentation, test signoffs, and a 30-day acceptance period in fit-out scopes.
The episode notes that these are operational recommendations and that legal teams should review final contract language. That distinction is important: operations can define the needed outcomes, while legal formalizes them.
Three Actions to Take This Week
The episode ends with three immediate documentation tasks that teams can complete right away.
Document the physical path and termination points for every shared riser and closet, even if the first version is only a one-line note.
Document the current contact list for everyone who has keys, credentials, and rack access.
Document existing exceptions and temporary workarounds in one place and assign expiration dates.
Those three actions reduce finger-pointing and speed up remediation when something fails.
Key Takeaway
The central message of the episode is that shared infrastructure does not fail only because of bad hardware or bad installs. It fails expensively when the boundaries of responsibility are unclear. Durable handoffs, visible asset catalogs, and named ownership turn governance from a vague administrative issue into a practical uptime strategy. For anyone managing multi-tenant environments, that is the difference between a quick fix and a prolonged disruption.
Who Owns the Riser? Why Shared Infrastructure Governance Matters
In multi-tenant buildings, some of the most serious operational problems do not begin with failed equipment. They begin with uncertainty. A riser is available to multiple parties. A telecom closet sits behind a locked door, but no one is sure who controls access. A contractor touches cabling that crosses landlord and tenant spaces. A service goes down, and the first hour of response is spent trying to figure out who is actually responsible.
That is the central issue explored in this episode of Built, Wired, and Secured. Alex Morgan speaks with Michael Harrington about the governance of shared infrastructure in multi-tenant buildings, with a focus on risers, closets, power feeds, and automation interfaces. Their message is practical: if ownership of shared systems is unclear, routine building work can trigger outages, delays, cost overruns, and avoidable conflict between teams.
The Hidden Risk Inside Shared Spaces
The episode opens with a scenario that feels uncomfortably realistic. A contractor on a fit-out team pulls a riser panel in a telecom closet. Two floors of tenants lose phone service. Building automation trips. A point-of-sale system goes dark. Leasing calls facilities. Facilities calls IT. Everyone wants to help, but responsibility is fuzzy, and the response slows down before the technical work even begins.
That example captures the core point of the discussion. Shared infrastructure creates shared risk, but it does not always come with shared clarity. In many buildings, the riser path, telecom closet, control panels, and patching environments sit at the intersection of multiple scopes. Landlords, tenants, service providers, low-voltage contractors, and operations teams may all touch the same environment over time. If no one has documented where one party's authority ends and another begins, a simple mistake can expand into a building-wide operational issue.
Why Ownership Breaks Down
Michael points to three recurring causes.
First, contracts are often fragmented. Lease language, construction scopes, and service agreements are created by different teams for different purposes. Each document may make sense on its own, but together they fail to form a single operating picture of shared assets.
Second, short-term incentives drive decisions during build-outs. When timelines are tight, it is easy to classify a task as landlord scope or tenant scope simply to move the project forward. Those decisions may solve an immediate coordination problem, but they often remain untested until a change, outage, or ownership transition exposes the gap.
Third, documentation decays. Drawings, access lists, patching details, change orders, and handover notes get stored in different places. Vendors rotate off site. Internal staff changes roles. Over time, institutional memory fades, and the building keeps operating on assumptions no one has verified in years.
None of those factors sound dramatic in isolation. Together, they create exactly the kind of ambiguity that turns maintenance work into tenant-facing disruption.
When Hidden Dependencies Become Expensive
One anonymized story from the episode makes that risk tangible. A tenant had installed a private fiber path from the basement riser to its floor. The path crossed landlord spaces, but the documentation lived only in the tenant's handover binder. Two years later, a contractor working for the landlord re-terminated fiber in the same riser during a lighting upgrade and cut the tenant's path. The tenant lost internet service for hours. The fix required emergency technician time, rerouting work, and a tenant retention conversation.
The issue was not simply that someone made a technical mistake. The bigger issue was that the building lacked a durable, shared record of what infrastructure existed inside a shared pathway and who needed to be consulted before work was done.
Centralization Is Not Always the Answer
The conversation does not present centralized landlord control as the answer to every problem. Instead, it frames governance as a trade-off.
Centralized control works well when uptime, standardization, and predictable maintenance boundaries are the top priorities. In larger multi-tenant office environments with shared fiber, centralized security, and consistent expectations across floors, centralized oversight can reduce confusion and improve planning.
But tenants do not all have the same technical requirements. Some need specialized automation, unique network designs, or infrastructure flexibility that a standardized model may not support well. In those cases, tenant autonomy has value.
The practical recommendation is to identify the interfaces where failure is most costly and place tighter controls there. If a riser path, closet, or shared controller creates broad downstream impact when touched, its governance should be explicit and durable. Other areas can allow more flexibility when the operational risk is lower or easier to recover from.
The Handoff Problem
One of the strongest points in the episode is that ownership often fails during transitions. A fit-out may be complete from a construction standpoint, but that does not mean operational responsibility has cleanly transferred. Contractors leave. Operations inherits a live environment. Questions remain about labeling, validation, and support obligations.
Michael recommends explicit, time-boxed handoffs. His example is a control point at the riser boundary with a named responsible party and a 30-day acceptance window. During that period, the installing contractor stays on call to validate connections and documentation. After the acceptance window ends, ownership formally moves to operations.
This is a simple idea with major operational value. It prevents assets from sitting in limbo and makes accountability visible at the moment a building is most vulnerable to knowledge loss.
Operational Warning Signs Teams Should Notice Early
The episode also offers a useful way to think about risk before an outage happens. In the two anonymized incidents discussed, the failures were preceded by visible warning signs.
In one case, a security camera feed failed after a contractor temporarily repurposed a riser circuit without updating access lists. In another, a tenant faced intermittent building automation control faults because responsibility was split across shared controllers and no one owned end-to-end testing.
The warning indicators included inconsistent labeling, multiple vendors holding separate keys, recurring workarounds buried in email threads, tickets bouncing back and forth between parties, and the lack of a single troubleshooting runbook. These are governance signals as much as technical signals. They suggest that the building may be running on habits and assumptions instead of documented operating boundaries.
A Practical Framework for Building Teams
Rather than stopping at diagnosis, the episode gives a simple framework that teams can act on immediately. Michael recommends a 90-minute ownership mapping workshop anchored by four pillars.
The first is asset cataloging: identify risers, closets, feeders, and control points, along with physical location, patching details, and vendor contacts.
The second is a decision ownership matrix: define who can make changes, who approves work, and who owns emergency response for each asset.
The third is maintenance boundaries: clarify who maintains cabling, who owns power feeds, and who handles labeling and access control.
The fourth is minimum contractual language: require handoff documentation, test signoffs, and a 30-day acceptance period in fit-out scopes.
This framework is practical because it does not require a perfect records system to begin. It requires teams to make implicit assumptions visible, then assign names and boundaries before the next project or outage forces the issue.
Three Immediate Actions
If a full governance overhaul feels too large to start this quarter, the episode narrows the next step to three pieces of documentation that teams can create this week.
First, document the physical path and termination points for each shared riser and closet, even if the first draft is basic.
Second, document who currently has keys, credentials, and rack access.
Third, document existing exceptions and temporary workarounds in one location and give them expiration dates.
These are not glamorous tasks, but they directly reduce response friction when something breaks.
Why This Matters Beyond Infrastructure
The broader lesson from the episode is that building technology governance is not just about technical neatness. It affects tenant uptime, response speed, vendor coordination, and planning. When responsibilities survive staff turnover, vendor changes, and contract transitions, operations become more predictable. When they do not, the same building can look stable on the surface while carrying unresolved coordination risk underneath.
If your team manages multi-tenant environments, this episode offers a useful lens: do not wait for a major outage to discover that no one owns the interface that failed. Map it now, assign it now, and document it now.
For a deeper walkthrough, listen to the full episode and use the checklist ideas discussed in the conversation to review your own shared infrastructure boundaries.