Show Notes
When tacit knowledge becomes the outage
This episode of Built, Wired & Secured opens with a painfully familiar operations problem: a tenant outage drags on because the one piece of documentation that matters is buried in a closeout folder on someone else’s laptop in another time zone. Alex Morgan uses that story to frame the episode’s central idea: Maintenance-as-Code. Instead of relying on tribal knowledge, giant PDFs, and handoffs that fall apart under pressure, the team argues for short, testable runbooks and lightweight automations that make building operations more reliable.
Michael Harrington and James Rogers explain that most failures are not caused by a total absence of documentation. The artifact often exists. The problem is that it fails in the moment of use. It is too long, stored in the wrong place, formatted for project closeout instead of live operations, or understandable only to the person who originally built the system. In practice, that means a thirty-minute fix can become hours of tenant calls, lost productivity, and vendor confusion.
The discussion is especially useful for teams responsible for building systems that are operationally interdependent. As the guests point out, the issue is rarely just one device failing in isolation. The bigger problem is the loss of shared memory about what to check first, what order to follow, and what “back to normal” actually looks like.
What a one-page operational play should include
The strongest practical takeaway in the episode is the structure of a one-page runbook. Rather than writing exhaustive narrative documents, the group recommends a tight operational play with just the information an on-call technician needs during a live issue.
- Trigger: the condition that should start the procedure
- Prerequisites: operating conditions or checks that must be true before acting
- Steps: a short, sequenced list of actions
- Acceptance: measurable criteria that confirm the system has recovered
The example they give is concrete and useful. A trigger could be a chiller fault appearing for two consecutive five-minute polls. Prerequisites might include confirming the building is in occupied mode and verifying the vendor contact. The steps stay simple: check breaker A, cycle control power, and if the fault persists, switch to manual cooling and notify the vendor. Acceptance is not vague. It is defined as the chiller returning to auto and supply temperature stabilizing within fifteen minutes.
They also recommend including one line for rollback and contact information. That discipline matters because it keeps the runbook truly operational. If a new technician can follow it at 2 a.m., the document is doing its job.
Why long handoff documents fail in the field
The episode makes a clear distinction between project documentation and operational documentation. A forty-page closeout PDF may be useful as a historical record, but it is usually the wrong artifact during an incident. In a crisis, teams need speed, clarity, and confidence. They do not need to search through a massive handoff package hoping to find the right paragraph.
That is why Maintenance-as-Code is less about writing more and more about writing for use. The goal is not documentation for documentation’s sake. The goal is operational reliability under stress.
- Store the runbook where operators actually look
- Write for active use, not archival compliance
- Reduce cognitive load during incidents
- Make success criteria measurable, not subjective
How to avoid checkbox maintenance
Alex raises an important objection: do these runbooks just become another checklist exercise? The answer from the field is that they can, unless ownership and feedback are built in from the start.
The guests recommend two simple controls. First, every validation cycle should require one observation note, even if the smoke test passes. That note might capture something small, such as a slow valve response, which then becomes an improvement ticket. Second, the runbook needs a named owner at the role level, not just a department label. Someone must be responsible for running the test, logging outcomes, and driving follow-up actions when issues appear.
They also emphasize rotating who runs the test. If the same person performs every check, the organization recreates the same knowledge bottleneck that caused the problem in the first place. A lead tech, an apprentice, and an on-call team member rotating through the runbook builds redundancy in human memory.
How often should teams test runbooks?
For most systems, the team recommends quarterly smoke tests as a sensible default. More critical systems may need monthly checks. The more important rule is to keep these validations short. If the test takes more than ten minutes, it will eventually get skipped.
That advice is practical because it reflects how real operations teams work. Long maintenance procedures compete with urgent tickets, vendor coordination, and day-to-day support demands. Short tests are more likely to happen consistently, and consistency is what builds confidence over time.
- Quarterly is a good default for many systems
- Monthly may make sense for critical systems
- Keep smoke tests to ten minutes or less
- Failed tests should trigger corrective action, not silent logging
Where automation helps and where it hurts
The automation discussion is balanced and grounded. Michael warns against brittle corrective automations that act without human context. An automated reset may seem efficient until it fires at the wrong time and causes a larger cascade. That is why the recommended starting point is detection automation, not action automation.
The best early use cases are deterministic checks: heartbeats, point reads, alarm counts, and simple drift detection. Automation should identify problems quickly, open the right ticket, and attach the correct runbook. Human operators should still make the judgment call on corrective steps.
The starter automation they recommend is intentionally simple: a daily health check that reads five critical points such as power status, supply temperature, pump run status, controller heartbeat, and alarm count. If any value is out of range, the system should generate a ticket and link the relevant one-page runbook.
That approach delivers value fast because it improves detection without introducing unnecessary complexity. It also reinforces a key theme from the episode: automation should free staff to do better preventative work, not replace operational judgment.
Three steps to start this week
The episode closes with a practical challenge. Teams do not need a massive program to begin. They need one pilot system and a small amount of discipline.
- Pick one failure-prone system and draft a one-page runbook with trigger, prerequisites, steps, and acceptance
- Assign a named owner and run a short pilot smoke test
- Build a simple daily health check that opens a ticket and links the runbook
Just as important, measure what happens on the next incident. If the runbook cuts an hour from recovery time, that metric becomes the evidence leadership needs. As Michael says, small pilots beat big promises.
The bigger lesson
This conversation is really about operational maturity. Quiet reliability does not come from heroic memory or frantic group chats. It comes from small, repeatable practices: clear ownership, short tests, measurable acceptance criteria, and documentation stored where operators actually work.
The closing advice is worth repeating: write the runbook so a new tech can follow it at 2 a.m. If they can, you have probably created something operationally valuable. That is the promise of Maintenance-as-Code. Not complexity for its own sake, but fewer long outages, cleaner handoffs, and building systems that are easier to support when it matters most.
Maintenance-as-Code turns building operations into something teams can actually run
In building operations, a surprising number of outages last longer than they should for one simple reason: the team does not have usable operational guidance when the issue hits. The information may exist somewhere in a closeout package, a commissioning document, or a consultant’s laptop, but that is not the same as having a live, usable operating play.
That is the core problem explored in this episode of Built, Wired & Secured. Alex Morgan talks with Michael Harrington and James Rogers about a practical idea they call Maintenance-as-Code: translating tacit operational knowledge into short, testable runbooks and lightweight automations that reduce downtime, handoff friction, and vendor confusion.
What makes the conversation valuable is how grounded it is. This is not a discussion about building giant knowledge bases or overengineering workflows. It is about getting the right operational knowledge into the right format so a technician can use it under pressure.
The real failure is often operational memory, not the equipment itself
One of the strongest points in the episode is that building technology rarely fails in isolation. A fault in one area quickly turns into an operations problem across vendors, staff, tenants, and support teams. The technical event is only part of the outage. The rest is coordination, interpretation, and recovery.
That is where tacit knowledge becomes dangerous. Someone on the project team used to know the right breaker sequence, the controller behavior, or the exact order of operations. Then they left, changed roles, or became unavailable. The equipment is still there, but the shared operational memory is gone.
When that happens, organizations often discover they do have documentation, but not documentation designed for live operations. A forty-page closeout PDF with the answer buried on page thirty-two is not a practical incident response tool. In real conditions, operators need something faster: the trigger, the prerequisites, the steps, and the acceptance criteria.
Why one-page runbooks work
The episode argues for a very specific artifact: a one-page operational play. This format is intentionally narrow. It is not trying to capture everything about a system. It is trying to capture what an operator needs to do when a known condition appears.
The recommended structure is simple:
- Trigger: what condition starts the procedure
- Prerequisites: what must be verified first
- Steps: the short, sequenced actions to take
- Acceptance: the measurable outcome that confirms recovery
The example from the episode is a good model. A trigger might be a chiller fault that appears across two consecutive five-minute polls. Prerequisites might include confirming occupied mode and verifying the vendor contact. The steps then stay tight and practical: check breaker A, cycle control power, and if the fault remains, move to manual cooling and notify the vendor. Acceptance is specific: the chiller returns to auto and supply temperature stabilizes within fifteen minutes.
That level of specificity matters. In operations, vague language causes delay. “System seems okay” is not a recovery standard. “No active faults for ten minutes” is.
Operational documentation should be designed for use, not storage
One of the episode’s best insights is the distinction between project handoff documentation and operational documentation. Both matter, but they serve different purposes. Project records preserve technical detail. Operational runbooks enable action.
That distinction is where many post-project handoffs break down. Teams receive a complete package, but not a usable one. The handoff satisfies delivery requirements without truly supporting the people responsible for ongoing uptime.
Maintenance-as-Code fixes that by treating operational artifacts as live tools rather than archived files. A runbook is not successful because it exists. It is successful because it is short enough to use, clear enough to follow, and stored where operators actually look during an incident.
How to keep runbooks from becoming checkbox theater
There is a fair criticism of any runbook program: teams can turn it into a compliance exercise. A checklist gets marked complete, no one learns anything, and the document slowly drifts away from reality.
The episode offers a simple answer. Build feedback and ownership into the process.
First, every smoke test should capture one observation note, even when the test passes. That note is where improvement starts. Maybe the valve responded slowly. Maybe a notification lagged. Maybe an operator had to clarify a step. Those observations create the next round of refinement.
Second, assign a named owner by role, not just by department. Someone has to be accountable for running the validation, logging the outcome, and triggering corrective action if the test fails.
Third, rotate who runs the test. If the same person always validates the runbook, the organization is still dependent on one memory holder. Rotating a lead tech, an apprentice, and an on-call team member spreads operational knowledge and builds resilience in the team itself.
Short tests are more likely to survive real operations
The guests recommend quarterly smoke tests as a strong default for most systems, with monthly checks for more critical environments. But the more important design rule is duration. If the test takes longer than ten minutes, it probably will not happen consistently.
That advice is easy to underestimate, but it reflects how operations teams actually work. Busy teams do not ignore maintenance because they do not care. They ignore it when the process is too heavy to fit into a normal week. A short test cadence makes reliability sustainable.
That is an important mindset shift for leadership as well. Reliability programs often fail because they begin with large frameworks instead of small habits. Short, consistent validation beats ambitious programs that no one can maintain.
Where automation creates leverage
The episode is equally practical about automation. The temptation in modern operations is to automate everything, including corrective actions. Michael cautions against that approach. Corrective automation without human context is exactly the kind of “works until it doesn’t” logic that creates brittle systems.
The better place to start is deterministic detection. Automate the checks that are objective and repeatable: heartbeats, alarm counts, point reads, and drift detection. Let automation tell people something is wrong and attach the runbook they need. Let people decide whether and how to act.
The suggested starter automation is a daily health check that reads five critical points:
- Power status
- Supply temperature
- Pump run status
- Controller heartbeat
- Alarm count
If any point is out of range, the system opens a ticket and links the corresponding one-page runbook. That is a strong first step because it improves detection speed without introducing high-risk automated actions.
It also connects documentation and workflow in a useful way. The runbook is no longer a passive file. It becomes part of the response path.
What teams should do first
If your team is trying to improve operational reliability, the episode’s advice is refreshingly simple. Do not begin with a giant initiative. Pilot one system.
Choose a failure-prone asset or process. Draft a one-page runbook. Assign a named owner. Run a ten-minute smoke test. Capture one observation note. Then create a simple daily health check that opens a ticket and links the runbook when a threshold is crossed.
Most important, measure what happens during the next real incident. If that runbook cuts recovery time by an hour, you now have something more persuasive than a strategy deck. You have evidence.
That is the business case embedded in the episode. Better runbooks do not just improve technical neatness. They reduce downtime, lower handoff friction, create cleaner vendor coordination, and give leadership a clearer line of sight into operational performance.
Why this matters beyond maintenance
For organizations responsible for workplace technology and building operations, Maintenance-as-Code is really a discipline of ownership. It forces teams to define what triggers action, who owns follow-up, what success looks like, and where judgment still matters.
That discipline is valuable well beyond a single outage. It strengthens handoffs after projects, improves onboarding for new technicians, and helps operations teams move from reactive heroics to repeatable recovery.
The best line in the episode may be the simplest one: the best day in operations is the one nobody notices. Quiet reliability is the outcome. One-page runbooks, short validation cycles, and low-risk automation are some of the most practical ways to get there.
If you want a grounded example of how operational knowledge becomes a usable maintenance system, this episode is worth a listen. It offers a practical framework that teams can start using immediately without waiting for a major platform rollout or a perfect documentation project. Small discipline really can create big dividends. Listen to the full episode here: https://builtwiredsecured.com/episodes/maintenance-as-code-lightweight-runbooks-building-tech