How do you write a technical strategy that changes what teams do, and get it adopted without authority?

What a strategy has to contain to be one

A technical strategy is a small number of decisions taken centrally so that dozens of teams do not have to re-litigate them, plus the reasoning that lets someone extend those decisions to a case you did not anticipate. Three parts make it real. A diagnosis that says what is actually wrong, specifically enough to be arguable. A guiding policy — a handful of choices that constrain what happens next. And the coherent actions that follow, with owners and dates.

Most documents that fail this test fail in the same way: they are a picture of a target architecture with a list of technologies, and no statement of the problem that architecture is the answer to. That document cannot be wrong, cannot be argued with, and cannot tell anyone whether their proposal complies, which is why it ends up in a wiki that gets three visits a quarter.

A wiki document	A strategy that bites
"We will adopt event-driven architecture"	"Cross-team changes need three coordinated releases, so services publish domain events and no team may read another team's database"
Lists preferred technologies	Names one default per capability, and the exemption route
Contains no losers	Says which current investments stop, and when
No date, no owner	Each policy has an owner and a review date
Cannot be falsified	States the measures that would show it working or failing

The diagnosis is where the credibility comes from

Spend disproportionate effort here, because a diagnosis people recognise buys you the right to prescribe. It should be built from evidence the organisation cannot dismiss: change lead time by team, the recurring causes in the last twenty incidents, where the cloud bill concentrates, which repositories require cross-team coordination to release, and what new joiners take longest to understand. Two or three sentences of specific diagnosis outperform ten pages of principles.

Write it in the language of consequences rather than of architecture. "Six of our last ten customer-visible incidents originated in shared database schemas changed by a team that did not own the reading service" is a diagnosis. "Our services are too tightly coupled" is a complaint.

Say what you are not doing

A strategy without losers has not made any choices, and every reader can tell. The section that earns the most trust and costs the most political capital is the one naming what stops: the framework you will no longer support, the second messaging system that is being retired, the in-house tool whose author still maintains it, the migration that will not be funded this year.

This section is also what makes the document useful in a budget conversation, which is the only conversation where a strategy has real force. If it cannot be used to decline a proposal, it is not affecting behaviour.

Adoption is a sequence of acts, not a launch

Without formal authority, adoption is earned by making the strategy demonstrably useful before you ask anyone to comply with it. The order matters.

Co-author with the most credible sceptic rather than presenting to them. The engineer who will publicly object is the one whose objections improve the document, and their name on it is worth more than a director's endorsement. Ask them to break it before it is circulated.

Apply it to a live decision within the first fortnight. A strategy that resolves an argument two teams are having this week — cheaply, visibly, in their favour where it can be — is adopted by demonstration. One resolved decision is worth more than any number of presentations.

Attach it to a ritual that already exists. Design review, the ADR template, quarterly planning, the production readiness checklist, the onboarding path. A strategy with no ritual has no enforcement surface and will decay to a document; a strategy that adds a mandatory new forum will be resented and bypassed. Prefer editing an existing gate.

Make the compliant path cheaper than the alternative. This is the single most effective mechanism available to someone without authority. If the default service template, the pipeline, the observability wiring, and the on-call integration all arrive free when you follow the paved road, teams take it for the same reason water runs downhill. Governance by document loses to governance by convenience every time.

Publish an exemption route with a low cost of entry. A team should be able to deviate by writing a short record of the deviation and its reasoning, reviewed rather than approved. Bans get circumvented silently; documented exemptions give you a real map of where the strategy is wrong.

When a team says no

The instinct to escalate is almost always premature, and it converts a technical argument into an authority contest you will win once and pay for repeatedly. Start by assuming the refusal contains information: their constraint may be a deadline you did not know about, a customer commitment, or a genuine case the policy handles badly.

A phrasing that keeps the conversation productive:

"I'm not asking you to change what you've already committed to for this quarter. What I want to understand is whether the policy is wrong for your case, or right but badly timed. If it's wrong, I'd rather fix the policy than have you quietly work around it — you'd be the second team to raise this and that matters. If it's timing, let's write down what you're doing and when you'd converge, and I'll take the exception."

Escalate only when a deviation imposes a cost on other teams and the owning team will not carry that cost — and when you do, escalate the trade-off with both positions represented fairly, not the disobedience.

The failure mode nobody admits to

Strategies rarely fail because they were wrong about technology. They fail because they were written as an act of description rather than an act of decision, so nothing was ever declined on their basis. The tell is easy to check and worth asking about in any interview where a candidate claims to have written one: name a project that changed course, a technology that was retired, or a budget line that moved because of this document. A candidate who has genuinely driven strategy has that answer immediately. A candidate who wrote a document has an adoption plan instead.

The second, subtler failure is a strategy with a horizon so long that no one is accountable within it. Three-year target states are unfalsifiable by design. Give each policy a review date inside a year and treat being proved wrong as the system working, because a strategy that has never been revised is one nobody has tested.