Building Influence Without Authority

One of the most important skills anyone can have

Back in May, I learned that two versions of the same standard work were being taught in the network. There was the official written standard, but there was also an alternative approach, born out of a workshop at a site a couple of years ago. A tiger team that focused on correcting and improving processes at struggling sites had been teaching the unofficial version. Meanwhile, my manager training team was teaching managers to follow the written standard. This created a lot of confusion when a manager would attend our training and be taught one way, then go back to their site and be told something totally different by the team that was there to help them improve.

Six different teams touched this process in different capacities: network operations, the specialized improvement team, process engineering, two training teams, and regional leadership. But none of them were talking to each other about it and most of them didn’t know that conflicting versions of the standard even existed. They all thought that the version they were teaching was the correct standard. The org structure never asked them to compare notes with each other. Each team sat inside its own reporting line, with its own priorities, its own definition of ‘good.’ Nobody’s role included checking whether the other teams were working from the same standard.

That’s the exact pattern from my post on Why No One Owns the Problem Between Departments: ownership gets drawn around departments, never around the connections between them. We had six rigid silos and no one assigned to bridge them. Nobody assigned me to coordinate the teams or solve the conflict. But being aware of it put the obligation on me to do something about it.

I’ve written before about the difference between leadership and influence — authority over your own department versus the ability to move things you don’t control. But knowing the difference doesn’t tell you what to say to the person on the other side of a gap who doesn’t report to you. That’s what I want to look at today. In the actual moment, what do you do?

Why the Two Default Moves Fail

Most people default to one of two moves when they find a problem outside their lane. Both tend to fail.

Asking nicely puts the entire decision in someone else’s hands with nothing behind it. You’ve raised a concern. They’ve heard it. Nothing obligates them to act, and if they’re already busy (and they always are) a polite flag gets filed away as something to get to eventually. Eventually rarely comes.

Escalating immediately solves the urgency problem and creates a worse one. Going over someone’s head before you’ve tried working with them directly tends to burn the relationship you’ll need the next time. You might get compliance that once, but you also get a reputation as someone that’s hard to work with.

The problem is that both approaches skip the work that needs to be done. When you’re in this kind of situation, what you need to do is remove the friction that makes saying no the path of least resistance for them.

Frame It As a Gate, Not a Challenge

The first move in resolving the standards conflict was a direct conversation with the other training team, asking them to pause materials they’d already invested time and effort in.

I didn’t frame it as “you’re building the wrong thing.” I framed it as a quality gate: I let them know that a standards conflict had surfaced, and continuing what they were doing risked codifying something that hadn’t actually been validated. That’s a completely different conversation than telling a team their work is wrong. That just puts them on the defensive. Presenting it as a quality concern gives them a reason to want the pause as much as you do; nobody wants to be the team that shipped an unvalidated standard to the whole network.

Most people will cooperate readily with a gate and resist a challenge, even when the underlying request is identical. A challenge asks someone to admit an error. A gate asks someone to avoid one.

Structure the Ask So It Can’t Stay Vague

Getting the pause bought a few weeks but it didn’t resolve anything. All six teams needed to align on one answer. My biggest concern was that an open-ended conversation among six teams with competing histories and priorities could have run for months. So instead of scheduling a series of meetings, I built a single dedicated Slack channel and pulled in one representative from each team. I was very intentional about the way I presented the problem. I didn’t just say “here’s a problem, let’s discuss this.” I framed the conversation around exactly two options: the current official standard, or the alternative that had come out of the earlier workshop. I gave the pros and cons of each and asked everybody to pick one. I also gave them a clear date they needed to respond by.

Narrowing the frame did most of the work. Vague asks invite vague responses and no urgency. A forced choice between two specific options, with a real deadline attached, gives a group of busy senior people something they can act on. The alignment happened on schedule because the structure didn’t leave room for the conversation to drift. There was still disagreement and conversation about the merits of each approach. But presenting it as two options with a deadline kept the discussion on topic and on time.

Bring Something Instead of Asking For Something

My second story is a different kind of authority problem. In the last example, nobody had asked me to take charge, I’d simply seen a problem and taken ownership of it. In this instance, site leadership had asked for my help. Being invited makes things easier, but I still had no authority over the site, the team, or the managers running it. If you’ve read When A Good Leader Meets Bad Culture, this is the same site from that post. After the events I shared in that post, I reached out to the general manager at the site. He knew there were some problems and requested that I come visit.

I spent a couple days on the floor observing before I said anything about causes. The site was running about 6% behind three comparable locations with identical layouts. The assumption walking in, from the site itself and from the network’s perspective, was that this was a matter of the employees not being as engaged as at other sites. My analysis found otherwise. The site’s individual process rates were actually near the top of its peer group. The real gap was in the execution of the process. Because they had some of their systems set up incorrectly and had some quality shortcomings in a couple places, the site was generating nearly a quarter more touches per package than its peers. Everyone was working hard, they were just doing more work than should have been needed.

When I gave my recommendations to the site lead, I didn’t walk in with a diagnosis and ask them to accept it. I walked in with a finished report: ranked recommendations, each one sized in hours saved per week, with the reasoning shown so it could survive scrutiny from anyone who wanted to check my work. One fix alone was worth well over two hundred hours a week, once I traced it back to containers running underpacked and compounding into congestion everywhere downstream.

Asking a struggling manager to trust your judgment is a big ask. Handing them a diagnosis they can independently verify, with a clear reframe from “your team isn’t working hard enough” to “the work itself was set up wrong,” is a much smaller one. He didn’t have to take my word for anything. The math did that part.

Protect What’s Working Before You Touch What Isn’t

That report had one really important section that mattered as much as the recommendations — a list of everything the site was already doing better than its peers, with an explicit note not to touch any of it.

It would have been easy to skip that section because it didn’t add any hours saved. But a manager who’s just been told, by an outsider, that his site is underperforming, especially coming after a public struggle, is primed to hear the whole visit as criticism. Naming what was already working — clearly, specifically, before getting into what wasn’t — changed what kind of conversation this was. It stopped being “here’s what’s wrong with your site” and became “here’s what’s happening, including the parts you should be proud of.”

This is not a social nicety. It’s how you show them that your visit is not an attack, so they’ll listen when you give them four things worth changing. It’s how you show him that you’re not trying to take apart everything he’s built.

Summary

Exerting influence without authority comes from a small number of repeatable moves: frame a hard ask as protection rather than correction, structure requests so they aren’t vague, bring finished work with data instead of an opinion, and protect what’s already working before you touch what isn’t. These things show that you’re there to help, not to attack. They make it easy for the people involved to say ‘yes.’ None of it requires outranking anyone. They don’t even require someone to give you permission. They just require you to pay attention and be genuinely helpful.

You don’t need to outrank someone to move them. You need to make the right answer easier to reach than the wrong one.

---

From Theory to Action

1. Name one gap you’ve spotted that isn’t officially yours. Write down which teams touch it and whether any of them are even aware the others are involved.

2. Before you ask anyone to change course, find the “quality gate” framing. Rewrite your ask so it protects the other person from a bad outcome, rather than correcting a mistake they’ve already made.

3. Reduce your next cross-team ask to a forced choice with a deadline. If the request could still be answered with “let’s keep talking about it,” narrow it further.

4. The next time you need someone else’s buy-in, bring a draft, not a question. A finished recommendation someone can push back on moves faster than an open request for their opinion.

5. Before you flag what’s broken, write down three things that are working. Say those first, specifically, before getting into what needs to change.

6. Identify the person in your network most likely to say no to your next ask. Have the conversation with them first, one-on-one, before it happens in a group.