Building Influence Without Authority, A Tech Lead's Guide

TL;DR — Influence without authority is built on three things: credibility you’ve earned through delivered work, written arguments that travel without you, and a network of trust that compounds over years. There are no shortcuts, but there is a process.

The frustrating part of being a tech lead or staff engineer is that the job description usually requires you to move things that you don’t formally control. You need the platform team to ship a feature. You need three other teams to align on an API contract. You need an executive to fund a migration whose ROI is hard to articulate. None of these people report to you. Most of them don’t even know who you are.

This is the influence-without-authority problem, and it’s the defining challenge of the staff-plus career path. The engineers who solve it move from senior IC to staff to principal. The ones who don’t end up frustrated, doing technically excellent work that nobody adopts.

I’ve been on both sides of this. Five years ago I was the senior engineer who couldn’t understand why my technically correct proposal got ignored. Three years ago I figured out the part I was missing. Today I help other engineers shorten that learning curve. This post is the playbook I wish I’d had then.

Why authority isn’t actually the lever

Even people with authority don’t really get things done through authority. Telling someone what to do is the lowest-leverage form of influence. It works once, maybe twice, and then resentment compounds. The engineers who appear to have lots of authority got it by building influence first, and they spend the authority sparingly because they know how expensive it is to use.

So the framing of “I’d be able to do this if I had authority” is usually wrong. Authority is a small multiplier on influence. If your influence is near zero, authority will get you compliance but not commitment. If your influence is high, you barely need authority at all.

The mental shift: stop thinking of influence as a workaround for not having authority. Start thinking of it as the actual currency of getting things done across boundaries. Authority is a side channel.

The three pillars of real influence

Credibility, earned and specific

Credibility is the foundation. Without it, nothing else works. But credibility is more specific than people realize. It’s not “are you a good engineer?” It’s “do I trust your judgment on this particular kind of question?”

Your credibility is a portfolio of small bets that paid off. The architect who called the database choice correctly three years ago has credibility on database choices, not on frontend frameworks. The engineer who wrote the incident retrospective that everyone learned from has credibility on operational risk, not on hiring. Treat your credibility as domain-specific and build it deliberately in the domains you want to influence.

Concrete moves that build credibility:

1. Predict an outcome in writing before it’s known. Be specific. “I think this migration will take three quarters and the hardest part will be the cutover.” When you’re right, you’ve earned credibility. When you’re wrong, write the postmortem on your own thinking. That earns more.
2. Take a position publicly on a contested technical question with reasoning, not just opinion. Even if you lose the argument, you’ve shown you can think.
3. Ship one thing per quarter that other teams notice. Not feature work. Something cross-cutting (a library, a guide, an internal tool) that solves a real problem for engineers outside your team.

Written argument that travels

The single highest-leverage skill for influence is writing. Not “be a good writer” in some abstract literary sense. Specifically, write arguments that can be circulated without you in the room and still convince a reasonable person.

This is harder than it sounds. Most engineering writing fails one of three tests. The argument doesn’t survive without context. The structure is meandering, so the reader gives up. Or the writer hedges so much that no clear position is taken.

The structure I use for any argument I want to influence with:

## TL;DR
One paragraph. The position, the main reason, the ask.

## What I'm proposing
Two paragraphs. Specific enough that a reader could implement it.

## Why this matters now
What's the cost of waiting?

## Three reasons to do this
Numbered. Each one with evidence.

## The strongest argument against
Steelman it. Then answer it.

## What this would look like in practice
A concrete example, with numbers if possible.

## What I'm asking for
A specific decision, from specific people, by a specific date.

A doc like this, two to three pages, well-circulated, will move more than ten meetings. The reason it works: it lets people engage on their own time, in their own format, with the version of you that thought hardest, not the version of you that’s tired in a 4pm meeting.

Trust network, built over years

The third pillar is the slowest to build and the most durable. A trust network is the set of people across the org who will pick up your message and amplify it because you’ve earned that from them.

You don’t build a trust network by networking. You build it by doing favors that compound. Specific favors that I’ve watched build trust networks:

• Helping another team debug something painful at midnight without being asked.
• Sending the credit upward when something cross-team goes well.
• Spending half an hour explaining your team’s roadmap to a new lead so they can plan around it.
• Reading another team’s design doc carefully and giving substantive feedback before they ship.
• Mentoring a junior engineer on another team because their lead is overloaded.

Each of these is small. Cumulatively, over two or three years, they create a network of people who will return the favor without keeping score. That network is the thing that turns “can you support this proposal in the meeting tomorrow” into a yes instead of a maybe.

If you’re new in a role, the trust network is your slowest-building asset. Start now. The first six months of any new role should include at least one trust-building action per week.

A four-step framework for moving a specific initiative

Let’s get concrete. Say you want to drive a cross-team migration off a legacy system. You don’t manage any of the teams involved. How do you actually do it?

Step 1, map the decision

Before you talk to anyone, write down the answers to:

• Who actually has to say yes for this to happen? (Usually fewer than five people.)
• What does each of them care about most?
• What’s their current position, supportive, neutral, skeptical, or opposed?
• Who do they trust on questions like this?

If you can’t answer the fourth question, you have a discovery problem. Go talk to people who know the deciders better than you do.

Step 2, build the case in writing

Use the structure from earlier. Steelman the strongest argument against. Address it explicitly. If you’re not willing to write down the opposing view fairly, you’re not ready to make the case.

Step 3, presell, don’t pitch

Never pitch a new idea in a meeting where the decision will be made. Always presell. Take the doc to each decider individually, in advance, and get their reaction. Adjust the doc based on what you learn. By the time the meeting happens, the decision should already be effectively made. The meeting is the ratification, not the deliberation.

This is the single biggest mistake new tech leads make. They show up to the meeting with a brilliant proposal that nobody has seen, expect to convince everyone in forty-five minutes, and walk out confused about why it got tabled. Of course it got tabled. Nobody had time to think.

Step 4, attribute the win

When the thing happens, attribute the credit to everyone who supported it. Publicly. In writing. By name. The deciders who said yes will remember next time. The skeptics who eventually came around will remember even more. This step costs you nothing and pays dividends for years.

The skills that compound

A few skills are unusually high-leverage for influence. They take years to develop. Start now.

Asking better questions

The engineers I respect most ask better questions than I do. Not “gotcha” questions, but the kind of question that reframes the conversation. “What would have to be true for this to be the right call?” “If we did this and it failed, what’s the most likely reason?” “Who’s the person on this team who’s most worried about this?”

Good questions show that you’ve thought, that you take the other person seriously, and that you’re trying to understand rather than to win. All three are influence multipliers.

Disagreeing without diminishing

This is rare and valuable. The ability to disagree strongly with someone’s position while preserving their dignity, ideally while making them feel smarter for having engaged with you. The book Crucial Conversations is the best practical treatment I’ve read of this.

The basic move: separate the position from the person. “I disagree with this approach, and here’s why” is fine. “You’re wrong about this” is not. The reasoning is identical. The reception is night and day.

Being changeable

This is the one that took me longest to learn. The most influential people I know are not the most stubborn. They’re the most willing to change their minds in public when the evidence warrants it. This is counterintuitive. You’d think changing your mind would erode credibility. It doesn’t. It builds it, because it signals that your positions are honest assessments rather than ego defense.

For more on this, The Trusted Advisor by Maister, Green, and Galford is worth your time. The framing is from consulting but the principles transfer directly to engineering leadership.

Common Pitfalls

• Confusing being right with being persuasive. You can be technically correct and lose every argument. The org doesn’t run on correctness, it runs on shared understanding. Build the shared understanding.
• Hoarding information for leverage. This works once and burns the network for years. Share generously. Influence comes from being a node people route through, not a bottleneck they route around.
• Ignoring the social fabric. The skip-level who blocked your proposal isn’t being irrational. They’re protecting something you don’t see. Find out what.
• Trying to influence everyone. Pick the five people whose support actually matters and focus there. Spreading thin produces no movement on any front.
• Going around the org chart. Sometimes necessary, always expensive. The lead you bypassed will remember for two years. Do it only when the stakes truly justify it, and own the relationship repair afterward.

When This Goes Wrong

Your proposal keeps getting tabled. You’ve shipped a great doc, presold it, and it still doesn’t move. Diagnosis: usually one of the deciders is signaling discomfort they’re not voicing. Ask each one individually, “what would have to change for you to fully support this?” The honest answer often reveals a constraint nobody named in the meetings.

You have credibility but no allies. People listen when you talk but don’t pick up your work when you’re not in the room. Diagnosis: you’ve built credibility but not trust. Credibility is “they trust your judgment.” Trust is “they’d do something for you.” The fix is the favor flywheel from the trust network section. It takes time.

You burned out trying to influence. Six months of pushing a rock uphill and you’re exhausted. Diagnosis: you picked the wrong battle, or the wrong moment, or both. Sometimes the org isn’t ready. Sometimes the political alignment is just wrong. Step back. Pick a smaller battle you can win this quarter. Live to fight the bigger one next year. I cover this further in Talking to Executives About Technical Risk, A Practical Framework.

Wrapping Up

Influence without authority isn’t a hack. It’s the real shape of senior engineering work. The people who pretend it’s optional are usually the people who never made it past senior IC. The people who treat it as the core skill of the staff-plus career are the ones who build careers that compound.

The frameworks above (credibility, writing, trust network, the four-step initiative process) are not theory. They’re what I actually do. They’re slow. They work. The work is to start now, on something small, and let it compound over years.

You don’t need permission. You need patience and a written argument.