Influence Without Authority

At Staff+ the scope of what you're accountable for outgrows the scope of what you control. You're on the hook for an outcome that spans four teams, and not one of those engineers reports to you. You cannot mandate, you cannot reassign, you cannot fire. What's left is persuasion — and persuasion at this level is a learnable, repeatable skill, not a personality trait you were either born with or not.

The engineers who are good at it are rarely the most charismatic. They're the ones who built credibility, made the right thing easy, and lined up agreement before the meeting that everyone else thought was where the decision got made.

Credibility Is the Currency

Everything else runs on this. Without credibility, the best-argued proposal gets a polite nod and quiet inaction. With it, a one-line Slack message moves a roadmap.

Credibility is earned, slowly, through:

• Shipped work. Not designs, not docs — things that are in production and didn't fall over. The first time you propose something cross-team, your track record is the only evidence you have.
• Accurate predictions. Say "this will be slow under load" and be right; say "this migration will take three weeks" and land it. People remember who called it.
• Being right — and admitting when wrong. Counterintuitively, publicly saying "I was wrong about X, here's what changed my mind" builds credibility. It signals you update on evidence, which makes your future claims more trustworthy, not less.

Trust compounds. Each correct call makes the next assertion cheaper to accept. And it burns fast: one confidently-wrong claim that costs a team a sprint, or one time you spun a bad outcome instead of owning it, and you're paying interest for quarters. Spend the balance deliberately — don't stake hard-won credibility on a hill that doesn't matter.

Make the Right Thing the Easy Thing

The most durable influence is structural, not interpersonal. Convincing one engineer in a meeting lasts until they're reassigned. Changing the environment so the desired behavior is the path of least resistance lasts until someone deliberately changes it back.

• Golden paths. A paved road for the common case — service template, deploy pipeline, observability wired in — that's genuinely easier than rolling your own. Adoption follows convenience, not mandates.
• Good defaults. The default config is what 90% of teams will ship. Make the default the right choice and you've influenced everyone who never touched the setting.
• Tooling and templates. A linter rule, a scaffold, a CI check that fails loudly. These persuade silently, every time, without you in the room.

When you find yourself in the same argument with the fifth team this quarter, stop arguing. Build the thing that makes the argument unnecessary. Structural influence scales; repeating yourself does not.

Meet People Where They Are

Your proposal is, to you, obviously correct. To the team you need, it's a tax on a roadmap they already committed to. Influence starts with understanding their world:

• Goals. What is this team measured on this half? Your ask either helps that or competes with it.
• Incentives. What gets their lead promoted? What does their manager fear? People act on incentives even when they agree with you in principle.
• Constraints. Headcount, on-call load, a fragile system they can't touch until Q3. The "no" is often a constraint you didn't know about, not disagreement.

Then frame the proposal in terms of their problem, not yours. "This unblocks the latency work you committed to" beats "this is the right architecture." Map the stakeholders before the big asks: who decides, who influences the decider, who is affected, who will object and why. The map tells you where to spend your conversations.

Written Persuasion

The highest-leverage form of influence is a document that makes the case so well it argues for you while you sleep. A good design doc gets read by people you'll never meet, in timezones you'll never overlap with, and converts them.

• Argue from data and shared principles, not authority or taste. "We agreed reliability is the top priority this year; here's how option A serves it" lands; "I think we should do A" does not.
• Lay out the options you rejected and why. Skeptics trust a recommendation more when they can see you considered their preferred alternative and have a reason.
• Make the ask and the recommendation explicit. A doc that ends in ambiguity ends in inaction.

This is the medium where authority matters least and reasoning matters most, which is exactly why it's the Staff+ engineer's primary tool. See RFCs & design docs for how to structure the document itself, and technical decisions for driving the call to a close.

Leading Through Questions

You don't have to be the one who states the conclusion. Often it's better if you're not.

• Socratic alignment. Ask the questions that lead a team to discover the problem themselves. "What happens to this when traffic doubles?" lands harder than "this won't scale," because they reached it.
• Let others arrive at it. A conclusion someone reaches on their own is theirs; they defend it. A conclusion you hand them is yours; they poke holes in it.
• Give away credit generously. When the team adopts the idea, let it be their idea. You are not collecting attribution; you're collecting outcomes. The engineer who hoards credit finds the next idea harder to place.

This feels like giving things up. It is — and it's the most reliable way to make influence stick, because it's no longer dependent on you.

Disagreement and Conflict

You will not align everyone by being agreeable. Real influence survives genuine disagreement.

• Separate the person from the position. Attack the argument, never the arguer. The moment someone feels personally attacked, the technical discussion is over and you've made an enemy who outlasts the decision.
• Steelman the other side. State their position better than they did before you disagree with it. It proves you understood, and it often reveals they were half-right.
• Disagree and commit. Once the decision is made — even against you — commit to it visibly and fully. Re-litigating a settled call quietly is corrosive, and it's noticed. The engineers who can lose an argument gracefully get listened to more next time.
• Know which hills to die on. Most decisions are reversible and not worth the capital. Save the hard stands for the few that are expensive to undo. If you fight everything, you're a blocker; if you fight nothing, you're furniture.

Coalition Building

The big meeting is not where the decision gets made. It's where the decision gets ratified. The work happened before.

• Line up support first. Walk the proposal through the key stakeholders one-on-one before it's on a shared agenda. Smaller rooms surface objections you can address calmly instead of defending live.
• Find allies. Someone already wants what you want, or has the same pain. A second voice that isn't yours changes the room.
• No surprises in the room. Anyone who will be affected or who might object should have heard it from you first. Surprising a peer publicly, even with a good idea, buys you a "no" out of sheer self-defense — and a grudge. Pre-wiring isn't manipulation; it's respect.

Escalation as a Tool, Not a Failure

Escalation has a bad reputation because it's usually done badly — as a tattle, a power play, a confession that you couldn't handle it. Done well, it's a normal, clean instrument for resolving a genuine deadlock between teams with conflicting priorities.

Escalate cleanly:

• Only after a real attempt. You've talked directly, understood their constraint, and you're genuinely stuck on a priority conflict neither of you can resolve.
• With options and a recommendation, not a complaint. "Teams A and B disagree on X. Here are the two paths, the tradeoffs, and what I'd choose — we need a tiebreak." You're handing the decider a decision, not a mess.
• In the open, with the other party. Loop in the person you're escalating about. Escalation done behind someone's back is the going-over-heads move people rightly resent; done transparently, it's just asking the right person to make a call that's above both your pay grades.

The goal is a decision, not a victory. If your "escalation" reads as a request for someone to overrule a peer, you've used the tool wrong.

Anti-Patterns

• The blocker who only says no. Veto power with no alternative. You can stall anything once; after that, people route around you and stop inviting you. A "no" is only influence if it comes with a "here's what would work."
• The architecture astronaut. Beautiful diagrams detached from what ships. Influence is grounded in delivery; the moment your proposals stop surviving contact with production, your credibility evaporates.
• Winning the argument, losing the relationship. You can be right, prove it, and crush someone in the meeting — and they will never help you again. The relationship outlives this decision. Optimize for the relationship.
• "Because I said so." Pulling rank you don't have, or leaning on a title instead of a reason. It works exactly until it doesn't, and it trains people to comply rather than agree — which evaporates the moment you're not watching.
• Secret influence and back-channeling. Building support in private to ambush someone in public, or cutting deals that the affected people never see. It's effective once. Then it's known, and nobody trusts a closed door with you behind it.

The connective tissue across all of these is the same currency: every one of them spends credibility for a short-term win. For the day-to-day mechanics of cross-team work see internal collaboration, and for influencing the people above you specifically, managing up.

Self-Check

Before the next time you try to move a team that doesn't report to you:

If your title vanished tomorrow, would this still work?

If the answer is yes — it rests on credibility, on their incentives, on a structural change, on a coalition — it's real influence. If the only thing carrying it is the authority you don't actually have, it isn't going to hold.