skip to content

What is a technology radar with Adopt / Trial / Assess / Hold rings, and what does placing an item in each ring commit an organisation to?

level: middleimportance: should knowfreq 48%

answer

  1. Adopt = default & supported
  2. Trial = real project, reversible, scoped
  3. Assess = spike only, no prod traffic
  4. Hold = no new usage, not a purge
  5. dated editions; movement is the signal

basics

~20 s

A technology radar is a periodically published list of tools, techniques, platforms and languages sorted into four rings: Adopt (default choice), Trial (use on a real project with a way to back out), Assess (worth an experiment or spike), and Hold (do not start anything new with it).

solid answer

~50 s

A technology radar records the organisation's current stance on technologies, grouped into quadrants (typically techniques, tools, platforms, languages & frameworks) and four rings of confidence. Adopt means the default, supported choice — you need a reason not to use it. Trial means proven enough to use on a real, non-critical project by a team that can absorb the risk and reverse the decision. Assess means promising but unproven here; invest a spike or prototype, not production traffic. Hold means stop starting new work with it (not necessarily rip it out) — often because of cost, security, hiring, or a better alternative. Value comes from the process, not the picture: a recurring forum where sponsors argue items, evidence is recorded, movement between rings is explained, and the radar is dated and versioned. Coupled to golden paths, Adopt items are the ones actually paved with templates, libraries and support.

go deeper

for a junior

Name the four rings and give the one-line meaning of each, especially that Adopt is the default choice and Assess is experiment-only.

for a middle

Add the quadrants, the cadence and the nuance that Hold means no new usage rather than a ban, and Adopt means default rather than mandatory.

for a senior

Focus on the process: sponsors, evidence, cost and exit cost, movement between rings, connection to golden paths and fitness-function enforcement.

for a principal

Treat it as a governance instrument: who sits on the forum, how exceptions and deprecations are funded, how it feeds and is fed by the north-star, and how you detect when it has become theatre.

### What it is A **technology radar** (popularised by ThoughtWorks and widely cloned internally) is a periodically published, dated snapshot of an organisation's opinion about technologies. Items are placed on a circular diagram with: - **Quadrants** — usually *Techniques* (practices such as trunk-based development or contract testing), *Tools*, *Platforms*, and *Languages & Frameworks*. - **Rings** — concentric confidence bands, from the centre outward: **Adopt**, **Trial**, **Assess**, **Hold**. Distance from the centre encodes confidence, not maturity of the technology in the wider world: it is *our* stance, here, now. ### The rings, precisely | Ring | Meaning | Implied commitment | |---|---|---| | **Adopt** | We are confident this serves us well; it is the default | Supported, documented, templated, ops story exists; deviating needs justification | | **Trial** | Worth pursuing on a real project, by a team able to handle risk | Production use allowed but scoped, with an owner, success criteria and an exit plan | | **Assess** | Promising, worth understanding | Timeboxed spike/prototype only; no production dependency, no user traffic | | **Hold** | Proceed with caution; do not start new work with it | Existing usage may continue; new usage needs an exception; sometimes paired with a migration plan | Critical nuances that interviewers probe: - **Hold ≠ banned or delete-it-now.** It means "stop adding new dependencies on this." Removing existing usage is a separate, funded decision. - **Adopt ≠ mandatory everywhere.** It means default and supported. Presenting the radar as a mandate is the fastest way to make teams route around it. - **Items should be specific.** "Microservices" is too broad to place; "gRPC for internal service-to-service calls" is placeable. - **Rings encode organisational fit**, so an industry-mainstream technology can legitimately sit in Assess or Hold for you (no operational expertise, licensing cost, hiring pool, compliance). ### Why the process matters more than the diagram The radar's real output is a **recurring decision forum**: a group with representation from teams (not just a central architecture board) meets on a cadence — commonly quarterly or twice-yearly — and each item needs a sponsor who presents evidence: what problem it solves, what it replaces, cost, operational burden, security posture, hiring/skills impact, exit cost. Movement between rings is the interesting artifact: an item that goes Assess → Trial → Adopt shows a working pipeline; an item that sits in Assess for three editions is a signal nobody actually cares. Good hygiene: - **Date and version each edition**, and keep the archive so you can see how opinion evolved. - **Write a short rationale per item** — a blip with no reasoning cannot be challenged or revisited. - **Cap the size.** A radar with 200 entries is a catalogue, not a decision aid. - **Include Techniques, not only tools.** Practices often deliver more than products. - **Publish a deprecation/exception path** for Hold items, otherwise Hold generates arguments instead of migrations. ### How it connects to the rest of technical strategy - The **north-star architecture** supplies the criteria the radar judges items against. - **Golden paths / paved roads** are the implementation of the Adopt ring: templates, libraries, pipelines and support that make the default choice the easiest choice. - **Build-vs-buy** decisions feed the Platforms quadrant. - Radar decisions become partly enforceable via **fitness functions** and dependency scanning (for example, failing a build that pulls a Hold library into a new module). ### Failure modes - Compiled by a central team with no team representation → ignored, or complied with theatrically. - Treated as policy with penalties → shadow IT and hidden dependencies. - Never re-published → stale opinions get quoted as current policy. - Popularity contest with no evidence, cost or exit-cost analysis. - Everything lands in Adopt, so the radar says nothing.

  • A widely used framework in your stack is moved to Hold. What happens to the twelve services already using it?
    Nothing automatic. Hold stops new adoption; existing usage continues until a separately funded migration decision is made, with an exception process for teams that must extend Hold usage and a documented deprecation timeline if removal is actually intended.
  • How do you keep a radar from becoming a central mandate that teams route around?
    Staff the forum with engineers from delivery teams, require evidence and a sponsor per item, keep Adopt meaning 'default and supported' rather than 'required', publish a lightweight exception path, and invest in golden paths so the default is genuinely the cheapest route.

It is a restaurant menu with confidence levels: house specials you can order blind (Adopt), dishes the kitchen is confident about but new (Trial), tasting-menu experiments (Assess), and items the kitchen has stopped cooking for new orders while it finishes the ingredients (Hold).

saying these in an interview costs you the question

  • Saying Hold means the technology is banned and must be removed immediately
  • Saying Adopt means every team must migrate to it
  • Placing vague umbrella terms like 'microservices' or 'AI' as radar items
  • Publishing once and never dating, versioning or revisiting it
  • Judging items purely on industry hype instead of organisational fit, cost and exit cost
  • Letting a central architecture board own it with no delivery-team representation

context

resolving links…