How to Influence Company Tech Strategy When You Don't Set It

There isn't a mold of a person that will always have the most technologically innovative idea. It can come from any location, role, or team. The problem is that organizations often suppress any strategy that doesn't come from the center. If you're coming from outside of corporate — a satellite location, a franchise, or even an entry-level role — how do you influence the central strategy to allow for innovation?

‍

The struggle with reverse-influencing

Most of the time, clients come to us because they've "hit a wall." They're ready to push their technology further but are stuck on what to do next. For the clients who aren't part of corporate, this usually starts as dissatisfaction with the software that was handed to them. But when we dig into what the current system isn't giving them, the bigger issue almost always turns out to be something more human: a sense of disconnect from corporate's direction, and a push from the top that never really accounted for them.

By the time the conversation reaches us, the frustration has been building; not for months, but for years. So why does the gap feel so hard to close?

1. The center holds the keys on purpose. Technology and AI strategy is one of the most deliberately centralized functions in a company. More than half of organizations run AI under a centrally-led structure even when they decentralize almost everything else. So the wall isn't an accident; it's how the company keeps technology decisions coherent. The things a location would need to build anything (system access, admin rights, budget, API permissions) were never designed to sit outside HQ.
2. They are building for scale, not nuance. Major technology decisions have to work across the entire company, so corporate designs for the common case. That's the right call for the whole, but it means the specific realities of a satellite location or a single team rarely make it into the requirements.
3. Lessons learned the hard way can only happen once. One of corporate's jobs is to protect the brand and the company's reputation. If a decentralized initiative went badly before, even years ago and even unrelated to this technology, they'll be far more hesitant to let it happen again. It isn't personal. It's a concern about fallout that could carry serious consequences.
4. Influence runs through people, not the org chart. Influence runs through people, not the org chart. Every center has one or two people everyone actually trusts and tests things against. If you're not in that person's orbit, your best idea never reaches the room where the decision gets made. You can lobby three people at corporate and still not reach the one whose sign-off everyone waits for.
5. You may be pushing against a decision they made. You may be pushing against a decision they made. Technology moves fast, so by the time a system is implemented and its gaps become obvious, the team that chose it is often still at corporate. That can make it feel less like a business decision and more like a personal one. You're not just critiquing a tool, you're critiquing the one they chose.

None of these are irrational. Corporate isn't being stubborn for its own sake. It's protecting the brand, honoring past decisions, and trusting the people it already trusts. Which is exactly why arguing harder doesn't work. You can't out-argue a wall that was built on purpose. So the instinct becomes to go around it.

‍

Why the obvious moves backfire

When the center won't move, three responses feel natural. All three tend to fail, and it's worth knowing why before you try them.

The first is to argue harder. Build the business case, write the memo, escalate. The trouble isn't that you're wrong. It's that an argument still asks the center to take your word for it, and given everything above, taking a branch's word for it is the one thing they're most reluctant to do. A projection can be debated. A result is harder to wave off.

The second is to go around them. This is the most tempting one, and the most dangerous. We watched a franchise wrestle with it directly: stuck on a corporate-mandated system missing features they'd had before, they were one step from standing up a second, better software alongside it and just running their business out of that. It solves the pain today. But two systems running in parallel becomes a place where leads quietly slip between the cracks, and now you've got two sources of truth and no single answer to "what's actually going on." We advised against it for exactly that reason. Worse, going rogue proves the center right. Every buried lead and every data mismatch becomes evidence that decentralized initiatives can't be trusted, which is the very fear that built the wall in the first place. The workaround doesn't just fail. It hardens the thing you were trying to move.

The third is to wait. File the request, get on the roadmap, and hope your turn comes. Sometimes it does. In the same engagement, the vendor confirmed the missing capability was genuinely coming, so pausing and checking back was the right call there. But waiting only works when the thing you need is actually queued and dated. Most of the time you're one edge case in a backlog built for the common case, and "later" never arrives. The judgment call is honest: press for something that's real and imminent, but don't mistake a polite "it's on the list" for a plan.

So the edge is left choosing between a case no one's positioned to hear, a workaround that backfires, and a wait that may never end. None of the three moves the center. The way through is a different move entirely.

‍

What actually works: proof over persuasion

The goal isn't to write a better proposal or line up another vendor demo. It's to become the proof. You turn your own location into the example that shows corporate real results, and then you let those results, backed by what you've learned building them, make the case you were never going to win on paper.

Build the smallest working proof

You don't need to overhaul the whole system to make a point. Narrow in on the specific problems you can solve within your own scope, and back-table the ones that are bigger than your location until you can tackle them with corporate. A good place to start is testing the AI features already available in the software you have.

‍We wrote about how to do that here→

Quantify the proof points

Before you build or deploy anything, capture your starting state in the metrics that matter: hours spent, miskeys, parts that failed inspection. Measuring the same things after the solution is in place turns your win into a before-and-after that other locations can repeat. And when you use the metrics corporate already tracks, everyone is speaking the same language.

Prioritize integration over replacement

Unless you already know the company is moving off the current platform, favor solutions that work with what you have rather than around it. Every branch is running the same core technology, so a fix that plugs into it isn't just a fix for you. It's a candidate for the wider rollout, which is exactly what gives your idea leverage as strategy instead of as a one-off.

Keep the center close to client frustrations

Corporate rarely has direct contact with the end client, so it doesn't feel the friction you feel daily. When clients keep raising a problem you know a system change could fix, pass those messages up. The client becomes a neutral voice in the room, one that isn't a branch lobbying for itself, and that everyone can agree deserves priority.

Keep a clean, detailed roadmap, strategy, and SOP

Document the decision, the system, and the outcome as you go. It makes your solution simple to present and simple to repeat, and it hands the center something it can't build on its own: a ready-made playbook for scaling your win to every other location.

Put it in front of the one person you trust

Influence runs through people (reason #4 above), so aim your proof at the right one instead of sending it up the org chart and hoping. Every center has someone it tests everything against. Find that person and get your demo in front of them directly, even if that just means getting cc'd into the right conversation at corporate.

‍

Ultimately, influencing innovation isn't about taking on a problem well beyond your reach. By achieving excellence on a system your own team or site has driven, you show a path that's repeatable and scalable. And you leave room for partnership and collaboration instead of opposition.

‍

Strategy Influencing FAQs

Why won't corporate just approve a good idea from a branch or franchise?

Centralizing technology decisions is deliberate, not an oversight. Companies keep these calls at HQ to stay coherent, protect the brand, and honor decisions they've already made. The access, budget, and permissions you'd need to build something were never designed to sit outside HQ. So a solid idea on paper still runs into a wall that was built on purpose — which is exactly why arguing harder rarely moves it.

Can't I just build my own workaround and run my part of the business on it?

It's the most tempting move and the riskiest one. Running a second system alongside the mandated one creates two versions of the truth, and leads and data start slipping between them. Worse, when it goes sideways it proves corporate's fear right — that a location going its own way can't be trusted. The workaround usually hardens the wall instead of moving it.

The feature I need is "on the roadmap." Should I wait?

Sometimes, but only when it's genuinely queued and dated. If the vendor confirms it's coming soon, pausing and checking back is the right call. If all you got was a polite "it's on the list," treat that as a no for now and start proving your case another way. Don't mistake a backlog for a plan.

How do I prove an idea works if I don't have budget or system access?

Start with the smallest working version inside your own scope. Solve the specific problems you can reach today, and set aside the bigger ones until you can tackle them with corporate. A good first step is testing the AI features already built into the software you have. Then capture your starting point before you change anything — hours spent, miskeys, parts that failed inspection — and measure the same things after, so your win becomes a before-and-after other locations can repeat.

Why favor a fix that connects to the current system over replacing it?

Unless you already know the company is leaving the current platform, a fix that plugs into what everyone's running isn't just a fix for you; it's a candidate for the wider rollout. That's what turns your win from a one-off into something corporate can actually scale.