Nobody reports to me. I do not control anyone’s performance review, I cannot assign work, and I have zero hiring or firing authority. And yet, my job is to drive technical direction across multiple teams, align engineers on shared approaches, and sometimes convince people to throw away months of work and start over.
This is the central paradox of the staff engineer role: you have enormous responsibility and almost no formal authority. If you cannot influence without authority, you cannot do the job. Full stop.
I learned this the hard way. Early in my staff journey, I had a technically correct proposal for standardizing a frontend build pipeline. I presented it to the affected teams with the confidence of someone who knew they were right. The proposal was sound. The teams ignored it — not because they disagreed with the technical merits, but because I had not invested in the relationships and trust needed to make adoption feel safe rather than imposed.
“Staff engineers don’t just solve hard technical problems; they make sure that the right problems get solved, in a way that allows the people around them to grow.” — Pat Kua
The Three Currencies of Influence
After years of operating without formal authority, I have identified three currencies that staff engineers trade in. You need all three — any one alone is insufficient.
| Currency | How You Earn It | How You Spend It | How You Lose It |
|---|
| Trust | Consistency, competence, honesty about being wrong | Proposing significant changes that require buy-in | One political move, taking credit for someone else’s work, or dismissing a junior engineer’s concern |
| Expertise | Maintaining genuine technical depth, shipping real code, reviewing thoughtfully | Making authoritative recommendations in your domain | Faking knowledge, proposing solutions you could not implement yourself |
| Relationships | Attending other teams’ demos, reviewing their docs, informal coffee chats, helping people with no expectation of return | Navigating complex cross-team decisions, building coalitions | Being transactional, only showing up when you need something |
The single best relationship investment: help someone else succeed with no expectation of return. Review their RFC thoroughly. Pair with them on a hard problem. Champion their work in a meeting they are not in. These deposits compound over time into deep trust.
Navigating Resistance
Not everyone will agree with your direction, and that is healthy. Resistance is not the enemy — unexamined resistance is. The key is understanding the type of resistance and responding appropriately.
| Resistance Pattern | What It Looks Like | Underlying Cause | How to Respond |
|---|
| The Skeptic | ”I don’t think this will work because…” | Genuine technical concern | Engage seriously — they might be right. Address concerns with data or prototypes. |
| The LGTM-but-won’t | ”Sounds great!” then does nothing | Agrees in principle, disagrees on priority | Make the cost of inaction visible. Connect to their team’s goals. Make adoption easy. |
| The Passive Blocker | Missed meetings, unanswered docs, endless “one more question” | Disagrees but avoids confrontation | Force the explicit conversation: “I sense hesitation — what concerns you?” |
| The Turf Protector | ”Our team already handles this” | Perceives threat to scope or autonomy | Acknowledge their ownership. Frame your proposal as supporting, not replacing. |
| The NIH Engineer | ”We should build our own instead” | Pride in craft, distrust of external solutions | Channel energy into evaluation criteria. Let them prove their case — sometimes they are right. |
Never confuse resistance with malice. In my experience, 95% of resistance comes from legitimate concerns — different priorities, incomplete information, past trauma with similar initiatives, or genuine technical disagreement. Assuming bad intent poisons the well permanently.
Running Effective Working Groups
When a technical decision spans multiple teams, working groups are the primary mechanism for building alignment. A working group is a temporary, cross-team group formed to make a specific decision or drive a specific initiative.
| Element | What Good Looks Like | What Bad Looks Like |
|---|
| Charter | Clear problem, defined scope, explicit end date | Vague mandate with no finish line |
| Membership | One representative per affected team with decision-making authority | Observers, delegates without authority, or the wrong people |
| Duration | Time-boxed to weeks, not months | Runs indefinitely — becomes a committee where momentum goes to die |
| Artifacts | Written summary after every meeting; decisions documented | Verbal agreements that evaporate by the next sync |
| Decision protocol | Agreed upfront — consensus, majority, or lead-decides-after-input | Undefined, leading to endless revisiting of settled decisions |
In a small team, working groups can be informal — a Slack thread and two meetings usually suffice. In a large organization, you need formal charters, weekly syncs, and monthly stakeholder updates. Match the formality to the organizational complexity.
Show, Don’t Tell
The single most effective influence tactic I have found: build a prototype. A working prototype is worth a thousand slides. Engineers are rightfully skeptical of abstract proposals — they have seen too many beautiful architectures that fell apart on contact with reality.
When I proposed a new component library approach in one project, I did not write a ten-page RFC first. I built a working prototype over two weeks — three components, proper types, documentation, and a migration example showing how an existing component could be ported. Then I wrote a short RFC pointing at the working code. Teams could evaluate a real thing rather than an idea, and adoption started before the RFC was formally approved.
Choosing Your Battles
You cannot influence everything simultaneously. Staff engineers who try to drive every technical decision burn out and lose credibility — every recommendation carries less weight when you are recommending everything.
| Battle Type | Strategy |
|---|
| High impact, low controversy | Just do it. Write the proposal, build the prototype, drive adoption. |
| High impact, high controversy | Invest heavily. Build alliances, gather data, prototype, be patient. These are worth fighting for. |
| Low impact, low controversy | Delegate. Let someone else lead it as a growth opportunity. |
| Low impact, high controversy | Let it go. Spending political capital on low-impact battles is the most common staff engineer mistake. |
