Your Peer Group Is Not Your Working Group: The Hardest Rule for Corporate Teams With Indirect Influence

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.