Technology Standards & Tech Radar

## What the artifact is A technology radar is a lightweight governance artifact — usually a single diagram or table — that an organization uses to communicate, at a glance, how much production trust it currently places in each technology, framework, tool, or technique it uses or is considering. The four rings encode a **maturity gradient**, and moving a technology between rings is meant to be driven by accumulated real-world evidence rather than by opinion or hype. ## The four rings Mechanism, concretely: 1. **Assess** is the outermost, lowest-commitment ring. An item lands here when someone has flagged it as worth investigating — a conference talk, a competitor's engineering blog, a vendor pitch — but nobody in the organization has built anything real with it. The expected activity at this ring is a time-boxed spike or proof-of-concept, explicitly not connected to a customer-facing system. 2. **Trial** is the next ring in: a team commits to using the technology on an actual project, ideally one that's real but has a contained blast radius (an internal tool, a new low-traffic service, a non-critical batch job) rather than the core payment path. The point of Trial is to generate evidence under real operational conditions — deployment friction, debugging experience, performance under real load, how it behaves during an incident. 3. **Adopt** is the innermost, highest-trust ring: enough independent teams have run the technology in production successfully, for long enough, that the organization is comfortable recommending it as the default choice for new work in that category, often backing it with a reference architecture, a golden-path template, and dedicated support or training. 4. **Hold** is not really a maturity level — it is a stop sign. An item enters Hold because trial evidence was negative, because a newer or more strategic alternative has taken its place, because a vendor is discontinuing it, or because it carries a risk (security, licensing, operational) the organization no longer wants to accept for new systems. ## Why the four-ring structure exists The four-ring structure exists because it solves a real coordination problem in organizations with more than a handful of engineering teams. Without a shared radar, technology choice degenerates into either total anarchy or heavy-handed central mandate: - **Total anarchy** — every team picks whatever is fashionable, and the org ends up supporting eleven different message queues. - **Heavy-handed central mandate** — a standards committee dictates a fixed stack, innovation stalls, and teams route around the rule anyway. The radar is a middle path: it lets exploration happen safely at the edges (Assess, Trial) while concentrating operational investment — training, tooling, on-call runbooks, shared libraries — on a manageable Adopt set. Crucially, it makes the evidence bar explicit: nobody can push a technology straight to Adopt on enthusiasm alone; it has to survive at least one real Trial. ## The trade-off The four-ring model trades a small amount of process overhead (someone has to run the review cadence, someone has to write up trial results) for a large amount of reduced coordination cost and reduced blast radius when a bet doesn't pay off, because a failed Trial only ever touched one low-stakes system. The cost on the other side of that trade-off is **latency**: genuinely great technology can sit in Trial for two review cycles simply because nobody happened to run a qualifying project, and teams under delivery pressure will sometimes route around the process entirely ('shadow IT'), which defeats the purpose of having a radar at all. ## Failure modes in production - **The radar becoming a static, unmaintained wiki page** — the most common failure mode. Published once with great fanfare and never revisited, so it silently drifts out of sync with what teams are actually running, and nobody trusts it. - **Rings without criteria** — a second failure. 'Adopt' becomes whatever the loudest architect likes, and 'Hold' becomes a graveyard nobody ever formally reviews for grandfathering or migration, so teams stuck on a Hold-ringed technology have no path forward and no exception process. - **Scope creep** — a third. Every internal library and one-off script ends up on the radar, diluting it until it's too large to be useful as a quick-reference artifact. ## Where the pattern comes from A concrete real-world instance: ThoughtWorks itself publishes a public Technology Radar twice a year, moving items like specific frameworks, testing tools, and techniques (e.g., 'contract testing,' or a particular observability tool) through exactly these four rings based on what their consulting engagements across many client codebases actually observed in practice — which is also the origin of the pattern many enterprises now run internally, usually on a quarterly cadence tied to an architecture guild or Cloud Center of Excellence review.