Leading without authority: the platform tech lead's playbook

You're the tech lead for the internal platform team. You wrote the migration guide, you built the paved road, you know it's the right call. Six months later, half the org is still on the old thing, three teams have quietly forked their own version, and the one team that "adopted" it did the bare minimum and routes around you for everything real. Nothing is broken. Nobody disobeyed an order — because you were never in a position to give one.

That is the defining condition of the role: full responsibility for the outcome, zero formal authority over the people who determine it. A platform team makes it sharper than anywhere else in engineering, because your "reports" are other engineers who are your customers — and customers can't be commanded, only won. This is the playbook for winning them.

Why the title has a hole in it — responsibility without authority

"Tech lead" is not a point on the ladder; it's a set of responsibilities. Fournier's The Manager's Path is blunt about it: you keep writing code, but you also scope the project, plan the work, represent the group upward, and unblock the team — "usually without any management responsibilities and usually without any specific training." Nobody reports to you. You can't hire, fire, promote, or assign. You are accountable for a result you can only influence.

A platform team turns that from awkward to existential. A feature team ships to external users who have to accept what they're given. A platform team ships to internal engineers who have alternatives — they can build their own, keep the old thing, or comply on paper and hack around you. Your users get a vote, and they vote with adoption. You don't have customers because you're generous; you have customers because without them the platform has no reason to exist.

The reframe that makes the rest work: stop treating the missing authority as a handicap to work around, and start treating influence as the actual medium of the job. The plays below aren't consolation prizes for people who couldn't get a manager title — for a platform team they are a better instrument than authority would be, because they force you to build something people genuinely want.

Why "you must migrate" backfires — the mandate trap

The tempting shortcut is to borrow authority you don't have: get a VP to declare the platform mandatory. On paper it solves adoption in one email. In practice it detonates.

Mandated platforms create resentment and circumvention. Across platform-engineering write-ups the pattern repeats: developers stripped of autonomy respond with shadow infrastructure, or malicious compliance — they technically use the platform while hacking around it to do their real work. Worse, the mandate removes your incentive to build something good: once adoption is guaranteed by decree, the feedback loop goes silent. Developers stop complaining and start suffering quietly, and you lose the signal that would have told you what to fix.

One industry survey put rough numbers on it (single-source — treat as directional, not gospel): around a third of platform teams still lean on mandates to drive usage, roughly 40% can't demonstrate measurable developer value within a year of launch, and developer adoption — not technology — is the single most-cited challenge. The technical part is rarely the hard part; the cultural adoption is.

So the real question isn't "how do I make them adopt this?" It's "how do I make this the thing they choose?" That's a product problem and an influence problem — which is exactly what the rest of this is.

The operating model — influence as the medium, product as the mindset

Two ideas do the load-bearing work, and every play in the catalog is an application of one or both. They're the right column of the figure above, named.

Influence runs on reciprocity and currencies, not rank. Cohen & Bradford's Influence Without Authority — the concept this whole role rests on — models influence as exchange: the Law of Reciprocity says people repay what they receive, and you get cooperation by trading currencies the other person values (their word for anything someone values — inspiration, useful work, visibility, relationship, a genuine favour). You don't have positional currency. You have plenty of the other kinds. The job is knowing which currency a given team actually wants and paying in it.

Treat the platform as a product. This is the Team Topologies keystone: a platform team treats other teams as customers and offers capabilities as a service — self-service, well-documented APIs, real support channels. The goal is the Thinnest Viable Platform (TVP): the smallest set of APIs, docs, and tools that measurably accelerates the teams building on it. Not a bloated everything-platform — the minimum that genuinely makes your customers faster. Product thinking is what keeps influence honest, because a product customers freely choose is the strongest evidence your influence is earned, not borrowed.

Credibility is the currency both ideas spend. Fournier: influence trumps formal authority precisely because "trust and credibility matter more than titles" — built on a track record of good calls and on explaining your reasoning so others can follow it. Every play below either builds that account or draws it down. Guard the balance.

The playbook — 11 plays a platform tech lead actually runs

A catalog, not a sequence — read the ones you need. Each play lists what it is, why it works without authority, who advocates it, and whether it rests on research or on named judgement, so you can weigh evidence against opinion.

If you just want the working mental model, plays 1–6 are the core — direction and adoption. Plays 7–11 are the leverage layer: scaling yourself through people. That's the model and the plays; the rest is the cost and the failure modes.

What influence costs — the tradeoffs nobody puts on the slide

Influence is slower than authority. A mandate ships tomorrow; adoption-by-attraction takes quarters. That's a real cost, and sometimes the wrong one — a genuine security or compliance floor may warrant an actual mandate. The judgement is knowing the difference between "this must be enforced" (rare) and "I wish they'd just do it my way" (common). Reserve borrowed authority for the first; it's a currency that devalues every time you spend it.

Credibility is a finite account. Every play draws on it. Lose a few public arguments badly, ship a paved road that wastes people's time, or become the bottleneck, and the balance drops — and unlike authority, you can't top it up by decree. This is why "follow more than you lead" and disagree-and-commit matter: they're deposits.

Product discipline can tip into scope creep. "Treat it as a product" plus eager customers can grow the platform past the Thinnest Viable Platform into the bloated behemoth Team Topologies warns against. More surface is more to maintain and more ways to slow your customers down — the DORA throughput caveat again: high adoption of a bad platform is a real failure mode.

Where platform tech leads go wrong — the anti-patterns

Six ways the role fails, and the play that pulls it back.

What to actually do on Monday

If you take one thing from all of this: stop trying to get authority you were never going to get, and start building the platform people choose. Then pick the two or three plays that fit your current gap. Adoption stalling? Play 4 (product) + Play 5 (paved road) + Play 6 (measure it). Losing arguments and burning goodwill? Play 1 (credibility) + Play 9 (disagree-and-commit). Drowning as the single point of contact? Play 7 (multiplier) + Play 11 (sponsor). The catalog is a toolbox, not a checklist.

And keep the reframe that makes it bearable: for a platform team, leading through influence isn't the consolation prize for not having authority. It's the only path that produces a platform worth adopting — because the discipline of winning customers you cannot command is the same discipline that builds something genuinely good.