Influence Without Authority Isn't Won in the Room. It's Built Before You Get There.

How I built influence before I needed it.

The conversation to use feature flags barely happened. I sat down with my CTO expecting to make the case. To my surprise, he was already convinced. He told me to go and write the business case. My PM was already thinking about the next release. The developers were already eager to use it. An engineer from another team had already asked how their team could get involved. By the time I got to filling out a business case, the decision had already been made and shifted to next steps.

That is not how influence is supposed to work. You prepare the argument, walk into the room, make the case, answer the objections, and hope the decision goes your way. But in this case, the argument had already been made: in a one-to-one with the PM, in a soft introduction to the CTO, and in a biweekly tech demo where someone from another team spoke up before I had finished showing it. The formal conversation was not where the decision started. It was where the groundwork became visible.

This is what I learned about influencing direction beyond your scope. It does not just happen in the room. It happens in everything you do before the room exists.

Filling the vacuum

In early stage companies, technical direction is rarely handed down clearly, and the vacuum gets filled by whoever moves first. The people who move first decide which problems get priority.

I had seen the downside of that before. The team was adopting infrastructure as code, a significant shift in how the whole engineering organisation would interact with deployments. The decision was technically sound, well prepared, and had buy-in from the people who understood the infrastructure layer best. But it did not fully account for the developer experience on the other side.

The tool was complex. It added friction to deployment workflows, and it took much longer than what developers were used to. The people who made the decision were not especially worried about the complexity, and the people who had to live with it wished they had been involved earlier. Nobody really made a bad call. The direction had simply been shaped from one angle.

A different kind of vacuum existed on my own team, no one was going to fix the customer configuration problem. Developers were being pulled away from feature work to handle customer-specific setup, colour settings, schema conversions, data uploads, the kind of task that kept landing on engineers not because it was technically complex but because we hadn't built a way for anyone else to do it. It came up in conversations as boring and frustrating, and when I looked at how much time was going into it against how much feature work was getting done, the imbalance was hard to ignore. Watching people on your team work on things that aren't a good use of their capabilities is something you eventually have to act on.

So I had a conversation with product first, framing it in their terms. Developer time spent on work that only needs an engineer because there's no other mechanism. They were receptive, so I built an internal admin panel as part of that broader conversation of protecting engineering time. I showed it at the biweekly tech demo, which customer support agents were already attending as participants. Seeing it working directly changed the nature of the conversation since nobody asked whether it was worth doing, they asked how they could start using it. Shortly after it became part of the team's strategy. Configuration and onboarding work moved to customer support, and they already understood the tool because they'd been in the room.

That was the pattern I later recognised as similar to feature flags. The influence did not start with a proposal. It started by making the problem visible, showing a possible solution, and letting the right people see how it connected to their own work.

Making ideas visible before they're decisions

The biweekly tech meeting was already how the tech teams kept in sync, but for a while it was long and unfocused - the kind of meeting people attended because they had to. What I pushed for was a segment where anyone could demo what they were working on, something low stakes and unpolished, just a chance to show the thing and talk about it.

It caught on faster than I expected and we renamed it the biweekly tech demo. People were genuinely excited to share, and having something to show created a quiet pressure to deliver something worth showing. Across four teams that could easily drift into silos, it kept the culture cohesive and gave people visibility into work they'd otherwise never see.

When I eventually showed feature flags, I wasn't pitching it, I just showed it working, what you could toggle, what you could control, what happened when something went wrong, and let people draw their own conclusions. An engineer from another team spoke up in the meeting, said they could use this for their own team, that it was exactly what they'd been missing, and asked how they could get involved. They hadn't been targeted or briefed beforehand, they just saw it working and opted in.

That's the difference between a demo in a low-stakes forum and a proposal in a formal meeting. A proposal asks people to evaluate an idea under pressure, a demo lets people react to something real. The engineer who spoke up wasn't making a decision, they were expressing genuine interest, and that interest became informal advocacy before any formal conversation had happened. By the time feature flags reached a decision point, it had already passed the first test, whether people found it interesting enough to care about.

This is easy to underestimate. A lot of technical influence is not about having the strongest argument. It is about giving people enough contact with an idea that, by the time it needs approval, it already feels familiar, useful and low-risk.

Speaking the right language to the right person

Feature flags meant different things to different people, and pitching it the same way to everyone would have killed it before it got anywhere.

The PM conversation happened first, in a one to one. I didn't lead with the technical case. I talked about release ownership, about the dependency on developers every time she wanted to control what went out and when, about what it would mean to manage that herself. The moment I knew the approach had landed was when she stopped asking whether it was worth doing and started asking which customers she could control which features for, what it would look like on the user side, which customers she could target differently. She was already thinking about how to use it before we'd agreed to build it properly.

With developers the framing was different. They had some anxiety around releases, everything went out together, which meant any change could break anything. Feature flags changed that, you could ship without releasing, merge with confidence, and control what users saw independently of what was deployed. That's a different kind of relief to what the PM needed, but it came from the same solution.

The CTO barely needed a formal conversation, and what surprised me was how little friction there was. I'd given him a soft introduction to the idea early on, the show and tell had done most of the work, and by the time we sat down he was already all for it. He wasn't being convinced, he was telling me to go make the business case. The cost was low, the complexity was manageable, and the upside was real: reduced deployment risk, better release control, and a cleaner way to separate shipping code from exposing functionality.

Getting to this point, meant understanding what each person cared about before walking into the room. The friction they feel day to day, the things making their job harder than it should be, and sometimes the things they'd learned to work around rather than raise. When you understand that, you are no longer pitching an idea in the abstract. You are speaking in outcomes people already care about.

What good influence actually requires

None of this works without patience and empathy. Patience matters because the approach is slow by design, skip it and you're walking into a room where the idea is new to everyone, and a cold audience under pressure is the hardest place to land anything. Empathy because you can't sequence stakeholders correctly, or frame an idea in someone else's point of view, without first understanding what they actually care about. The IaC situation showed what happens when the groundwork reaches only part of the audience. Whoever moves first shapes the approach, and if you're not moving first, you'll be working within someone else's.

Timing and trust are the two things easiest to overlook. The same idea can land differently depending on when it arrives,too early and it reads as abstract, too late and it reads as redundant . The right timing is when the pain is apparent and the path forward is open. But it also requires trust. People have to believe your judgement is sound, and that gets built through the small things long before the big moments arrive.

The honest caveat is that there are moments where none of this is the right approach. When the time window is short, when the decision needs to be on record, or when there are external blockers, then a direct conversation is needed. Ask yourself: is the resistance actually about the idea, or something deeper? Does the solution need people to care, or just comply? Is there even time for a slower approach? If the answers point that way, go direct. But these cases are the exception, most of the time the real work is quieter than it looks. The conversations in between meetings, the trust earned through the small things. These are what allow ideas to arrive already accepted.

Ultimately, the goal isn't to win the argument. It's to make the argument unnecessary.