Most org charts describe who reports to whom. They say almost nothing about who a team actually listens to when a system is on fire at 2 a.m. Those are frequently different people — and in distributed systems work, that gap is where real leadership happens.
Authority tells people what to do. Influence is what makes them want to. On a team spanning multiple services, multiple time zones, and multiple managers, authority often doesn't even reach that far — you can't formally direct an engineer on another team's roadmap. Influence is the only lever left. The good news: it's also the more durable one.
The four levers that actually move a distributed team
Technical credibility
People follow the engineer whose calls have been right before. Credibility isn't built in the big design review — it's built in the small moments: catching the race condition nobody else saw, actually reading the postmortem instead of skimming it.
Written clarity
A clear design doc travels further than a persuasive meeting ever will. Most people will never hear you argue your point live — they'll only ever read what you wrote. Make the writing carry the weight.
Consistency under pressure
Anyone can look composed in a calm planning meeting. What earns trust is showing up the same way during an incident — clear, calm, focused on the fix instead of the blame.
Making others' work easier
The fastest way to earn influence on a team you don't manage is to remove a blocker for someone who does the work day to day. Influence compounds every time you help without being asked.
A migration nobody officially owned
The clearest version of this shows up during a cross-team migration — the kind where three services need to move together, no single manager owns all three teams, and the timeline is tight enough that nobody wants to volunteer to run it.
In situations like that, the person who ends up steering it is rarely appointed. They're the one who wrote the first rollout doc before anyone asked for one, flagged the shared dependency the other two teams hadn't noticed yet, and kept a plain-language status update flowing so no one had to chase updates in five different channels. None of that required a title. All of it required doing the unglamorous coordination work before someone else had to.
Authority is given to you. Influence is something a team decides you've earned — one clear decision at a time.
Where this breaks down
Influence isn't a substitute for authority in every situation — it has real limits. It doesn't help you make an unpopular call that requires enforcement, and it can quietly erode if you're right too rarely, or if you start using your credibility to avoid being challenged rather than to earn trust. Influence has to keep being re-earned; that's what makes it different from a title, which sticks around whether or not you deserve it that week.
It also isn't a reason to avoid seeking formal authority when a team genuinely needs it — sometimes a decision needs someone empowered to make the final call, not just someone persuasive. The two aren't in competition. Influence is what makes authority, when you do have it, actually work.
The takeaway
On a distributed team, nobody is going to hand you the authority to make the migration go smoothly. But every team is quietly watching for who they can trust to make the hard call, write the doc no one else wants to write, and stay steady when things break. That's the leadership that's actually available to you — and it scales a lot further than a title ever will.