Influence Without Authority: how FDEs find the 'currency' of people who don't report to them

Picture the second week of a deployment. The code is ready, but read access to the data is still sitting in a DBA’s queue. That person doesn’t report to you, or to your boss. You have no power to give orders, and one more reminder is unlikely to change anything.

Influence Without Authority wasn’t written specifically for FDEs, but few books come so close to that situation. Its publisher, Wiley, calls it the classic guide to getting what you need from people you don’t control.

For an FDE, that is daily work rather than a soft skill to save for later. Your project depends on people outside your organisation, and the book gives you a concrete way of thinking about them.

Two authors writing for a flatter world

Allan R. Cohen is Distinguished Professor of Global Leadership at Babson College. David L. Bradford is Senior Lecturer Emeritus in Organizational Behavior at Stanford Graduate School of Business, where he once ran the Executive Program in Leadership.

The third edition came out in 2017. Wiley sets the book against organisations that are increasingly flat and reliant on outside contractors, so that getting results means collaborating as peers, often across borders, time zones and organisational boundaries.

That sentence all but describes an FDE sitting at a customer site. The announcement for this edition also says plainly that the model works when influencing colleagues, bosses or customers.

First idea: don’t start by asking “who can force them?”

The book’s process has six steps, and the first is to assume that everyone can become an ally. It sounds like pleasant advice, but it completely changes what you do next.

If the DBA is an obstacle, the natural reflex is to escalate to the sponsor. You may get the access, but the person answering you next week will still be that DBA. If the DBA is a potential ally, the question becomes: what is this person trying to do well?

Escalation is sometimes still necessary, but it should be the last resort, once you truly understand what the other person needs.

Second idea: the currency belongs to the recipient

The core of the book is the Exchange Model: you get what you need by giving back something of value. What the other person values is their “currency”, and in Wiley’s wording, it is the direct tool for winning their cooperation.

Go back to the stuck ticket. The request “give me production read access so the pipeline can run” speaks only to your needs. Suppose that after a coffee you learn that what the DBA fears most is being woken in the middle of the night because a strange query has slowed the system.

Now the offer changes completely: use a read replica instead of the primary, limit yourself to 5 concurrent queries, run outside peak hours, take the alerts from these queries yourself, and have the access expire automatically after 30 days. You can still read the data, and the DBA gets exactly what they need: sleep.

Now try sending the same offer to the head of security. Suppose this person values being able to answer auditors. Query limits then say little. What needs adding is a dedicated account, access logs and a list of tables approved for reading.

So the first move at a customer is not to draft a request. Ask the person what frustrates them most in their week, and write your offer only after you have heard the answer.

Third idea: give and take runs through the whole project

The model rests on what social scientists call the Law of Reciprocity. In the six-step process, identifying the currency is only step four. Two tasks follow: looking after your relationship with the person, then persuading them through acts of give and take.

That order is worth noting, because currency is not a one-off trick. An FDE who once helped a DBA fix a backup script that kept failing won’t be starting from zero when asking for access in week six.

There is a trap here that FDEs should watch for: don’t pay in currency that isn’t yours. Promise a roadmap feature in exchange for access and the work gets unblocked today, but the debt lands on the product team. Offer what you can deliver yourself.

Which edition, and how to read it?

The book suits engineers who are working as FDEs or about to move from an SWE role, where power has always come from your code being right. People who have led cross-functional projects for years will probably find it familiar, though it is still useful as a vocabulary for teaching teammates.

Choose the third edition. The second is also from Wiley, but the newer one adds examples and material on remote, geographically dispersed teams. If you work with customers in other time zones, that is reason enough.

There is only one thing to remember about how to read it: go through the six steps in the authors’ order, trying them on a stuck ticket as you read. At the first step, write down the name of the person holding the ticket and treat them as a potential ally before reading on.

At step four, stop and write down that person’s currency. The last two steps, on relationships and give and take, put that answer straight to use. If you finish the book without having changed a single email, you might as well not have read it.

For your career, this skill only has value when you can prove it. When reading a job description, look for lines about working with stakeholders or having impact without direct management authority. On your CV, replace “good communicator” with a specific sentence: what you proposed to which team, to unblock which step of a deployment.

Have that story ready for interview questions about conflict with customers. The next time a ticket goes quiet, hold off on the fourth reminder and ask yourself what currency the person at the other end spends.