Tech Strategy | The Garnet Wiki

A technology strategy is a small set of decisions about where an organisation will and will not spend its engineering capacity, written down clearly enough that someone else can use it to say no. That last property is the test. If a document cannot be used to reject a plausible, well-argued proposal, it is not a strategy — it is a wish list, a roadmap, or a statement of values.

What a Technology Strategy Is

Strategy is choice under constraint. An organisation has finite engineering capacity, finite attention from its senior people, and a finite tolerance for concurrent disruption. The purpose of a strategy is to concentrate those limited resources on the few problems where winning matters, and to deliberately under-serve everything else.

The deliberate under-serving is the part that gets omitted. A document listing eight priorities has no priorities, because it provides no basis for resolving the conflicts that will inevitably arise between them. The uncomfortable sentences — the ones naming what will be tolerated as mediocre, deferred indefinitely, or actively retired — are what makes the rest actionable.

Strategy Is Not a Roadmap

A roadmap is a sequence of planned deliverables with approximate dates. A strategy is the reasoning that determines what belongs on the roadmap at all. The roadmap answers what and when; the strategy answers why this and not the other thing. A roadmap without a strategy behind it is a list of everything everyone asked for, ordered by who asked most persistently.

Several other artefacts are also commonly mislabelled as strategy. A vision statement describes a desired end state without explaining how constraints will be overcome. A technology inventory — a decision to adopt a particular platform or language — is an action; it becomes strategic only when attached to a diagnosis explaining why it addresses a real obstacle. A goal expressed as a number is a target, not a plan for hitting it. A budget allocates money without explaining the logic of the allocation.

Diagnosis, Guiding Policy, Coherent Action

The most useful structure available is the one Richard Rumelt sets out in Good Strategy Bad Strategy, which decomposes a strategy into three parts that must all be present.

Diagnosis. A clear statement of what the actual obstacle is, simplifying a messy situation down to its critical few facts. "Our release process requires three weeks of manual cross-team coordination, so we cannot act on customer feedback within a quarter" is a diagnosis: it names a mechanism and implies where to intervene. "We need to be more innovative" is not a diagnosis; it is a complaint.
Guiding policy. The overall approach chosen to deal with the obstacle. A guiding policy rules things out. "We will standardise on a single deployment path and retire the others, accepting that two teams will lose tooling they prefer" is a policy, because it tells you what to do when someone proposes a ninth deployment path.
Coherent action. A set of coordinated moves that implement the policy and reinforce one another, with owners and sequencing. Actions that each make sense individually but pull in different directions are the signature of a strategy that was negotiated among stakeholders rather than decided.

Most weak technology strategies fail at the first step. They skip diagnosis and open with a list of initiatives, which means nobody can subsequently tell whether an initiative is working, because no one wrote down what it was supposed to fix.

The Recurring Decisions

Build, Buy, or Adopt

The reasonable default is to buy or adopt anything that is not a source of durable advantage, and to build only what is. The trap is that the two costs are visible in different ways: build costs appear as headcount you already have, while purchase costs appear as a line item someone must approve. This asymmetry systematically biases organisations toward building things that are not differentiating.

Compare against lifetime cost rather than initial cost. For building, include operation, on-call burden, security patching, documentation, the eventual migration off it, and the opportunity cost of the team not doing something else — the total is dominated by the years after the first release, not by the first release. For buying, include integration, data migration, the renewal negotiation, and the exit. Those are treated in detail under Vendor Management.

Consolidation Versus Optionality

Every standardisation decision trades local fit for global leverage. Standardising on one database engine, one language, or one deployment path means some workloads fit badly, and it means every team shares one operational skill set, one set of tooling investments and one upgrade path. Allowing divergence means better local fit and a larger surface that somebody must operate, secure and staff.

Neither is correct in the abstract. The useful question is where you are currently bleeding. If incidents are caused by systems nobody on call understands, and hiring is hard because every team's stack is different, consolidate. If teams are routinely blocked waiting on a central platform that does not meet their needs, the standard is too tight and loosening it will buy more than it costs.

Platform Bets

An internal platform is a bet that shared leverage beats team autonomy for a particular capability. It pays off when many teams genuinely need the same thing, the thing is hard to do well, and doing it centrally removes real work rather than relocating it.

Platform bets fail in recognisable ways: the platform is built speculatively for customers who were never consulted; adoption is mandated before the platform is good, which converts every defect into resentment; or the platform is funded as a project with an end date rather than as a product with ongoing ownership, so it decays the moment the launch team disperses. The most reliable discipline is to treat internal platforms as products with voluntary adoption for as long as possible, because voluntary adoption is the only honest measure of whether the platform is actually better than the alternative.

Writing It Down

A strategy that exists only in a leader's head is not a strategy, because nobody else can use it to make a decision — which was the entire point. Write it short. Name the diagnosis, the guiding policy, the things you are explicitly not doing, and the few actions with named owners. Length is not a virtue here; a document long enough to need a summary will be read only as its summary.

Record the individual decisions that follow as architecture decision records: the context, the decision, the alternatives considered, and the consequences accepted. The context section carries most of the long-term value, because it captures what was known and constrained at the time. Without it, engineers arriving later see only a decision that looks inexplicable, and either cargo-cult it or reverse it without understanding what it was protecting against.

Revisit on both a cadence and a trigger. Triggers include a vendor deprecating something you depend on, an acquisition, a significant change in scale, or the loss of an assumption the diagnosis rested on. A strategy nobody revisits stops being a decision and becomes an alibi for decisions made years earlier under conditions that no longer hold.

Common Failure Modes

Failure mode	What it looks like in practice	What to do instead
Strategy without diagnosis	A list of initiatives with no stated obstacle, so success is undefinable	Write the obstacle first; if you cannot state it, you are not ready to choose actions
Everything is a priority	Eight top priorities and no rule for resolving conflicts between them	Rank them, and write down what is being deliberately under-served
Roadmap wearing a strategy label	Dates and deliverables, no reasoning about why these and not others	Separate the two documents and make the roadmap derive from the strategy
Technology-first thinking	A platform chosen before the problem it solves was described	State the problem, then evaluate options against it, including doing nothing
Build bias from invisible cost	Bespoke internal tooling in a non-differentiating area, maintained forever	Compare lifetime cost including operation and exit, not initial effort
Mandated platform adoption	Teams route around the platform or comply resentfully and slowly	Earn adoption first; mandate only once the platform is demonstrably better
Never revisited	Decisions defended on grounds that stopped being true some time ago	Set a review cadence and name the triggers that force an early review

When You Do Not Need One

Producing a strategy document has a real cost in senior attention, and there are situations where it is not worth paying.

A small organisation with one product and one team. The strategy is legible to everyone without being written, and formalising it is ceremony that consumes the time it was meant to protect.
No genuine choice exists. Where a regulatory requirement, a contractual obligation or a hard technical constraint leaves one feasible option, document the constraint and move on. Constructing a strategy around a forced move is theatre.
The real problem is execution. If everyone already agrees on what should be done and it is not getting done, the gap is in delivery, ownership or capacity. Another strategy document will not close it, and writing one is a comfortable way to avoid the harder conversation.

Key Takeaways

The test of a strategy is whether it can be used to reject a reasonable proposal. If not, it is a wish list.
Diagnosis comes first. Initiatives without a stated obstacle cannot be evaluated.
Write down what you are deliberately not doing; that is where the constraint actually lives.
Build only what differentiates, and compare lifetime cost rather than initial effort.
Standardisation trades local fit for global leverage — choose based on where you are currently hurting.
Treat internal platforms as products with voluntary adoption for as long as you can afford to.
Record decisions with their context, and revisit on a cadence and on named triggers.