When I was promoted to cloud architect at a manufacturing company, I assumed people would listen to my recommendations because my title sounded impressive. They didn't. The first time I suggested we adopt infrastructure as code, the senior engineers nodded and then went back to clicking through the AWS console. I spent weeks building a beautiful Terraform module library and presented it at an architecture review. The room went quiet. Then one engineer said, "That's great, but we're shipping a new line next week and don't have time to learn your tool."
That stung because I had treated influence like a mandate. I had authority in name but none in practice, and I'd confused the two. What finally worked was much less glamorous: I stopped trying to convert people and started helping them with their actual problems. I sat with the engineer who managed the warehouse inventory system and asked what ate his weekends. It turned out he was manually recreating VMs every time a vendor updated a label printer driver. I wrote a small script that did it in ten minutes. I didn't call it infrastructure as code. I just said, "Hey, this might save you some time."
He used the script. Then he showed a teammate. Within a month, a few people asked me to help automate other manual tasks, and slowly the Terraform conversations became practical instead of theoretical. By then they trusted me, not my title.
The mistake I made early on was confusing expertise with influence. Being right isn't enough when you can't make anyone do anything. Influence without authority is built on a different currency: reducing someone else's pain. You have to find the person who's drowning and hand them a rope, not a lecture about swimming techniques.
Another thing that helped was learning to frame my ideas as experiments rather than mandates. Instead of saying we need to adopt zero trust networking, I'd say, "I wonder if we can lock down the staging environment without breaking the QA team's access for a week and see what breaks." That small change in language made people curious instead of defensive. They could disagree with the idea without feeling insubordinate, and that openness often led to better designs anyway. One senior DBA pushed back on my proposal and ended up teaching me about connection pooling behavior I'd completely overlooked. If I'd insisted on my original plan, we'd have shipped a security improvement that would have slowed every reporting job.
I've also learned that timing matters more than I'd like to admit. Showing up right after an incident or during a migration freeze with a big architectural pitch is a great way to get ignored. But showing up two weeks before a compliance audit with a simple checklist that saves the team three days of evidence collection makes you a hero. The same idea can land completely differently depending on whether people have appetite for change at that moment.
The biggest shift for me was internal: I stopped measuring success by how many of my ideas got adopted and started measuring it by whether people came back to ask for my opinion a second time. That's the real sign you've built influence. It's not a title or a seat at the table. It's the quiet moment when someone messages you before a design meeting and says, "Can you sanity-check this before I present it?" That's when you know you're the person they trust, and nobody had to give you that authority. You earned it one small favor at a time.