Category: ReliabilityX Blog

This is the third post in a series on corporate functional teams that operate with indirect influence over the operating sites. The centers of excellence, governance functions, and operational support teams that develop standards and best practices and rely on the sites to actually adopt them. 

The first post diagnosed the failure pattern, compliance theater driven by a default push model. The second post argued that the most counterintuitive rule for these teams is your peer group is not your working group, and your real customer is site leadership rather than the SME you work with day-to-day. 

This third post is the practical playbook. How do you actually build a pull system? What are the operating mechanisms that make it work? 

The Pull Process Flow 

Start with the core process. In a pull system, the sequence is fundamentally different from the standard top-down rollout. Here’s what it looks like in operation: 

Step 1: Sites assess against business outcomes. Not against your standard, against the outcomes their site leadership is accountable for. Production. Safety. Quality. Cost. Risk exposure. Whatever the site’s actual scorecard is. 

Step 2: Sites identify gaps. Where are they falling short of their outcome targets? Which gaps are biggest? Which are most consequential? 

Step 3: Sites prioritize. Out of the universe of gaps, which ones are they actually committing to close in the next year? This is the site’s plan, not the corporate team’s. 

Step 4: Sites engage corporate to close the gap. Now and only now does the corporate team enter the picture. The site says, “We’ve identified this gap. We need a process, a tool, a methodology, or a standard to help us close it. Do you have one? If yes, can we use it? If no, can we work together to develop one?” 

Step 5: Corporate determines if standardization is appropriate. Not every gap requires a standard. Some are local issues with local solutions. Some require methodology that’s already documented. Some genuinely require a new corporate standard because the gap will recur across sites. 

Step 6: If standardization is needed, develop with the community. This is where the corporate team’s value-add lives. They convene a community of excellence, corporate SMEs plus site representatives to develop or update the standard. The site that identified the gap is in the room. So are sites with related challenges. 

Step 7: Sites implement to close their gap. Adoption isn’t an end in itself. The standard is a tool the site is using to close a gap they identified. Adoption follows naturally because the site needs the result. 

Notice what’s different. The trigger isn’t “corporate has issued a standard, sites must adopt.” The trigger is “a site has a gap, and corporate has a resource that can help close it.” The standard exists in service of the site’s outcome, not the other way around. 

Knowing What to Standardize and What Not To 

One of the most underappreciated parts of this model is knowing what to standardize and what not to. Every gap identified by a site shouldn’t trigger a corporate standard. If your team is in the standards business and standards are your only deliverable, every problem starts to look like a standardization problem. 

Develop a decision tree. The criteria typically include: 

• Recurrence. Will this gap appear at multiple sites? If it’s idiosyncratic to one site’s local conditions, a standard is overkill. That site needs a custom solution. 

• Risk. Does the gap relate to safety, regulatory compliance, or material business risk? If yes, standardization is more justifiable even at lower recurrence. 

• Variability cost. Is there a meaningful cost to having different sites solve the same problem differently? Sometimes yes (interoperability, shared services, central reporting); sometimes no. 

• Maturity. Is the best practice well enough understood to be codified? Premature standards lock in suboptimal approaches. 

If the decision tree says “yes, standardize,” the corporate team and the community of excellence develop the document. If the answer is “no,” the corporate team can still be useful by sharing what other sites have done, connecting the site to peers solving similar problems, or providing guidance but a formal standard isn’t the deliverable. 

This discipline saves the corporate team from generating standards that nobody needs. It positions them as a team that knows when not to standardize, which paradoxically increases the credibility of the standards they do produce. 

The Governance Charter 

A pull system requires a written agreement between the corporate team and the sites about how the relationship works. I call this a governance charter. It’s a negotiated document not a corporate-issued one that establishes: 

• The corporate team’s purpose, scope, and standards-development process 

• The site’s responsibilities in the relationship,  gap identification, plan development, engagement with the community of excellence 

• The cadence of meetings and reviews 

• The metrics that will be used to assess the relationship’s effectiveness 

• The escalation path when commitments are missed on either side 

The act of writing the charter is itself a forcing function. When you sit down with site leaders to negotiate this, you discover what they’re actually willing to commit to, what they expect from you, and where the misalignments are. The conversation alone is often more valuable than most adoption initiatives the team has ever launched. 

The charter also makes the relationship symmetric. It’s not a list of demands on the sites; it’s a list of mutual commitments. That symmetry is what makes the pull system actually pull. 

The Site-Led Governance Review Meeting 

The single highest-leverage operating mechanism in a pull system is the site-led monthly governance review meeting. 

Most corporate teams run their site interactions backward. The corporate team owns the agenda. The corporate team asks questions. The sites answer. The corporate team checks compliance. The meeting is, in effect, an audit by another name. 

Flip it. 

In a site-led review, the site presents. The agenda belongs to them. They walk the corporate team and the other sites through their progress against their own annual plan, gaps identified, actions taken, results achieved, challenges remaining. The corporate team’s role is to listen, ask clarifying questions, and provide reinforcement when sites are doing well. 

Run one site per meeting on a rotating cadence. By the end of the year, every site has presented at least once, and most have presented several times. 

Two dynamics emerge from this format: 

Dynamic 1: Positive Competition. When one site presents impressive results, the other sites in the room notice. They start asking themselves and each other “How are they doing that?” The next site to present typically steps up its game. Over time, you create a friendly competitive culture across the network. That competitive energy is something a corporate team can never manufacture by issuing standards. It only emerges when sites are presenting to each other. 

Dynamic 2: Visible Reinforcement. Every time a site presents, the corporate team has the opportunity to publicly recognize what’s working. Find reasons to commend them for the rigor of their analysis, for the courage to share an honest setback, for the engagement they brought to a recent community-of-excellence working group. Public reinforcement, repeated over time, reshapes behavior more powerfully than audit-and-escalate ever will. 

The meeting is not a corporate-driven status update. It’s a peer-to-peer learning forum the corporate team facilitates. 

The One-Issue-Per-Site Discipline 

Here’s a tactical mechanism that turns the pull system from a quarterly cadence into a continuous relationship: at any given time, every site should have at least one open issue that the corporate team is helping them solve. 

Whatever the issue is a standard being developed, a gap analysis underway, a tool being piloted, a methodology being adapted, the site has corporate engagement on something they actually want help with. When that issue is resolved, the site brings forward another. The relationship is always live. 

This serves two purposes. 

First, it keeps the corporate team in problem-solving mode, which is the rebrand the entire pull system depends on. As long as you’re working real problems for real sites, you’re useful — which is the only thing that earns you the right to issue standards in the first place. 

Second, it gives the corporate team a clean metric to report up the management chain: how many sites are actively engaged with our team on an issue right now? Of those engagements, how many resulted in measurable progress? That metric is far more meaningful than “standards issued” or “audits completed.” It tells you whether the team is actually being pulled in by the sites which is the entire goal. 

If a site has no open issues with your team, that’s a signal. Either they don’t have any active gaps in your domain (rare), or they’re not engaging with you (more likely). Either way, it’s worth a conversation with site leadership about why. Frame it carefully: most sites complain that they don’t have enough resources to deliver on corporate expectations. The metric of “are sites taking advantage of the resources available to them?” turns that complaint back on itself. If there’s a corporate resource available and the site isn’t using it, that’s a different conversation than “we’re under-resourced.” 

Measuring What Matters 

The measurement shift is one of the hardest changes for corporate teams to make. Most teams measure activity: 

• Standards issued 

• Plans submitted 

• Audits completed 

• Findings closed 

• Meetings held 

These metrics tell you whether the corporate team is busy. They tell you nothing about whether the sites are getting better. 

In a pull system, you measure two things: outcomes and behaviors. 

Outcome metrics track whether the sites are actually improving in your domain. If your team is responsible for reliability, you measure unplanned downtime, mean time between failures, PM compliance trends. If it’s quality, defect rates and SOP adherence. If it’s safety, recordables, near-misses, and procedural compliance. The corporate team’s effectiveness is judged by whether the sites collectively are getting better, not by whether the team is busy. 

Behavior metrics track whether the relationship is functioning as a pull system: 

• How many sites engaged the team for help in the last quarter? 

• How many open issues are the team currently working with sites? 

• How active is site participation in the community of excellence? 

• What’s the response cadence when sites reach out? 

• Are sites bringing new gaps forward proactively, or only when prompted? 

These metrics, taken together, tell you whether the corporate team has earned a real seat at the site’s table which is the precondition for everything else. 

The Rebrand: From Auditor to SME Hub 

If the corporate team has historically been seen as an auditing body, the shift to a pull system requires a deliberate rebrand. Sites won’t pull from a team they’ve learned to avoid. The team has to make itself visibly available and useful before sites will engage. 

Two concrete moves: 

Build a capabilities handbook. Create a directory of every SME on the team, bios, areas of expertise, the kinds of problems they’ve helped solve. Publish it on a SharePoint or internal portal where site leaders can browse it. The message: here’s what we know how to do; reach out when one of these is the gap you’re trying to close. 

Ask the question. In every meeting with a site leader, end with a version of: “What’s one thing our team could do differently, starting next week, that would make you more likely to call us for support when you have a gap?” Listen to the answer. Act on it. The fastest way to be more useful is to ask the people you’re trying to serve what useful looks like to them. 

The rebrand isn’t a poster or a new tagline. It’s the accumulated effect of a hundred small interactions where the team showed up as a resource rather than as a regulator. 

Accountability Still Exists 

A pull system is not a permission slip for sites to ignore corporate work. Accountability still lives in the system; it just lives in the right place. 

When a site’s plan isn’t producing the results they committed to, governance has a responsibility to say so clearly. Not punitively, but accurately. “Site X committed to closing this gap by Q2. The gap is not closed. Here’s the current status, and here’s what support has been offered.” That’s an honest report, and it belongs in the conversation between your management chain and theirs. 

The key is that escalation comes after genuine support, not instead of it. The corporate team’s first move when a site is struggling is to offer help, not to escalate. Only if the help is rejected and the commitment is repeatedly missed does escalation become the right move. And even then, the conversation is at the leadership level, not the SME level because the principle from the second post in this series still applies. 

Accountability that flows through site-owned commitments and corporate-supported execution is durable. Accountability imposed by external mandate is theatrical, and it always reverts to compliance behaviors over time. 

A Pull System Has to Be Earned 

A pull system can’t be manufactured. It can’t be declared by a memo or rolled out as an initiative. It has to be earned, one problem solved at a time, one site relationship at a time, one piece of helpful work at a time. 

The good news is that it can be earned. Sites are not actually hostile to corporate teams. They’re hostile to corporate teams that show up as additive work without offering anything in return. When a corporate team shows up as a resource, visibly useful, actually solving problems, accepting prioritization decisions, working at the right peer level, the relationship inverts. Sites start calling. Standards start getting adopted. Outcomes start moving. 

If you’ve read this series and recognized your own team in the diagnosis, the path forward is concrete. Start with a few small moves. A charter conversation with one site, a site-led review meeting in place of a corporate-led one, an open-issue mechanism with a single pilot site, a capabilities handbook posted on the portal. Earn a few wins. Build credibility. The pull system grows from there. 

The push model is the default. The pull model is the discipline. Most corporate teams fail because they never make the switch. The ones that do make it become the kind of corporate function that operating sites actually want to work with and that, more than anything else, is what determines whether the team’s work has any real impact at the end of the year. 

This is the second in a three-part series on how corporate teams without direct authority over the operating sites can actually succeed in driving adoption and change. The first post diagnosed the failure mode; compliance theater driven by a default push model. This post tackles the single most counterintuitive principle for corporate teams trying to escape that pattern. 

Of all the rules I share with corporate functional leaders trying to influence sites without authority over them, this one gets the most pushback in the room and delivers the most value when actually applied: 

Your peer group is not your working group. 

Most corporate teams get this exactly wrong, and the misalignment is invisible to them until someone calls it out. Once you see it, you can’t unsee it. 

The Mistake 

Here’s how it almost always plays out. 

A corporate team is developing a standard, a maintenance and reliability standard, an EHS standard, a quality SOP, an IT governance document, anything that requires technical accuracy and site adoption. To validate the standard’s technical content, the team identifies a subject-matter expert at each site. The site SME reviews drafts, provides input, signs off when the document is technically correct. 

So far, so good. SME involvement in standards development is right. The mistake comes after the standard is published. 

The corporate team continues working with the same SME. They follow up on adoption progress with the SME. They escalate when adoption stalls to the SME. They send reminders to the SME. They build their dashboards around what the SME is doing or not doing. The SME becomes the corporate team’s day-to-day point of contact for everything related to that standard. 

This feels right. It feels efficient. The SME is the person who understands the technical content; surely they’re the right person to drive it forward. And if the standard isn’t being adopted, it must be the SME’s fault for not pushing harder. 

It’s wrong. And it’s the single biggest reason corporate teams burn out trying to drive change at the site level. 

Why Working at the SME Level Doesn’t Work 

The SME at the site is not your peer. They don’t report to you. You don’t report to them. They have a day job that has nothing to do with your standard, assigned by a manager who has nothing to do with your standard. Their authority to allocate resources at the site is limited or nonexistent. 

When you push them on adoption, you’re asking them to do something they can’t actually deliver on their own. They can’t reassign techs to your initiative. They can’t reorder the site’s project priorities. They can’t pull capital out of one bucket to fund the work your standard requires. Those decisions belong to the site leadership. 

So when adoption stalls, the SME has two options. Option one: tell you the truth that the standard is fifteenth on the site’s priority list and won’t get worked until next year. That’s a hard conversation, and most SMEs don’t have the political room to have it. Option two: say something vague about timing and resources and quietly hope you stop calling. 

Option two wins almost every time. Which is why corporate teams who work at the SME level spend their days chasing ghosts. 

You’re not building accountability when you push the SME. You’re building avoidance. And you’re misallocating your own time, because the conversation that actually changes anything isn’t happening with the SME, it’s happening at the site leadership level, in rooms you’re not in. 

The Boulder Uphill 

I describe working at the SME level as pushing a boulder uphill. It feels productive, there’s motion, you’re talking to someone, the SME is nodding along but the boulder is heavy and the slope is steep, and the moment you stop pushing, it rolls back down. 

Why? Because the SME has no leverage. Even when they want to help you, they don’t control the priorities. Their manager does. The site leader does. The local leadership team does. So whatever momentum you build with the SME evaporates the moment they walk into a meeting with their boss to talk about the actual operational priorities. 

You can spend a career pushing this boulder. Many corporate teams do. They burn out, they get cynical about the sites, they conclude that the sites are uncooperative or undisciplined or unwilling to follow standards. None of that is the diagnosis. The diagnosis is that they’re working at the wrong level. 

The Real Peer Group 

Your peer group, as a corporate functional leader, is the site leadership. The plant manager, the operations director, the site general manager, whatever the title is in your organization. That’s the person who controls priorities, resourcing, and adoption sequencing. That’s the person who, when they decide to allocate resources to your standard, makes adoption actually happen. 

Your job isn’t to convince the SME to push harder. Your job is to be useful enough at the site leadership level that when site leadership prioritizes their twelve competing initiatives, your work makes the cut. 

This is a fundamentally different conversation than the one you’re having with the SME. It’s strategic. It’s about business outcomes the site leader is accountable for, not technical specifications the SME signed off on. It’s about how your standard helps the site hit their numbers, production, safety, quality, cost but not about whether it’s been incorporated into local documentation. 

When you have that conversation with the right person, two things happen. Either site leadership says, “Yes, this is a priority, and here’s what we’ll commit to,” and adoption follows naturally. Or they say, “I hear you. We have twelve initiatives competing for resources right now, and your work is twelfth on the list.” Either answer is useful. Both are honest. Both let you stop pushing the boulder. 

The Discipline of Being Twelfth on the List 

Here’s the part that’s hard to accept: when site leadership tells you you’re twelfth on their list, the right response is to accept it. 

I know that’s hard. You spent six months developing the standard. You believe in its importance. You can articulate why it matters. And being told it’s twelfth feels like being told it doesn’t matter at all. 

But the discipline is to accept the prioritization, report your status accurately, and keep showing up. Don’t escalate around the site leader. Don’t try to leverage your management chain to override their priorities. Don’t pivot back to working at the SME level because you can’t get traction at the leadership level. None of that helps. 

What helps is to keep reporting. “Standard X is at twelfth priority at Site Y; estimated adoption window is Q3 next year.” Keep doing that month after month. Eventually one of three things happens: 

1. The site leader’s priorities shift naturally and your standard moves up the list as resources free up. 

1. Your management chain decides the prioritization is wrong and engages with theirs to renegotiate it. That’s a leadership-to-leadership conversation, and it gets handled at the right level. 

1. The standard remains low priority indefinitely because the site has bigger problems to solve. That’s also a valid outcome and it tells you something about whether your standard was actually solving the most important problems. 

In all three cases, you’ve stayed in your lane, maintained credibility with the site leader, and avoided burning your relationship by pushing on someone who didn’t have the authority to act anyway. 

There’s also a competitive consideration here. If your team is one of many corporate teams pushing standards at the same sites and most teams are, you’re sharing a finite pool of local resources with the other corporate functions. Trying to force your standard up the priority list ahead of someone else’s doesn’t actually help your team. It just trades short-term adoption of your work for long-term resentment from the site. Accepting the priority list is the discipline that lets the network of corporate teams collectively succeed instead of cannibalizing each other. 

The Asset-Centric Reframe 

Underneath this principle is a deeper reality about how operating companies work. The company buys assets to add value. Production lines, processing units, distribution networks, IT infrastructure — whatever the assets are, that’s where money is made. The people who operate and maintain those assets are the ones generating value. Everyone else in the company is a support function whose job is to help those frontline people get more value from the assets. 

That includes corporate teams. 

If a corporate team isn’t visibly helping the sites get more value from their assets. Fewer breakdowns, less waste, lower risk, faster throughput, better quality, that team is optional. It might not feel optional from inside the team. The work feels important, the standards feel necessary, the governance feels real. But from the site’s vantage point, if you’re not making them better at running their assets, you’re overhead. 

This is a hard truth, and it’s the one that makes the peer group principle actually land. The reason your peer is the site leader, not the SME, is because the site leader is accountable for getting value from the assets. They’re the customer your team exists to serve. The SME is a contributor to your work product; the site leader is the recipient of it. You serve the recipient, not the contributor. 

When corporate teams internalize this, the dynamic changes. They stop trying to enforce adoption and start trying to be useful. They stop tracking SME compliance and start tracking site outcomes. They stop pushing boulders and start solving problems. 

What This Looks Like in Practice 

A few concrete behavioral shifts to apply this principle: 

• Identify your peer group explicitly. Make a list of the site leaders for every site your team supports. That’s who you’re really working for. The SMEs are colleagues, not customers. 

• Cadence with site leadership matters more than cadence with SMEs. Build a regular touchpoint with site leadership. Quarterly business review, monthly check-in, whatever fits the rhythm. That’s the venue where your work actually moves. 

• Talk in business outcomes, not standards. When you’re with site leadership, stop talking about whether the standard has been adopted. Start talking about what the standard is helping them solve, the safety incident rate, the unplanned downtime, the quality defect rate. Outcomes are their language. 

• Accept the priority list. Whatever ranking your standard gets, accept it. Report against it. Don’t try to renegotiate it through informal channels or by pressuring people who don’t have authority. 

• Move escalation to the right level. If a standard genuinely needs to move up the list, that conversation happens between your management chain and theirs but not between you and the SME. 

The Permission to Stop Pushing 

If there’s one outcome, I want corporate teams to take from this principle, it’s the permission to stop pushing the boulder. You’re not lazy when you accept that you’re twelfth on the list. You’re not failing when you decline to escalate around a site leader. You’re being honest about where the authority actually lives, and you’re saving your team’s energy for the work that genuinely moves the needle and being useful at the site leadership level. 

Corporate teams that learn this principle become dramatically more effective. They stop chasing accountability that isn’t theirs to enforce. They stop building dashboards that track activities instead of outcomes. They stop burning out trying to drive change through the wrong people. As a side effect, the relationship with the sites improves because the sites stop feeling pushed. 

Your peer group is the site leader. The working group is just the team that helps build the work product. Don’t confuse the two, and don’t try to manage one as if they were the other. 

The next post in this series gets into the practical mechanisms. The operating cadence, the measurement framework, and the rebrand from auditor to problem-solver, that turn this principle into a functioning system. 

Large operating companies have a corporate team. Sometimes called operations support, technical excellence, a center of excellence, or a governance function whose job is to develop standards, best practices, and governance documentation for the sites that report up through the organization. The team writes the standards. The sites are expected to adopt them. Audits or self-assessments confirm compliance. The cycle repeats. 

If you’ve worked in or led one of these teams, you’ve watched the cycle break down in roughly the same way every time. The standards are technically excellent. The intent is right. The work that goes into them is real. But adoption is theatrical. Plants submit improvement plans on time. Boxes get checked. Audits pass. And on the ground, almost nothing actually changes. 

This is compliance theater, and it’s the default state of nearly every centrally governed corporate function I’ve encountered. This post is the diagnosis: why it happens, and what the root cause actually is. 

The Default Push Model 

Most corporate teams operate on what I call the push model. It looks like this: 

• Corporate develops a standard, often with limited input from the sites. 

• The standard is published with an expectation of adoption. 

• Sites are required to incorporate it into their local documentation. 

• Adoption is verified through audits or self-assessments. 

• Nonconformance findings trigger increased audit frequency, escalation, or corrective action plans. 

On paper, this looks like rigorous governance. In practice, it produces three predictable failure modes. 

Failure Mode 1: Orphaned Standards. The document gets written, signed off, published and then sits. Technically accurate, formally adopted, but never actually implemented in any meaningful way. The site has its own priorities, its own competing initiatives, its own resource constraints. The standard is real on paper and invisible in operations. 

Failure Mode 2: Compliance Theater. Improvement plans are submitted on schedule, but the plans reflect what governance wants to hear, not what’s actually happening at the plant. Sites become expert at managing the audit, not at adopting the standard. The improvement plan is a deliverable to the corporate team, not a roadmap for the site. 

Failure Mode 3: The Auditing Spiral. When a nonconformance event happens, the corporate response is to audit more frequently. More pressure. More documentation. More attention from the central team. The site sees this as additional burden, punishment, even rather than support. The relationship becomes adversarial. Adoption gets even harder. 

These three failure modes compound. Over time, the corporate team is perceived as something to be avoided, managed, or worked around. Not as a resource that helps the site succeed. 

The Underlying Perception Problem 

Step into the shoes of a site leader for a moment. You have a P&L to run, production targets to hit, a workforce to manage, safety incidents to respond to, regulatory obligations to satisfy, capital projects to deliver, and your own continuous improvement initiatives in flight. You are constantly competing for finite resources: time, money, people, attention. 

Now corporate hands you a new standard. From their seat, this is the obvious next priority. From your seat, it’s one more demand on a stack that was already overflowing. 

If you don’t see how the standard helps you hit your numbers, it’s additive. And additive work, by definition, gets pushed to the bottom of the list. 

This is the perception problem at the heart of every failed corporate initiative. Corporate teams that are perceived as additive will be avoided. It doesn’t matter how good the standard is, how much technical work went into it, or how clearly leadership communicated the expectation. If the site doesn’t see the corporate team as a force multiplier on their own goals, the standard will not be adopted in any meaningful way. It will be tolerated. 

The default push model practically guarantees this perception. The standard arrives without context. The audit shows up to verify compliance. The escalation happens when compliance falls short. From the site’s vantage point, every interaction with corporate is something being done to them, never for them. 

Compounding the problem: most large operating companies have multiple corporate teams pushing standards at the same sites simultaneously. Operations support, EHS, quality, IT governance, compliance, supply chain, sustainability; they all report to different corporate executives, all develop their own standards, and all believe theirs is the obvious priority. From the site’s seat, they’re not facing one corporate team’s expectations. They’re facing twelve. And often the same site SME is the touchpoint for several of those teams. Each corporate team is competing knowingly or not for the same finite local capacity. 

The Reframe: Push vs. Pull 

The fix isn’t a better standard, a better audit, or a better escalation process. The fix is a fundamentally different operating model. One where the corporate team is pulled in by the sites because they’re useful, instead of pushing standards that the sites resist. 

In a push system, the optimization is for the corporate team. Activities are the metric, standards issued, plans submitted, audits completed. Sites are the recipients of governance. Adoption is mandated. The relationship is adversarial because the incentives are misaligned. 

In a pull system, the optimization is for the receiver. Outcomes are the metric, site performance, gap closure, business results. Sites are co-owners of the governance. Standards exist because they solve real problems the sites need solved. Corporate is a resource that gets called in because it’s helpful not avoided because it’s additive. 

The shift is philosophical before it’s procedural. It changes who the corporate team is for. In a push model, corporate exists to enforce standards on the sites. In a pull model, corporate exists to help the sites get more value from their assets. 

The North Pole Analogy 

Here’s the way I describe the difference to corporate teams trying to make this transition. 

Imagine you’re sending someone on an expedition to the North Pole. 

The push approach sounds like this: “Here’s exactly how you’re going to get to the North Pole. Here are the steps. Here’s the timeline. Here’s the gear list. We’ll be auditing along the way — checking how much water you drank, whether you wore your hiking boots, whether you turned left when we said to turn left. Don’t deviate from the plan.” 

That’s how most corporate standards land at the site level. Prescriptive. Auditable. Disconnected from the conditions actually being faced. 

The pull approach sounds different: “Here’s what the North Pole looks like, and why getting there matters to the company. Tell us where you currently are — we don’t know your terrain, you do. As you encounter challenges, we have resources to help. When you hit the desert, we’ve already designed the canteen for that. When you hit the mountains, we have a guide who’s been there. If you encounter something we don’t have a resource for yet, work with us to develop one — because the next site facing the same challenge will benefit from what you’ve built.” 

In the second approach, corporate sets the destination and provides standardized solutions for known terrain. The site owns the route, the pace, and the day-to-day execution. The relationship is one of mutual usefulness, not enforcement. 

Shared Ownership of the Outcome 

Here’s the move that makes the pull model work: shared ownership of the outcome. 

Under a push model, corporate owns the standard and the site owns the adoption. They’re separate ownerships, and they often have separate incentives. Corporate gets credit for issuing the document. The site gets credit (or blame) for adopting it. Neither feels accountable for whether the underlying business problem was actually solved. 

Under a pull model, both parties own the outcome together. Corporate owns the development of the standard, the curation of best practices across the network, and the removal of systemic barriers. The site owns the gap analysis, the implementation plan, and the actual results. But they share accountability for whether the result was achieved. 

This sounds like a small distinction. It is not. It changes every conversation that follows. When both sides own the outcome, the standard isn’t a deliverable. It’s a tool both parties are using to solve a real problem. The standard exists because the site needs it, not because corporate wrote it. 

What Comes Next 

This is the diagnosis. Compliance theater is the symptom. The push model is the disease. A pull system is the cure. 

Making that shift is harder than it sounds. It requires changing who the corporate team is talking to (and who they’re not), how progress gets measured, what gets standardized and what doesn’t, and how the corporate function rebrands itself in the eyes of the sites. 

Two principles in particular deserve their own treatment, and the next two posts in this series go after them: 

• The most counterintuitive rule for corporate teams trying to operate without direct authority, the principle that your peer group is not your working group and what that means in practice. 

• The practical mechanisms of a pull system, governance charters, site-led review meetings, the one-issue-per-site discipline, and the measurement shift from compliance to behaviors and outcomes. 

If you’re running a corporate team that’s struggling to drive change at the site level, the answer isn’t more pressure. It’s a different operating model. Start by recognizing the pattern in your own organization. Compliance theater is rarely intentional, but it’s almost always the default. Naming it is the first step toward replacing it with something that actually works. 

The Problem

The Little Potato Company’s Multivac production line in Edmonton, Alberta was operating far below its intended capability. What should have been a stable, high‑performing asset had become a bottleneck. Equipment was not running at design rate, minor defects were compounding into major losses, and operators did not have the tools or training to identify issues before they escalated. The line was experiencing chronic downtime, inconsistent performance, and rising operational costs.

These issues were not isolated. They were symptoms of deeper systemic problems. Variability in equipment condition, lack of standardized operating practices, and limited workforce capability were creating a cycle of firefighting instead of controlled, predictable production. Leadership recognized that without a structured, reliability‑driven intervention, the plant would continue to fall short of customer demand while absorbing unnecessary cost.

The goal was clear. Restore throughput. Reduce waste. Build a workforce capable of sustaining long‑term reliability. Do it in a way that created measurable financial impact.

The Solution

We partnered with The Little Potato Company to deliver a comprehensive, hands‑on transformation of the Multivac line. Our approach was designed to stabilize the equipment, strengthen the workforce, and eliminate the operational barriers that were limiting performance.

Our strategy included:

-Conducting a full mechanical and operational assessment to uncover hidden defects, process losses, and sources of variability that were driving downtime and inefficiency.
-Executing targeted cleaning and restoration events to return equipment to optimal operating condition and eliminate the chronic issues that had become normalized.
-Delivering specialized training that equipped operators and technicians to identify, troubleshoot, and resolve issues at the source instead of relying on reactive maintenance.
-Implementing center lining and operational standards that locked in consistency, reduced drift, and created predictable, repeatable performance.
-Coaching leaders and frontline teams to reinforce reliable behaviors, maintain process control, and sustain improvements long after the engagement ended.

This was a structured reliability intervention that combined technical precision with cultural alignment. The plant gained not only restored equipment performance but also a workforce that understood how to maintain and grow that performance every day.

The Results

The improvements were immediate, measurable, and financially significant. The Multivac line shifted from a chronic constraint to a reliable, high‑performing asset.

-Throughput increased by 56%, expanding annual capacity from 4 million to 10.5 million units
-Yield improved by 10%, generating $377,000 in savings
-Labor savings totaled $417,000 through improved flow and reduced intervention
-Material waste was reduced by 58%
-Cost of Goods Sold per unit decreased by $0.17

These results were not temporary. They were the outcome of restored equipment, standardized processes, and a workforce capable of sustaining reliability. The Little Potato Company now operates with greater efficiency, lower cost, and a stronger foundation for future growth.

Conclusion

We helped The Little Potato Company transform a struggling production line into a stable, predictable, and profitable operation. By restoring equipment condition, elevating workforce capability, and implementing operational standards, we delivered sustainable results that continue to scale across the facility.

If your plant is experiencing throughput loss, rising costs, chronic downtime, or instability on critical equipment, you do not have to accept those conditions as normal. A structured reliability approach can change the trajectory of your performance.

Schedule a free consultation and see what ReliabilityX can unlock for your operation.

Talk to anyone who has worked in a manufacturing plant for any length of time, and they’ll tell you the same thing: when the line goes down, somebody’s looking at the maintenance team. The OEE dashboard lights up, the availability number drops, and the natural reflex of operations leadership is to walk over to the maintenance shop and ask what happened.

That is why I call the availability bucket of OEE the maintenance blame bucket. It is the loss category most people instinctively assign to maintenance, and it is the one your maintenance organization gets held accountable for in most plants.

Here is the problem with that reflex: a substantial portion of what is actually living in the availability bucket does not belong to maintenance at all. If you do not understand what is really inside that bucket and how to measure it, you will spend your career defending a number you do not fully control.

Let us break it open.

Three Losses Live Inside Availability

OEE, Overall Equipment Effectiveness, has three buckets: availability, performance, and quality. We are focused on availability today.

Inside availability, there are three distinct loss types. They get lumped together into a single percentage on the dashboard, although they have very different causes and very different owners. Knowing the difference between them is the entire game.

Loss One: Breakdowns

A breakdown is the textbook maintenance loss. The clean definition:

A stop of 10 minutes or more, where a part is replaced.

That is the standard. Both conditions need to be true. A two-minute glitch is not a breakdown. A long stop where nothing was replaced is not a breakdown either. We will get to that one in a second.

There is a small edge case worth mentioning. If a wire gets frayed, you cut it back, strip it, and reuse the same wire, that can still count as a breakdown depending on how strict your definition is. The spirit of the metric is whether the asset suffered a physical failure that required intervention, and a reused wire after damage typically does. The bright-line rule for most plants is simple: 10 minutes or more, and a part replaced.

This bucket is squarely in maintenance’s lane. If the breakdown number is bad, your maintenance organization needs to look hard at PM strategy, precision craft, lubrication, alignment, and predictive coverage. Own that one.

Loss Two: Process Failures

This is where the conversation with operations gets interesting. The definition:

A stop of 10 minutes or more, where no part is replaced.

That second condition matters. If maintenance got called, walked out to the line, looked at the asset, and walked away without replacing anything, that probably was not a maintenance issue.

A few classic examples:

Somebody bumped the e-stop and could not figure it out. Eventually they call maintenance. Maintenance walks over, looks at the panel, resets the e-stop, and walks back to the shop. That is not a maintenance failure. That is a process failure.

Materials were not staged properly. The line was supposed to be running, although the operator did not have what they needed and spent twenty minutes hunting it down. Process failure.

The operator was not trained on a basic recovery procedure. A condition that an operator on a well-run line would resolve in two minutes consumed thirty minutes of maintenance time because the operator did not know what to look at. Process failure.

These are not maintenance issues. They are standards issues. Training issues. Line readiness issues. Operations own them.

Here is the catch: if you do not measure them separately, they all look like the same thing. The line was down, where was maintenance.

Loss Three: Setup and Adjustment

The third loss is the most often overlooked:

Anything that exceeds the standard for a changeover.

If operations are given a 10-minute standard for a changeover and it takes 15, that is a 5-minute setup and adjustment loss. Multiply that by every changeover in a week and you will find a quietly enormous number of available production hours bleeding away.

Setup and adjustment are operations’ loss to own. It is about SMED practices, changeover procedures, training, parts kits, and fixturing. It is not about the maintenance department.

The CMMS Move That Proves Out Process Failures

Here is the move that turns this from a definition into a defensible business conversation.

The biggest lever you have to recover unfair credit in the availability bucket is proving out how often maintenance is being called to handle process failures. There is a clean way to do that inside your CMMS:

Pull every work order written against a given production line over a defined period. A quarter is a good window.

Filter for work orders where no parts were issued and no materials were charged.

Look at the labor hours on those work orders.

That bucket, labor hours spent on the line with no parts replaced, is your process failure response time. It is maintenance hours burned on issues that were not maintenance issues.

Now you can walk into a meeting with operations leadership with something concrete:

“Last quarter, my team responded to 312 calls on Line 4. On 187 of them, 60 percent, no parts were replaced. That is roughly 240 maintenance labor hours spent on issues that were not maintenance failures. Every one of those calls also represented production time lost while the line was down waiting on us. We need to fix the line standards, not the maintenance program.”

That is a fundamentally different conversation than saying you need more maintenance people.

Why You Have to Track Everything as a Work Order

This entire technique depends on one upstream discipline: every maintenance touch on the line has to be a work order.

I see this constantly. A maintenance tech walks out to the line, fixes a five-minute problem, walks back, and never writes it up because it was just a quick one. Multiply that by every tech, every shift, every day, and you have an invisible mountain of process-failure response that never shows up in your data.

Without the work order, you have no record. Without the record, you have no conversation. Operations can keep blaming maintenance for the availability number because maintenance has no evidence to push back with.

Make it a non-negotiable. Every interaction with the line gets a work order. Every time. Even the quick ones, especially the quick ones, because those are the process failures you are trying to surface.

Arm Yourself With Knowledge, Then Partner

Here is the bigger point underneath all of this. The goal of breaking apart the availability bucket is not to dump the blame on operations. The goal is to partner with operations to solve the right problems.

When you can show operations leadership that 60 percent of your line calls were process failures, that operations was bleeding production time and burning maintenance hours on issues that better standards or better training would have eliminated, you are not making them defensive. You are handing them a roadmap to recover capacity. That is a gift.

The conversation shifts from asking why maintenance is so bad to asking how both sides can stop wasting capacity on preventable losses. Operations gets back production hours. Maintenance gets back labor hours to spend on actual reliability work. The plant gets a lower cost per unit. Everyone wins.

None of this happens without the data. The data does not exist without the discipline to write the work order, define the loss buckets correctly, and have the conversation with structure.

The Tip in Practice

Three concrete moves to take this from a blog post into a Monday-morning action:

Make your loss definitions crisp. Breakdowns equal 10 minutes and a part replaced. Process failures equal 10 minutes, no part replaced. Setup and adjustment equal anything exceeding the changeover standard. Print them and post them in both the maintenance shop and the operations break room.

Enforce the work order discipline. Every line interaction gets written up, no exceptions. The quick fixes are the data you need most.

Run the CMMS query. Pull a quarter of work orders at your worst-performing line, filter to no parts replaced, and quantify the process failure response. Bring the number to your next operations review.

The maintenance blame bucket is not going to fix itself. Once you understand what it is actually inside, you can start having a very different conversation about who owns what and how to recover the capacity that is quietly leaking out of every shift.

If you want support turning this approach into a repeatable process in your plant, connect with us. Our team can help you put the right structure in place.

One challenge has quietly grown into a full‑scale operational threat: the widening skill gap. Plants are onboarding new technicians who lack foundational mechanical aptitude, while experienced employees retire faster than organizations can replace them. The result is a workforce that is eager but underprepared, and a leadership team that is stretched thin trying to compensate for inconsistent skills on the floor.

This is not a theoretical problem. It shows up every day in the form of preventable downtime, repeat failures, reactive work, and frustrated teams who want to do the job well but were never given the tools or training to get there. Many manufacturers are feeling the pressure as they try to maintain production targets with a workforce that has uneven capability and limited exposure to modern maintenance practices.

Skill Gaps Are Now a Direct Threat to Reliability

Most plants are experiencing the same pattern. New hires arrive with limited hands‑on experience, and even seasoned employees often lack exposure to precision maintenance, structured troubleshooting, or reliability fundamentals. Supervisors spend more time coaching basic tasks than leading improvement. Planners struggle to build accurate job plans because the work varies depending on who performs it. Operators rely on tribal knowledge that disappears the moment someone retires.

This skill gap creates a ripple effect across the entire operation:

• Work quality becomes inconsistent
• PMs are completed but not effective
• Root cause analysis stalls because the team lacks the technical depth to identify true failure mechanisms
• Equipment health declines
• Production loses confidence in maintenance
• Leadership loses visibility into what is actually happening on the floor

The most painful part is that none of this is due to lack of effort. It is a capability problem, not a motivation problem. Teams want to perform at a high level. They simply have not been trained in a way that matches the complexity of the assets they are responsible for.

Build Capability Before You Build Expectations

Manufacturers often try to solve performance issues by adding more metrics, more accountability, or more urgency. But none of that works if the team does not have the skills required to meet those expectations. The most effective path forward is to build capability first.

A practical starting point is to evaluate three areas:

1. Skill clarity
   Define the skills required for each role and compare them to the skills your team currently has. Most organizations discover gaps they did not know existed.
2. Technical depth
   Prioritize training that improves troubleshooting, precision maintenance, and reliability fundamentals. Compliance training alone will not close the gap.
3. Consistency of practice
   Standardize how work is performed so that quality does not depend on who is on shift that day.

When capability improves, everything else becomes easier. Work quality stabilizes. PMs become meaningful. RCA becomes faster and more accurate. Supervisors can lead instead of firefight. Production sees the difference immediately.

Our Maintenance and Reliability Best Practices Framework was built to solve this exact problem. It gives manufacturers a structured, proven approach to developing a skilled, consistent, reliability‑focused workforce.

The framework covers the full spectrum of maintenance excellence, including:

• Work management
• PM optimization
• Precision maintenance
• Asset strategy development
• Troubleshooting and defect elimination
• Operator care
• Planning and scheduling
• MRO and storeroom management
• Reliability leadership and decision making

Each building block reinforces the others. When teams understand how their daily work connects to asset health, production stability, and long‑term reliability, performance improves quickly and sustainably.

What Happens When Skill Gaps Are Closed

One food manufacturer we worked with saw a 40 percent reduction in unplanned downtime within six months after implementing structured training aligned with their asset needs. Another facility reduced repeat failures by more than half simply by teaching technicians how to perform precision alignment and lubrication correctly. These improvements did not come from new equipment or major capital projects. They came from building capability and giving teams the knowledge to execute work the right way every time.

When people understand what good looks like, they deliver it.

On‑Site Training Tailored to Your Facility

Every plant has different equipment, different challenges, and different levels of experience on the floor. That is why our training is delivered on site and tailored to your operation. We focus on the skills your team needs most and build capability in a way that fits your environment, your assets, and your goals.

Schedule Training at Your Facility

If you want to strengthen your workforce, improve reliability, and close the skill gaps that are holding your plant back, we can help. Contact us to schedule on‑site training at your facility and start building a more capable, consistent, and confident maintenance organization.

Many maintenance teams work incredibly hard yet still feel like they are losing ground. They complete PMs, respond to breakdowns, and support production, but failures continue. Backlogs grow. Costs rise. Morale drops.

This happens because maintenance is not a list of tasks. It is a system. And when one part of the system is weak, the entire system suffers.

Consider a plant where technicians perform lubrication routes faithfully. They hit every point. They follow the intervals. They use the correct lubricant. Yet bearings still fail. Why? Because no one identified the failure modes. The lubrication tasks were not addressing contamination, misalignment, or over‑greasing. The work was being done, but it was not solving the problem.

Or a facility where operators are not involved in basic care. They walk past leaks, vibration, and abnormal sounds because they assume maintenance will catch it. By the time maintenance sees the issue, the failure is already in motion. The system is missing early detection.

Or a site that measures PM completion but not PM effectiveness. The numbers look good, but the equipment still fails. The metric is being met, but the purpose is not. The system is missing feedback.

Chapter 3 pushes organizations to understand maintenance as a connected system that includes:
• failure mode identification
• task alignment
• operator involvement
• planning and scheduling
• precision execution
• measurement and feedback
• continuous improvement

When one of these elements is missing, the system becomes reactive.
When all of them are aligned, the system becomes reliable.

This is why some plants with fewer technicians outperform plants with larger teams. They are not working harder. They are working within a system that supports reliability.

Every maintenance and operations leader has experienced the frustration of implementing a “best practice” that looked perfect on paper but fell apart the moment it hit the floor. The concept was sound. The training was solid. The intentions were good. Yet the results never materialized.

Why does this happen so often?

Because best practices are not universal solutions. They are proven approaches that worked somewhere under specific conditions. When those conditions do not exist in your plant, the practice will not deliver the same results.

Consider a real example:
A food processing facility adopted a world‑class lubrication program from a sister plant. The routes were detailed. The intervals were precise. The products were correct. But the environment was different. The plant had higher humidity, more washdowns, and less controlled storage. Within months, bearings were still failing. The team blamed the practice, but the real issue was misalignment between the practice and the environment.

Another example:
A chemical plant copied a PM template from a corporate standard. The PMs were thorough, but the equipment was 30 years older than the equipment the template was designed for. The tasks were too frequent for some assets and not frequent enough for others. The backlog exploded. Technicians were overwhelmed. Production lost confidence. The practice was not wrong. It was simply not adapted.

This is the message at the heart of Chapter 1.
A best practice is not something you copy.
It is something you understand.

The organizations that excel do not ask, “What are others doing?”
They ask, “Why does this work, and how do we make it work here?”

They evaluate:
• the age and condition of their assets
• the skill level of their workforce
• the maturity of their processes
• the expectations of their leadership
• the realities of their production schedule
• the constraints of their environment

Then they shape the practice to fit.

This is why best practices matter. Not because they are perfect, but because they give you a starting point for improvement. The real value comes from adapting them to your world.

If your organization needs help identifying the right practices, adapting them to your environment, or building a structure that supports sustainable reliability, we can help you put the right foundation in place. https://www.reliabilityx.com/contact