2026-06-11
June 11, 2026 · Issue 031
"Influence without authority" is the default advice handed to staff+ ICs and senior TPMs. Thirty-seven years after Cohen and Bradford wrote it, the frame is quietly making us worse at the job.
Walk into any TPM-track promotion conversation and the same phrase shows up: they show influence without authority. It became gospel because the underlying book — Allan Cohen and David Bradford's 1989 Influence Without Authority — was genuinely useful. The currencies-of-exchange model still holds up. The problem isn't the model. The problem is what the slogan has become: a permission structure for living downstream of unclear decisions.
If you optimize for influence, you accept the premise that you don't get to decide and your job is to talk people who do into the right thing. That's a real skill. It's also a tax. Every coalition you build is interest paid on a debt the organization incurred when it failed to specify who decides. In 2026, with agents accelerating both the number of proposals on the table and the rate at which decisions get re-litigated, that tax is becoming unaffordable.
The senior move is upstream: refuse to operate inside fuzzy decision rights. Make naming them the first artifact of any program. The leverage isn't being more charming in the room — it's making sure the room knows whose call it actually is before anyone walks in.
Here is the test that separates senior tech leaders from the very senior ones. Pick any cross-team decision currently in flight on your program. On a sticky note, in under sixty seconds, write four letters: D (who drives), A (who approves), C (who must be consulted), I (who must be informed). Put a name next to each letter — a single name, not a team.
If you can't, you don't have a decision. You have a discussion that will be re-opened every Thursday until somebody quits.
This is the diagnostic. Most program risk that gets logged as "alignment" or "stakeholder management" is, on inspection, undefined decision rights. The director who keeps re-litigating a tech choice isn't being difficult; nobody told them they weren't the A. The staff engineer who feels excluded isn't being precious; they were a D in the architecture and a C in the rollout, and nobody distinguished the two. The VP who "isn't bought in" was never asked, because everyone assumed someone else had.
Why "influence without authority" actively makes this worse. The frame implies authority is fixed and external — given by org charts, withheld from you. So you compensate with relationship currency. Cohen and Bradford's model, read carefully, never said that. They wrote it for people who needed to get a specific decision made by someone who held the right to make it. That's a precision tool. The slogan has become a license to skip the precision step — to organize support for an outcome without first naming whose decision it is. The result, at scale, is what the Aptly Blog studies of high-performing orgs flag bluntly: ambiguous decision authority is one of the strongest single predictors of low engineering velocity.
What the best engineering orgs actually do. Read across Stripe, Netflix, Amazon, and Google and a pattern emerges that has almost nothing to do with influence. Stripe lets the implementing team decide on architecture; senior engineers contribute feedback that does not require incorporation. Netflix runs "Freedom and Responsibility" — engineers decide inside their sphere, context flows via RFC. Amazon pairs explicit single-threaded ownership with Bezos's disagree-and-commit protocol: the decider hears the dissent, names the dissent, then decides — and the dissenters commit publicly. Google uses Technical Lead Networks and written design docs to localize decisions and make their boundaries legible.
None of these are influence systems. They are decision-rights systems with influence as a side effect. The leaders inside them are not less influential; they are influential because the system makes it cheap to know whose call it is, which lets relationship capital go toward the substance instead of the procedure.
What this means for your week. Stop framing your program risks as "need more buy-in from X." That's an influence framing and it leads to coffee chats. Re-frame them as decision-rights gaps: which decision does X own that we haven't surfaced? Which decision are we treating as theirs that's actually ours? Which decision has three people who think they're the A?
The 30-minute discipline: before your next program kickoff, list the top ten decisions that will be made in the first quarter. Next to each, draft the D/A/C/I. Send the draft to the people you named. Watch what happens. About a third will come back contested — that's the influence work you actually had to do, made visible. Another third will be silently corrected — that's the org telling you who the real decider is, for free. The last third will be confirmed — and those are the decisions that won't be re-litigated, because you wrote them down before anyone was incentivized to claim or disclaim them.
The shift, when it lands, is hard to overstate. You stop walking into rooms hoping to be persuasive. You start walking in already knowing whose meeting it is.
Try this week. Pick your most-stuck cross-team decision. Write D/A/C/I on it in under 60 seconds, with names. Email the named A: "I'm operating as if you're the approver on X — confirm or redirect." You will get an answer within a day, and the program will move by Friday.
What they are. DACI (Driver, Approver, Contributors, Informed) was codified by Intuit and popularized through Atlassian's Team Playbook; it formalized a single-approver pattern that had been informal for decades. RAPID (Recommend, Agree, Perform, Input, Decide) was developed by Bain & Company (Rogers and Blenko, Harvard Business Review, 2006) for decisions where multiple parties hold real veto power.
When to use DACI. One person or role has the final say; others contribute. This covers most program decisions: scope cuts, milestone moves, hiring loops, vendor selection within a budget envelope. Four roles are easier to assign and remember than five, and the Driver/Approver split keeps execution and accountability distinct.
When to use RAPID. Multiple functions can hard-block the decision — legal, security, finance, compliance, a partner org. RAPID's Agree role exists precisely to surface veto-holders explicitly. Use it for cross-org migrations, regulated-industry launches, major architecture changes touching shared platforms, and any decision where "we forgot to ask Security" would be a resume-generating event.
How to choose, in five steps:
When NOT to use either. Trivial reversible decisions (just decide and move). True emergencies (use OODA — Boyd, 1976 — and reconstruct the decision-rights story after). Decisions inside a single team's domain where the team's tech lead already owns them — adding a framework creates ceremony where ownership already exists.
One-line example: a platform migration with security, finance, and two partner orgs holding veto is a RAPID. A within-team library swap that the tech lead owns is neither — it's a tech lead's call documented in an RFC.
Token maximizing inside big tech — Gergely Orosz has been mapping how AI-coding metrics are getting gamed at Meta and Microsoft. The leadership takeaway isn't "AI metrics bad" — it's that any metric becomes a decision right by default, and undocumented incentives route around documented ones.
Camille Fournier at LeadDev (Nov 9-10, 2026) — Now managing director at JPMorgan Chase, Fournier is increasingly framing platform engineering as a decision-rights problem in disguise. Worth tracking for senior TPMs sitting between product and platform orgs.
Charity Majors on "managerial gravity" — Honeycomb's CTO keeps flagging how orgs accidentally route ambitious senior ICs into management because the IC track lacks formal decision rights. If you're building a staff+ ladder, this is the failure mode to design against.
"If you have conviction on a particular direction even though there's no consensus, it's helpful to say: 'Look, I know we disagree on this, but will you gamble with me on it? Disagree and commit?'"
— Jeff Bezos, 2017 shareholder letter
Don't miss what's next. Subscribe to Critical Path: