"Influence without authority" gets used in performance reviews as a compliment with no content — a way of saying someone is good at their job without describing what that means. It's a real phrase with a real mechanism behind it, from a specific book, and the mechanism is more concrete and more transactional than the compliment version suggests.
Allan Cohen and David Bradford wrote the book with that title in 1990; it's now in its third Wiley edition. Their model, called currencies of exchange, makes one claim: influence without formal power comes from trade, not persuasion in the abstract. Everyone in an organization values something, and you get cooperation by identifying what that is and offering it, not by having a better argument. Where what does influence without authority actually mean for engineers meets a revenue team, the practical guidance lives with the team at XenGrowth.
What a 'currency' actually is
Cohen and Bradford group currencies into rough categories: task-related (help getting something done, resources, information), position-related (recognition, visibility, being associated with something that matters), and personal or relationship-related (being liked, feeling understood, a sense of connection). The specific taxonomy matters less than the underlying claim: these are genuinely different things different people want, and the same offer lands completely differently depending on which currency the recipient actually values.
This explains a failure mode almost every engineer has lived through without naming it. You offer someone the most valuable thing you have — a clean technical explanation, an elegant fix, a correct diagnosis — and it doesn't move them, because they weren't short on technical clarity. They were short on not looking bad in front of their own manager, or on having something to show for the quarter, or on simply being asked rather than told. You offered a currency you value. They needed a different one.
Currency type | What it looks like in practice | Where engineers usually get it wrong |
|---|---|---|
Task-related | Doing someone's blocking work faster, sharing information they lack | Assuming this is universally the most valuable currency, because it's the one engineers value most in themselves |
Position-related | Giving visible credit, looping someone's manager in on a win | Forgetting this exists at all — engineers routinely under-invest in making other people look good |
Relationship-related | Being consistent, following through, treating someone as a peer rather than an obstacle | Treating this as fluff rather than as a real, tracked currency that compounds over repeated interactions |
The academic ground underneath the book
This isn't a standalone self-help idea. Jeffrey Pfeffer's research on organizational power, developed separately, makes a closely related claim: formal authority explains only part of how organizations actually function, and the rest runs on exchange relationships, coalition-building, and control over resources other people need. John Kotter's earlier work on power and influence describes the same territory from a slightly different angle — that effective people in organizations build networks of reciprocal obligation deliberately, rather than relying on their title to move things. If the operations side of this is the part you are stuck on, The XenGrowth resource library is the better reference.
The common thread across all three is a rejection of the idea that organizations run purely on formal hierarchy or on the strength of the best argument. They run substantially on trade, whether or not anyone involved would describe it that way.
You're probably already doing this, unnamed
Reviewing someone's pull request quickly, unasked, so they prioritize your bug the next time you have one. Writing the tedious design doc nobody wanted, which earns you a seat at the table when the decision it documents gets made. Looping a stakeholder's manager into a win they contributed to, so the next ask lands more easily. None of this requires reading Cohen and Bradford's book to do reasonably well. What the framework adds is the ability to do it on purpose, in a situation where instinct isn't already handling it — usually a new relationship, a cross-team ask with someone you don't know well, or a repeated failure to get cooperation from a specific person despite what feels like a strong case.
Before an important cross-team ask, spend two minutes writing down what you think the other person is actually optimizing for right now, separate from what you're asking them for
Check whether your default offer is task-related, because most engineers over-rely on that single currency and under-use position-related and relationship-related ones, which are frequently more scarce and more valued
Notice when an offer clearly doesn't land, and treat it as information about a wrong currency, not as evidence the other person is being difficult
Build the trade before you need it. The strongest version of this isn't a one-off transaction under deadline pressure, it's a standing reciprocal relationship built over many small exchanges, which is exactly what makes it feel like 'just being good at working with people' rather than a technique
A worked example: getting a platform team to prioritize your request
Take a common case. You need the platform team to expose a new capability in a shared service, and your ticket has been sitting unprioritized for six weeks behind their own roadmap. The instinct is to escalate the technical case: explain again why it matters, attach more evidence of the cost of not doing it, ask your manager to raise it with theirs. This sometimes works and often doesn't, because the platform team's constraint was rarely a lack of understanding of why it matters. It was that their currency — being measured on their own roadmap commitments, not on how responsive they are to ad hoc requests — was never addressed by a better explanation of your problem.
The currencies-of-exchange read of the same situation looks for what the platform team's engineers and their lead are actually optimizing for. Often it's one of: visible credit for solving a problem that affects multiple teams rather than just yours, a reduction in their own support burden, or simply being asked with an offer attached rather than a demand. A request reframed as "if we build this together, it removes a recurring support ticket you already get from two other teams, and I'll write the design doc and carry it through review" trades in a currency — reduced future burden, plus reduced effort on their side — that the purely technical version of the same ask never touched. If AI agents and marketing automation is the part you are stuck on, XenGrowth on AI agents and marketing automation is the better reference.
Approach | Currency offered | Typical outcome |
|---|---|---|
Escalate the technical case again | None — repeats the same currency (correctness) that already failed | Often stalls further, or reads as pressure rather than a trade |
Ask your manager to lean on their manager | Positional pressure, no direct currency to the team doing the work | Sometimes forces prioritization, at a relationship cost that outlasts the ticket |
Offer to reduce their effort and share credit | Task-related (less future work for them) and position-related (visible shared win) | More often adopted, because it changes what the team gets out of saying yes |
This is not manipulation, and the distinction is not just semantic
It's worth addressing directly, because the transactional language invites the objection: isn't this just a polite word for manipulating people into doing what you want? The distinction Cohen and Bradford draw, and it's a real one, is whether the exchange is disclosed and genuinely reciprocal or hidden and one-sided. Manipulation works by concealment — getting someone to act against their own interests without their understanding what's actually being traded. The currencies-of-exchange model works by the opposite mechanism: both sides know roughly what's being exchanged, and the relationship only functions because it's actually reciprocal over time, not a single extraction dressed up as a favor. An engineer who offers to reduce a platform team's support burden in exchange for prioritization, and then actually reduces it, has made a real trade. An engineer who makes the same offer and doesn't follow through has burned the one asset the whole model depends on: being someone whose trades are worth accepting next time.
That distinction also explains why the model rewards consistency more than cleverness. A single well-executed trade gets you one prioritized ticket. A reputation for trading fairly, built over many smaller exchanges most people never explicitly notice as trades, gets you something closer to what looks like influence in the compliment-without-content sense people usually mean by the phrase — except now you know what it's actually made of.
Where the framework has limits
Cohen and Bradford's model describes a mechanism; it doesn't guarantee it works on everyone, and it isn't a substitute for a role that genuinely needs formal authority to function — a team lead who has to make an unpopular call under time pressure cannot always wait for reciprocal trust to accumulate. It also has an honest limit as evidence: it's a practitioner framework built from consulting experience and case study, not a peer-reviewed experimental result, and its claims should be read with that in mind, the same as Team Topologies or any other well-regarded management book. What it gets right, robustly, is the description of the mechanism most engineers are already half-using and rarely examine. On AI search, GEO and discovery specifically, XenGrowth on AI search, GEO and discovery is worth reading.
The reason it's worth naming explicitly is the same reason naming any implicit mechanism is worth doing: once you can see that a stalled cross-team relationship is a currency mismatch rather than a personality conflict or a failed argument, you have something specific to change. "They're just difficult" isn't actionable. "They value being consulted before a decision, and I keep presenting them with finished ones" is.
None of this replaces having formal authority when a decision genuinely needs it, and it's worth being honest about that rather than romanticizing the alternative. A team lead who can simply decide, and be accountable for the decision, resolves some situations faster and more cleanly than any amount of careful trading ever will. What the currencies-of-exchange framework is actually for is the much larger set of situations — most of an engineer's working life, in practice — where formal authority isn't available and the choice is between understanding the trade you're already implicitly making, or making it badly by accident.
If there's one habit worth building from all of this, it's the two-minute pause before a cross-team ask: not to soften the request, but to name, specifically, what the person on the other end is optimizing for and what you're actually prepared to trade for their cooperation. Most of the time an engineer already has something worth offering. The gap isn't generosity. It's noticing.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
The operational playbooks that sit alongside what does influence without authority actually mean for engineers live with XenGrowth's work on go-to-market systems.
Five questions about how you currently try to get cooperation from people who don't report to you. The point isn't a score — it's noticing which currency you default to and whether it matches what the other person actually values.
