I spent my first five years as an engineer convinced that being right was enough. If I could prove, with diagrams and benchmarks and a detailed migration plan, that we should move off that legacy message queue, people would listen. So I wrote a fifty page document. It had charts, risk matrices, and a phased rollout plan so thorough you could have framed it. Nobody read it. Not a single decision maker. The project went ahead with the old queue and we spent the next year firefighting exactly the failures I predicted.
That failure taught me that technical influence has almost nothing to do with the quality of your evidence. It has everything to do with whether people trust you before they need to trust you. And trust is built in small, unglamorous ways.
A few years later I was in a similar position, trying to convince a platform team to adopt a new observability standard. This time I didn't write anything. I started by asking the lead what kept him up at night. Turned out he was terrified of a database migration coming in six months, not observability at all. So I offered to help with load testing for that migration, no strings attached. I spent three weekends building a harness. We found a connection pool leak two weeks before it would have taken down production. After that, when I said 'we should look at our metrics approach,' he cleared his calendar.
That's the pattern I've seen work over and over. Find a problem that matters to the person with authority, do the unglamorous work to solve it, and let the trust accrue. You don't need to be the smartest person in the room. You need to be the person who made their life easier last quarter.
There's another piece that took me embarrassingly long to learn. Stop trying to win the whole argument at once. Early on I wanted the new queue, the new schema, the new deployment pipeline, all approved in one meeting. People hear a big proposal and immediately start looking for what it might break. Now I advocate for the smallest possible change that solves one painful problem. Once that change is running in production without drama, the next small change is an easier conversation. Momentum builds quietly.
I also stopped treating disagreement as a technical problem to be debugged. When a senior engineer pushed back on my containerization proposal, I assumed he didn't understand the benefits. So I explained them again, slower. That made it worse. Later I found out he'd been burned by a botched container migration at his previous company. The right move wasn't more explanation. It was acknowledging his past experience and asking what would make him feel safe trying it again. We ended up running a six week pilot on a non critical service, and he became the project's biggest internal advocate.
You can't force influence. You can build it, one small favor and one honest conversation at a time. The title never mattered as much as I thought it did. What mattered was showing up before I needed something, listening to the actual fear in the room, and being willing to solve a boring problem that wasn't mine to solve.