The central challenge of the staff engineer role is that the impact you’re expected to have — shaping technical direction, driving alignment across teams, changing how engineering gets done — requires influence, not authority. You can’t direct anyone. You don’t have a reporting line. You get things done by persuading people who don’t report to you, earning trust with stakeholders who already have strong opinions, and navigating organizational dynamics that nobody explicitly documented.
This is a learnable skill. It’s also the skill most engineers underinvest in, because it’s invisible in the way technical skills aren’t. Nobody reviews your influence patterns the way they review your code. Here’s how to develop it deliberately.
Why “Influence Without Authority” Is a Distinct Skill
Most engineers learn to get things done by being right and demonstrating it. You write better code. You catch bugs. You propose the right architecture. Over time, being demonstrably correct earns you credibility, and credibility earns you latitude to make decisions.
This model breaks down at the staff level for two reasons.
First, most disagreements aren’t about who’s more technically correct. They’re about different weights on competing values: speed vs. reliability, flexibility vs. simplicity, ownership vs. consistency. Both sides can be technically right. The engineer who “wins” these debates isn’t always the more technically skilled one — it’s often the one who understands what the other side actually cares about.
Second, the things staff engineers need to change are usually systemic. You’re not changing one piece of code. You’re changing how a team approaches a category of problem, how two teams coordinate, how engineering priorities get set. Systemic change requires sustained influence across multiple people over time. It can’t be won in a single design review.
Build Real Understanding Before Proposing Anything
The most common mistake in cross-team influence is proposing before understanding. You see a technical problem, you have a solution, you bring it to the stakeholders. This feels efficient. It’s usually counterproductive.
People can tell when you’re proposing to a problem you don’t fully understand. They can tell when your solution optimizes for your team’s situation rather than theirs. And when that happens, the conversation becomes adversarial even before it starts — you’re defending a proposal instead of solving a shared problem.
The alternative: spend time genuinely understanding the constraints, incentives, and concerns of the people you’re trying to influence. What does this team actually care about? What have they tried before and why didn’t it work? What are they evaluated on? What does their tech lead wake up worried about?
This isn’t just relationship-building (though it is that too). It gives you information that makes your proposal substantially better. A solution that accounts for their operational reality is much easier to agree to than one that creates new work for them.
The Mechanics of Technical Influence
When you’re ready to push for a change, the mechanics that work are different from what works in one-on-one technical discussions.
Write it down. Spoken proposals are easy to forget, misremember, and selectively engage with. Written proposals — even short ones — create something the other party has to respond to explicitly. They also let you be precise in a way that verbal conversations often aren’t. If someone disagrees with your written proposal, they have to say what specifically they disagree with, which surfaces the real point of contention.
Frame around shared goals, not your preferences. “I think we should standardize on X” is a weak frame. “The current inconsistency creates about 40% of our on-call incidents — standardizing on X is the highest-leverage way to reduce that” is stronger. The second frame names a goal the other side likely shares and positions your proposal as a means to that goal rather than an expression of your technical taste.
Make the cost of the status quo visible. Most technical changes fail not because they’re bad ideas but because they never reach the threshold of urgency. Nobody moves to fix a problem they’re not actively feeling. Your job is often to surface the ongoing cost of the current state: incident patterns, developer time, technical debt that compounds over time. Concrete data about the cost of doing nothing is more persuasive than any amount of argument about the benefits of change.
Propose incrementally. “We should replace the entire authentication system” rarely gets traction. “We should run a 30-day experiment where we migrate one service to the new approach and measure the operational impact” is harder to say no to. Incremental proposals reduce the perceived risk of agreement. They also generate evidence — which is the best possible input into the next incremental proposal.
Working With Skeptics
Most non-trivial technical changes have at least one influential skeptic. Trying to go around them rarely works — it creates an adversary who can undermine the initiative from the side. Working with them is more effective and usually produces a better outcome.
The approach: genuinely engage with their concerns rather than defending against them. “What would have to be true for this to be a good idea from your perspective?” is a useful question. Not as a rhetorical move, but as a real question. Their answer either surfaces a legitimate constraint you should account for, or it surfaces a preference that can be addressed, or it clarifies that the disagreement is about values rather than facts.
If it’s a values disagreement — they weight something you’re not weighting — the conversation becomes clearer when both sides name that explicitly. “I think we’re weighting developer speed vs. operational reliability differently” is a more honest and productive frame than continuing to argue over the technical details as a proxy for the values disagreement.
Earning Long-Term Influence
Single proposals win or lose. Long-term influence is built differently.
Be right about the things you’re confident about. Early in any relationship, the best way to earn influence is to have good judgment consistently. When you flag a risk and the risk materializes, people remember. When you call an architecture problem six months before it causes an outage, that builds credibility that carries into your next proposal.
Tell people when you’re wrong. Staff engineers who acknowledge mistakes publicly earn more trust than those who don’t. It signals that your assessments are calibrated — that when you say something is a problem, you’ve actually thought about it, rather than just asserting confidence.
Give credit generously. When a technical change you advocated for succeeds, attribute success to the people who executed it. They did the work. They took the risk. Your role was to create alignment and remove obstacles. Publicly acknowledging that earns goodwill that compounds.
Follow through on what you commit to. This sounds obvious, but the most common trust failure in cross-team influence is engineers who raise concerns, participate in design, advocate for a direction — and then disappear when implementation gets hard. If you’re going to influence a decision, you’re taking on some accountability for how it turns out. Show up for the hard parts.
The Influence Map
One practical tool: periodically map the key stakeholders for the technical direction you’re working on. For each person:
- What do they care most about? What are their actual incentives?
- What’s their current stance on the change you want?
- What would move them toward alignment?
- Who influences them that you might be able to work through?
This isn’t manipulation — it’s just taking seriously that different people have different perspectives and planning your communication accordingly. The engineer who treats every stakeholder conversation as an opportunity to repeat their argument loses. The one who figures out what each stakeholder actually needs to hear makes more progress.
VividMap helps you track the influence you’re building across teams over time — so the patterns in how you create change are visible, not just the moments when something was hard. See how it works.