Influence engineers, managers and vendors who do not report to you by understanding what they value and building trust.
Why it matters
Most IT project managers lead people who do not report to them. The developers report to an engineering manager, the database administrator belongs to the infrastructure team, the security reviewer works for the CISO and the vendor answers to their own account manager. You cannot order any of them to do anything. Yet you are accountable for the project getting delivered.
This is called leading without authority, and it is the core skill of the job. The good news is that it can be learned. It rests on three things: understanding what other people value, building trust before you need it, and making it easy for people to help you.
Power you do have
You may not have positional power, but you usually have other sources of influence:
- Information. You see the whole project. You know what is blocked, what is late and what the sponsor cares about.
- Relationships. You talk to everyone. People who trust you will go out of their way for you.
- Expertise. Being good at planning, running meetings and removing obstacles makes people want to work with you.
- Reflected authority. The sponsor's goals are behind you, but use this rarely. "The VP said so" works once and costs trust.
Exchange: what does each person value?
A useful idea from Allan Cohen and David Bradford's work on influence is that cooperation runs on exchange. People help those who help them, though the "currency" is not always obvious. Before you ask someone for something, ask yourself what they value.
| Person | What they might value | What you can offer |
|---|---|---|
| Senior developer | Interesting problems, fewer interruptions, being heard on design | Protect focus time, bring them into decisions early, credit their work publicly |
| Engineering manager | Predictable demands on their team, career growth for their people | Give early notice of needs, a clear scope, visibility for their team's work |
| Security reviewer | Being involved before it is too late to fix things | Invite them to design reviews, give them time in the plan |
| Vendor account manager | A smooth, referenceable customer | Clear requirements, prompt decisions, fair escalation |
When you frame a request in terms of what the other person values, it stops being a favour and becomes a fair trade.
Building trust before you need it
Trust comes from reliability (you do what you say), honesty (you share bad news early) and care (you treat people's time and goals as real). Practical habits:
- Meet each key person one to one early in the project, before there is a problem. Ask what success looks like for them and what worries them.
- Keep small promises: send the notes when you said you would.
- Never surprise anyone in public. If a status report will show their work as red, tell them first.
- Give credit loudly and take blame quietly.
Making it easy to say yes
A clear, specific request is much easier to agree to than a vague one.
Weak: "Can someone look at the integration issue?"
Strong: "Priya, the records API returns a timeout on the bulk export, which blocks the clinic data load planned for 14 March. Could you spend an hour with the vendor's engineer on Thursday to diagnose it? I have booked the call and sent them the logs."
The strong version says what the problem is, why it matters, exactly what is needed, and what you have already done to reduce the effort.
Worked example: getting a busy team's time
On the Northside Clinics project, the portal needs a change to the single sign-on configuration. That belongs to the identity team, who are busy with an audit and have no reason to prioritise you.
- Understand them. You learn their audit is about access reviews, and their manager, Tom, is worried about finishing it on time.
- Find the exchange. The portal will remove 300 shared clinic logins, which reduces Tom's audit findings. That is something Tom values.
- Make the ask concrete. "The portal can retire the shared logins at all 12 clinics. To do that we need one SSO application set up by 1 April, about four hours of work. Our developer can draft the configuration for your review so your team only checks and applies it."
- Follow through. Send the draft on time, thank the team in the steering report, and mention the retired logins in Tom's audit.
When influence is not enough
Sometimes a conflict of priorities cannot be solved between peers. Escalation is then a normal, healthy step, not a failure. Do it well:
- Tell the other person first that you plan to escalate, and why.
- Escalate the decision, not the person: "Team A and the portal both need Priya in March. Which comes first?"
- Bring options and the impact of each.
Common mistakes
- Using the sponsor's name as a threat.
- Asking for help only when you are in trouble.
- Vague requests that make the other person do the thinking.
- Treating engineers as resources to be scheduled rather than experts to be consulted.
Quick recap
- Most project leads have no direct authority; influence comes from information, relationships and expertise.
- Find what each person values and frame requests as a fair exchange.
- Build trust early with reliability, honesty and no public surprises.
- Make requests specific and low-effort; escalate decisions, not people, when needed.
Try it
Open the Do tab and plan how you would influence one real or realistic person who does not report to you.