Building a Pull System: How Corporate Teams Without Direct Authority Drive Real Adoption

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.