Technology Radar
A Technology Radar is a published, quarterly-updated map of the technologies, tools, languages, frameworks, and platforms an engineering org is using โ sorted into four rings: Adopt (default choice), Trial (worth piloting), Assess (interesting, watch), Hold (do not start new use). Originated by ThoughtWorks in 2010 and now adopted by Capital One, Zalando, AOE, Spotify, and hundreds of others. The point is not to predict the future โ the point is to make tech choices visible, opinionated, and debatable across teams that would otherwise re-litigate the same decisions in isolation.
The Trap
The trap is treating the radar as a vendor-approval list or procurement gate. Once it becomes 'you can only use what's on the radar,' engineers either game it (lobby to add their pet tool) or ignore it (use whatever they want and never tell anyone). The radar dies. The other trap: shipping it once and never updating it. A radar from 2022 still showing 'Adopt: Angular.js' is worse than no radar โ it actively misleads. Useful radars publish quarterly with clear movement (item moved from Trial to Adopt, item moved from Adopt to Hold) and the reasoning behind each move.
What to Do
Run the radar as a quarterly opinion-forming exercise: (1) Form a Tech Radar Working Group of 8-15 senior engineers from across teams (not just architects). (2) Each quarter, gather candidate technologies via open submission. (3) Discuss each in a session: real production experience? maturity? alternatives? lock-in? (4) Place each on the four-ring map with a 1-2 sentence rationale. (5) Publish internally with a changelog showing what moved and why. (6) Make it advisory, not mandatory โ but use it as the starting point in every architecture review and tech-selection meeting.
Formula
In Practice
ThoughtWorks publishes its public Technology Radar twice a year since 2010 โ Volume 32 (April 2025) covered 100+ items across Languages & Frameworks, Tools, Platforms, and Techniques. Internal versions exist at Capital One (where they call it the 'Tech Compass'), Zalando (open-sourced their internal radar), and AOE. The Zalando radar tracks 200+ technologies and is updated quarterly, with each item linked to teams currently using it in production.
Pro Tips
- 01
Use four rings, not three: Adopt, Trial, Assess, Hold. The 'Hold' ring is the most valuable โ it tells engineers what NOT to start using, which prevents far more bad decisions than the 'Adopt' ring promotes good ones.
- 02
Movement matters more than position. A tool moving from Trial to Adopt is a stronger signal than a tool that's been in Adopt for 3 years. Publish the movement explicitly with reasoning.
- 03
Open-source your radar (or at least share it with peer companies). Hiring teams use it as a recruiting signal, and the discipline of public commitment forces better reasoning.
Myth vs Reality
Myth
โThe radar is the source of truth for which tools to useโ
Reality
The radar is a strong opinion, not a binding rule. Mandating it kills it โ engineers route around mandatory lists. Used as advisory input, with clear reasoning, it shifts the default choice without preventing teams from making the case for an exception.
Myth
โBigger radar = better radarโ
Reality
A radar with 500 items is unreadable and useless. ThoughtWorks deliberately caps each volume at ~100 items, with strict criteria for inclusion. The discipline of choosing what NOT to put on the radar is what makes it useful.
Try it
Run the numbers.
Pressure-test the concept against your own knowledge โ answer the challenge or try the live scenario.
Knowledge Check
Your company adopts a Technology Radar. After 6 months, an engineering team wants to use Rust for a new service, but Rust is in 'Assess' (not 'Adopt'). What's the right response?
Industry benchmarks
Is your number good?
Calibrate against real-world tiers. Use these ranges as targets โ not absolutes.
Technology Radar Update Cadence
Engineering organizations with 100+ engineersBest Practice
Quarterly
Acceptable
Twice yearly
Drifting
Annually
Stale
Every 18+ months
Dead
Never updated after launch
Source: ThoughtWorks Technology Radar Methodology / Zalando OSS Tech Radar
Real-world cases
Companies that lived this.
Verified narratives with the numbers that prove (or break) the concept.
ThoughtWorks
2010-2025
ThoughtWorks invented the Technology Radar format in 2010 as an internal tool, then began publishing it publicly twice a year. By Volume 32 (April 2025), the radar covered 100+ items across four quadrants: Languages & Frameworks, Tools, Platforms, and Techniques. The radar is built by the Technology Advisory Board โ ~20 senior technologists โ who debate each item over multi-day sessions. Items move based on real client engagement experience. Companies like Zalando, Capital One, AOE, and government agencies have adopted internal versions, and the format is now an industry standard.
Volumes Published
32 (2010-2025)
Items per Volume
~100
Public Adoption
100s of companies
Update Cadence
Twice yearly
A radar's value comes from explicit, opinionated movement โ not the items themselves. Publish what moved and why; that's where engineers learn.
Zalando
2016-Present
Zalando open-sourced its internal Technology Radar in 2016 as a tool for managing 200+ technologies across hundreds of engineering teams. Each item links to actual teams using it in production, with 'Adopt/Trial/Assess/Hold' rings updated quarterly. The radar is governed by a Tech Council of senior engineers and is advisory rather than mandatory โ teams retain authority over their stack but must justify deviations from 'Adopt' or use of 'Hold' items. The open-sourced template is now used by hundreds of other companies as a starting point.
Technologies Tracked
200+
Engineering Teams
300+
Update Cadence
Quarterly
Governance
Tech Council (advisory)
Linking each radar item to teams using it in production keeps the radar honest. If no team uses it, it shouldn't be in Adopt.
Related concepts
Keep connecting.
The concepts that orbit this one โ each one sharpens the others.
Beyond the concept
Turn Technology Radar into a live operating decision.
Use this concept as the framing layer, then move into a diagnostic if it maps directly to a current bottleneck.
Typical response time: 24h ยท No retainer required
Turn Technology Radar into a live operating decision.
Use Technology Radar as the framing layer, then move into diagnostics or advisory if this maps directly to a current business bottleneck.