I want to talk about something that took me years to get comfortable with: getting a room full of engineers to follow a direction when you have no actual power over them. As a consultant, I step into organizations where I'm technically an outsider. No direct reports. No authority to assign work. Yet my job is often to change how teams operate. Early on, I thought being right was enough. I'd write a detailed proposal, explain the tradeoffs, and wait for people to agree. They rarely did.
There was one engagement where I recommended replacing a homegrown deployment script with a proper pipeline. I had the data, the comparison matrix, the rollback plan. I presented it to the platform team and got polite nods. Nothing changed for three months. I was frustrated. Then a senior engineer pulled me aside and said, 'You just told us our baby is ugly. You didn't ask why we built it that way.' That stung because it was true. I'd treated their work as an obstacle instead of a context.
What I learned is that influence starts with being genuinely useful in ways that matter to them, not to me. On the next project, I stopped pushing my agenda for a while. I sat with the operations folks during their on-call rotation and just helped close tickets. I fixed a recurring disk full alert by adjusting log rotation. Nobody asked me to. A few weeks later, when I floated an idea about automating their release checklist, the same people who'd ignored my earlier memo started asking questions. Not because I'd proven I was smart, but because I'd proven I wasn't there to judge them.
The other part is speaking the language of their risk. Engineers don't resist change because they're lazy. They resist because they've been burned by someone who never had to carry the pager. So I started framing every recommendation around what would keep them out of trouble. Instead of saying 'we should adopt containers,' I'd say 'here's how we can reduce the 2 a.m. calls from database connection leaks.' Same technical direction, different entry point. That small shift made conversations productive.
I also learned to give away credit deliberately. If a system admin suggests a tweak that makes my design better, I mention their name in front of their manager. It costs me nothing and builds a reputation as someone who doesn't need to win. Over time, people start treating your opinions as safe to consider because you're not competing with them for visibility.
The mistake I made early on was treating influence like a presentation skill. It's not. It's a patience skill. You earn the right to be heard by showing up for other people's problems first. And you have to accept that sometimes the right technical answer will lose to the right political answer, and that's okay. The goal isn't to win the argument. It's to make the system better, even if someone else gets the credit.
Eventually, influence without authority stops feeling like a constraint. It becomes the default way you work. You ask more questions, you assume less, and you build relationships that outlast any single project. I still get it wrong sometimes, especially when I'm tired and slide back into just wanting to be correct. But I've noticed that the moment I stop trying to be the smartest person in the room, the room gets a lot more willing to listen.