ProcessTechnology
How to create a technology radar that steers real adoption decisions
To create a technology radar that people use, treat the picture as the output of a process: anyone can nominate an entry, each ring has an evidence standard, a small forum reviews nominations on a fixed cadence, every ring change is recorded as a decision, and the radar is wired into golden paths, procurement and security review. This page sets out that process for an engineering stack over roughly the next one to two years.
On this page
- One radar cycle, from nomination to retirement
- Scope: what an engineering radar should and should not decide
- Evidence required before an entry moves into each ring
- Setting up and running the radar process
- Fields every radar nomination should carry
- Connecting the radar to golden paths, procurement and security review
- Frontier entries: letting scanning and readiness evidence feed Assess
- Questions and answers
- Sources
One radar cycle, from nomination to retirement
- Nominate
Any engineer proposes a new entry or a ring change using a short template.
- Gather evidence
The sponsor collects pilot results, support and security information for the target ring.
- Forum review
A small cross-team group accepts, defers or rejects the placement on a fixed cadence.
- Record the decision
The outcome and its reasoning are written up as an architecture decision record.
- Publish and wire in
The radar site, change log, templates and procurement lists are updated together.
- Retire or re-assess
Hold entries get migration plans; stale entries return to nomination or leave the radar.
Scope: what an engineering radar should and should not decide
Thoughtworks popularized the format: entries, called blips, sit in four quadrants (techniques, platforms, tools, and languages and frameworks) and in rings that express how strongly each is recommended1. Its published radar now uses Adopt, Trial, Assess and Caution, while its Build Your Own Radar tool still labels the outer ring Hold12. Either naming works; what matters is that each ring has a definition your teams can test a proposal against.
Keep the scope to the engineering stack your teams will choose from over the next year or two: languages, frameworks, data stores, cloud services, delivery tooling and practices. Long-range foresight and maturity rating of frontier technologies are different jobs with different methods. A radar that tries to do all three ends up recommending nothing clearly. ColdAI's technology practice uses a radar in exactly this way, to keep the platforms it operates current5.
Quadrant names can change to fit your organization. A bank might add a quadrant for data and AI services; a manufacturer might separate plant-floor technology from enterprise software. Keep the count small enough that people remember where to look.
Evidence required before an entry moves into each ring
| Ring | Evidence required | Who may use it | Support expectation |
|---|---|---|---|
| Adopt | Production use by more than one team, documented operations, security review passed | Any team by default, ideally via a golden path | Central or platform team supports it |
| Trial | A bounded pilot with written success criteria that it met | Teams that accept extra effort and report back | Pilot team supports it; known gaps listed |
| Assess | A credible problem it could solve and a named person exploring it | Spikes and prototypes only, no production | None beyond the explorer's notes |
| Hold or Caution | Evidence of poor fit, risk, cost or a better alternative | No new use; existing use migrates on a plan | Existing owners until retirement |
The evidence column is the part most radars skip. Without it, rings record popularity rather than readiness.
Setting up and running the radar process
Charter the radar and its forum
Agree scope, quadrants, ring definitions and who sits on the review forum: typically a handful of senior engineers from different teams, a security representative and someone from the platform team. Rotate membership so it does not become a closed club.
Seed the first edition from what is already in use
Inventory the technologies teams run in production today and place them honestly, including the ones you would rather not have. A first radar that lists only new tools tells teams nothing about what to stop using.
Open nominations with a short template
Anyone may propose a new entry or a ring change. The template asks for the problem, the alternatives considered, the target ring and the evidence offered for it. A nomination without a sponsor willing to do the work is parked.
Review on a fixed cadence
Meet monthly or quarterly depending on volume. For each nomination the forum accepts, defers with a stated gap, or rejects with reasons. Thoughtworks publishes its own radar twice a year1; internal radars often need a faster rhythm for individual decisions and a slower one for full editions.
Record each ring change as a decision record
An architecture decision record captures one justified design choice and the reasoning behind it3. Link the record from the radar entry so a reader can see why something sits where it does and what would move it.
Publish, announce and retire
Update the internal radar site and a change log, announce moves in engineering channels, and hold office hours after each edition. Give every Hold entry an owner and a migration target, and revisit entries that have not moved for several cycles.
Fields every radar nomination should carry
Connecting the radar to golden paths, procurement and security review
A radar changes behavior only when it is connected to the places where choices are actually made. Adopt entries should appear in the service templates of your internal developer platform, so the recommended choice is also the easiest one. Procurement should check new purchases against the radar and route anything on Hold back to the forum. Security review can fast-track Adopt entries and apply full scrutiny to everything else.
Each link removes a reason to ignore the radar. Without them, teams treat it as advice, and advice loses to deadlines.
Frontier entries: letting scanning and readiness evidence feed Assess
Quantum computing, distributed ledgers and extended reality tend to arrive on radars through enthusiasm rather than evidence. Keep the bar the same as for any other entry. A horizon scan is the right source for candidates, and a technology readiness rating is the right evidence for whether something belongs in Assess at all.
Most frontier entries should stay in Assess until a pilot against a conventional baseline justifies Trial. Post-quantum cryptography is the common exception: it is a migration obligation rather than an optional technology, so it belongs in your security roadmap and on the quantum computing agenda, not in a debate about adoption.
Questions and answers
What is the difference between a tech radar and a standards catalog?
A standards catalog lists what is approved and usually changes slowly. A radar also shows direction: what is being tried, what is under assessment and what is being phased out, with reasons. Many organizations keep both, with Adopt entries feeding the catalog and the radar explaining how entries get there and leave.
How often should an internal technology radar be refreshed?
Review individual nominations monthly or quarterly so teams are not kept waiting, and publish a full edition once or twice a year with a summary of what moved and why. If editions repeatedly show no movement, the process is probably not receiving nominations or the evidence bar is unclear.
What tools can we use to publish our own radar?
Thoughtworks' Build Your Own Radar generates a radar from a Google Sheet or a CSV or JSON file with name, ring, quadrant, isNew and description columns2. Zalando's open-source tech-radar library, released under the MIT license, renders a radar from your own configuration as a static page4. A plain internal wiki page also works if the decision records are linked.
Who should be allowed to move an entry between rings?
Only the review forum, and only on evidence matched to the ring's standard. Individual teams can experiment with Assess entries freely, but a move to Trial or Adopt changes what other teams are encouraged to use, so it needs a recorded decision. Executives can ask for a review but should not place entries by decree.
Sources
- Technology Radar FAQ — Thoughtworks · checked 10 October 2026
- Build your own radar — Thoughtworks · checked 10 October 2026
- Architectural Decision Records (ADRs) — ADR GitHub organization · checked 10 October 2026
- zalando/tech-radar — Zalando on GitHub · checked 10 October 2026
- Technology capability: Operate & Evolve — ColdAI