How to Lead Engineers Without Authority

You own the migration plan. The security review belongs to another team. So does the API contract you need, and so does the deployment pipeline. Nobody on any of those teams reports to you, each has its own roadmap, and your deadline is still your deadline. Learning to lead engineers without authority is the only way through.

This is the normal condition of senior engineering work, not an exception. Tech leads, staff engineers, and project leads spend much of their time getting results through people whose priorities they do not set. The good news is that influence without authority is a learnable skill with known mechanics, not a personality trait some people are born with.

If you drive work across team boundaries, as a tech lead, a senior engineer running a cross-team initiative, or a manager who needs help from outside your reporting line, the rest of this guide is the toolkit.

Why Authority Runs Out at the Org Chart

In 1959, social psychologists John French and Bertram Raven described the bases of social power: the different reasons people go along with someone else’s requests. Raven later added a sixth, informational power. The list maps neatly onto engineering organizations.

One caveat: the model describes where influence comes from, not what to do with it. Knowing you have expert power does not tell you how to use it on a reluctant team, which is what the rest of this guide covers.

The pattern in the last column is the whole argument. Legitimate, reward, and coercive power belong to your position, so they weaken or vanish at the org boundary. Expert, referent, and informational power belong to you, so they work across teams, levels, and even companies. Leading without authority means running mostly on the bottom three rows.

Build Credibility Before You Need It

Expert power accumulates slowly and drains fast. Every design that holds up in production, every review comment that catches a real bug, and every incident you handle calmly makes your next proposal harder to ignore. Every time you push an opinion beyond what the evidence supports, you spend some of it. Saying “I don’t know, let me check” costs far less than being confidently wrong.

Referent power runs on reliability and credit. Two habits do most of the work. First, do what you said you would do, by when you said you would do it, especially for small commitments. Second, give credit away publicly and absorb blame yourself. When a cross-team effort lands, name the security engineer who turned the review around in two days, in a channel their manager reads. When it slips, own the slip. People remember who made them look good.

Informational power comes from doing homework others skip. The person who arrives with current traffic numbers, a clear dependency diagram, or a summary of the last three incidents shapes the conversation, because everyone else is reasoning from memory.

Even when you do have formal authority, these habits often work better than using it. When I inherited a frontend team that had to learn backend, CI/CD, and DevOps work for a CMS migration, my first attempts to speed them up met resistance. What worked was understanding what motivated them and building their skills step by step, without demanding or leaning on my title. The influence came from credibility and patience, not from the org chart, and it lasted longer than an instruction would have.

If you manage people, these habits are also the foundation of servant leadership, which applies the same logic inside your own team.

Rewrite the Ask

Influence is won or lost in the request itself. Watch how one ask improves through three drafts.

Draft one: “Hey, could someone look at our migration plan sometime soon?”

No owner, no date, no reason, no size. It costs the other team nothing to ignore, so it gets ignored.

Draft two: “Can your team review our rollout plan by Thursday?”

Better: there is a date. But it still asks for an open-ended chunk of someone’s week and gives them no reason to prioritize it.

Draft three:

Priya, the migration reaches your rate limiter next sprint, and you’re the person who knows its limits best. Could your team review our rollout plan by Thursday, or, if that’s tight, give us 30 minutes to agree the smallest version that keeps your limits safe? It’s the last open dependency on the milestone, and it also closes the rate-limiter item on your team’s own risk list.

The third version names a specific person and why them, offers two acceptable sizes of help, attaches a date, and frames the outcome in terms of the other team’s own goals. None of it requires authority. It requires preparation. A reply like “Thursday is tight, but 30 minutes on Wednesday works if you bring current traffic numbers” is what a well-built ask usually earns.

As a checklist, every cross-team request should carry:

• the specific person and why they are the right one,
• exactly what you need, with a size and a date,
• a smaller fallback option they can accept instead,
• why it matters to them, not only to you.

When the Other Team Has No Reason to Help

A well-written ask works when the other team is broadly willing. The harder case is a team with its own commitments and no incentive to help at all. Take a concrete one: you need a change to the shared deployment tooling, and the platform team that owns it has a quarter full of cost-reduction work their director is measured on. Your request is, to them, pure distraction.

Four moves, in order:

1. Find what they are measured on, and look for overlap. If your change also reduces compute spend, or retires something they want to retire, lead with that. Even partial overlap changes the conversation from a favor to a shared goal.
2. Shrink the ask until it fits. Instead of “build this feature”, ask for an hour of design review while your team builds it as a contribution to their repository, following their standards and their final approval. Many platform teams will accept a well-made contribution they would never have prioritized building themselves.
3. Take something off their plate. Offer a trade they actually value: your team migrates off the deprecated API they have been chasing everyone to leave, or takes on documentation they keep postponing.
4. If it still cannot fit, escalate the priority, not the people. Go to the leader both teams share, with the platform lead’s knowledge, and ask a clear question: “Our launch needs X; their quarter is committed to Y. Which matters more this quarter?” That is a legitimate question about priorities, and the platform team is better off having it answered than being pressured.

Research on influence tactics points the same way. Gary Yukl and J. Bruce Tracey’s 1992 study of managers found that rational persuasion, inspirational appeals, and consultation were the tactics most likely to produce genuine commitment, while pressure and appeals to authority tended to produce, at best, reluctant compliance. Each move above is a version of consultation or rational persuasion. None relies on pressure.

Map Who Can Help or Block You

The PMBOK Guide treats stakeholder identification as a core activity: before you engage people, list who can affect the work, what they care about, and how much influence they hold. For a cross-team engineering effort, a one-line-per-person map is enough:

INFLUENCE MAP
Name | Team | Can affect | Cares about | Influence (H/M/L) | Interest (H/M/L) | Last contact

Habit: one short conversation or written update per high-influence person
each month, whether or not you need something from them.

The map pays off in timing. Trust with the security reviewer has to exist before the audit crunch, not during it. A monthly five-minute update when you need nothing is what makes the urgent request in month four land well. For a fuller treatment of classifying and engaging stakeholders by power, interest, and current attitude, see how to manage difficult stakeholders.

Separate Facts From Interests

When another team pushes back, work out what kind of disagreement you are in. If it is about facts (will this design hold at peak traffic?), settle it with data, a prototype, or a load test. Persuasion is the wrong tool. If it is about interests (their roadmap is full, and your request displaces their own commitments), it is a negotiation, and the principled approach from Fisher and Ury’s Getting to Yes applies: focus on what each side actually needs, not on stated positions, and look for options that serve both.

Mixing the two wastes credibility. Arguing harder about a trade-off that is really about the other team’s capacity just makes you look unwilling to listen. Offering to share headcount on a disagreement that is really about technical risk looks like bribery.

If the disagreement has become personal, stop persuading altogether and use the approaches in how to handle conflict on an engineering team.

When to Stop Persuading and Escalate

Influence is the right tool most of the time, but not all of the time. Escalate when:

• The dependency is hard and the date is fixed. If a refusal would sink the project, try the direct ask once, then escalate early and in writing. Late escalation is worse for everyone.
• Legitimate authority already exists. Security, compliance, and regulatory requirements carry their own authority. Your job is to sequence and explain them, not to negotiate whether they apply.
• The facts are against you. If the data says the other team is right, change your plan. Spending trust to win an argument you have lost on the merits costs you twice.

When you escalate, do it transparently. Tell the other lead first: “I don’t think we can resolve this between us, so I’m going to ask our directors to decide by Friday.” Escalating behind someone’s back turns a colleague into an opponent for a long time.

Reduce the Need for Influence

The best long-term move is structural. DORA’s research on loosely coupled teams finds that teams able to change and deploy their systems without waiting on other groups deliver faster and more reliably. Every cross-team dependency you design out, through clearer service boundaries, self-service platforms, or published API contracts, is one less negotiation your tech leads have to win every quarter.

FAQ

How do you lead engineers without authority?

Build the power bases that do not depend on your title: expert power, from a track record of sound technical judgment; referent power, from reliability and shared credit; and informational power, from knowing the facts others need. Then make specific, dated, easy-to-accept requests, and escalate only when a hard dependency is at risk.

What is expert power in engineering?

Influence earned from demonstrated technical judgment: design reviews that catch real problems, designs that survive production, incidents handled calmly. It grows when you are right in public and admit uncertainty honestly, and it shrinks every time you push an opinion beyond what the evidence supports.

What are the bases of power?

French and Raven named five in 1959: legitimate, reward, coercive, expert, and referent. Raven later added informational power. The first three attach to your position; the last three attach to you, so they work across team and organizational boundaries.

How do you influence another team’s priorities?

Learn what that team is measured on, then frame your request in those terms, with a specific owner, a date, and a smaller version they can accept. Offer something useful in return where you can. If the dependency is critical and they still cannot help, tell them you are escalating and do it in writing.

Leading Engineers Without Authority Is a Long Game

When you lead engineers without authority, every review, thank-you note, and kept promise is an investment in the next request you will need to make. Leaders who invest steadily rarely need to escalate; leaders who only show up with asks find every request harder than the last. The other guides in leading teams cover the related skills of motivation, conflict, and accountability.

Last updated on 10 October 2026