I spent the first six years of my career waiting for someone to give me permission. Permission to propose a new deployment pipeline, to question a database choice, to suggest we stop writing that one legacy integration by hand. I assumed influence came with a title. It doesn't. I learned that slowly, and mostly by failing in front of people whose opinions I wanted to change.
A few years back I was a senior developer on a team with a real problem with flaky tests. Every morning someone would rerun the CI suite two or three times before merging. I wrote a long document explaining why we should invest in test isolation and deterministic ordering. I sent it to the team lead and waited. Nothing happened. Two weeks later I brought it up in a meeting and the lead said we didn't have time for it right now. I was frustrated. I had the right answer, but nobody cared because they didn't see me as someone who owned the problem. I'd skipped the part where you build trust before you build a case.
The turning point came when I stopped trying to win arguments and started making small things unambiguously better. I fixed one flaky test that everyone hated, the one that failed most often. It took an afternoon. I didn't announce it. I just made the build a little calmer. Then I fixed another. After a week, a teammate asked why the morning reruns had stopped. I explained what I'd changed. Suddenly I had a reputation for caring about the test suite, not just complaining about it. That reputation is what later let me propose the bigger refactor. Same idea, same document basically, but now it landed because people associated my name with actual improvement.
There's a difference between being right and being listened to. Being right is cheap. Being listened to requires that people believe you'll do the work, that you understand their constraints, and that you're not just trying to look smart. I used to treat technical debates like a courtroom. I'd prepare evidence, cite blog posts, and expect the logic to carry the day. It rarely did. What worked instead was pairing with the person I disagreed with. Not to convince them, but to understand why they chose the thing I thought was wrong. Half the time I discovered a constraint I hadn't known about. The other half, they walked away thinking I was reasonable, which meant the next disagreement started with more trust.
One thing I still struggle with is knowing when to let go. Early on, I'd push an idea long after the room had moved on. I thought persistence was influence. It's not. It's annoying. Now if I make a case twice and the team decides against it, I drop it unless new information shows up. That restraint has actually made my opinions carry more weight, because people know I'm not going to relitigate every decision forever. Influence is a weird thing. You build it by doing unglamorous work, by listening more than you talk, and by accepting that sometimes the best way to lead is to let someone else get the credit. I'm still not great at that last part.