How do you influence technical direction without formal authority?

As a senior iOS engineer without formal authority, influence comes down to a few things.

Lead with data, not opinion. If I want us to move away from, say, a bloated MVVM pattern or adopt structured concurrency, I don’t pitch it in a meeting cold — I write a short doc or prototype a spike that shows the before/after: crash rates, build times, a real diff of code complexity. Concrete evidence is much harder to argue with than “I think we should.”

Pick battles and time them well. Not every opinion needs to become a crusade. I focus energy on things with real leverage — architecture decisions that are expensive to reverse, like navigation patterns or dependency injection setup — rather than nitpicking things like file naming.

Build alignment before the room, not in it. If I know a proposal is going to be contentious, I’ll talk to the tech lead or a couple of senior peers one-on-one first, get their pushback early, adjust, and walk into the broader discussion with something that’s already been stress-tested. Ambushing a team with a big idea in a meeting rarely works.

Lead by example in code review. Consistently pointing out the same pattern — force unwraps, massive view controllers, whatever — and offering the fix, not just the criticism, shifts team norms over time more effectively than a mandate would.

Make it easy to say yes. Small, low-risk pilots — try the new pattern in one module, measure it, then propose rolling it out — get much less resistance than “let’s rewrite everything.”

Underneath all of that, it’s really about trust: being right often enough, admitting when I’m wrong, and making sure credit flows to the team rather than to me, so people want to listen the next time I raise something.