Technology Radar Creation
What Is a Technology Radar
ThoughtWorks popularized this concept. A technology radar is a visual tool that captures your organization's collective opinion on which technologies to invest in, experiment with, or step away from. Unlike a standards document that goes stale, the radar gets updated regularly and reflects what engineers are actually experiencing on the ground.
The Four Rings
Adopt means these are battle-tested technologies your teams should reach for by default on new projects. There's solid internal expertise, good tooling, and documented best practices already in place. Think TypeScript for frontend work, PostgreSQL for relational data.
Trial covers technologies that have worked well in limited use and are ready for broader experimentation. Teams can use them in non-critical paths, but there should be a designated champion who shares what they learn with the wider group.
Assess is for interesting technologies worth exploring through spikes, prototypes, or conference talks. Nothing in production yet. The goal is to learn enough to move them into Trial or push them to Hold.
Hold is where you park technologies the org has decided to stop investing in. Existing usage gets maintained, but no new projects should pick them up. This is actually the most valuable ring because it's what prevents fragmentation across teams.
Running the Process
Put together a Technology Advisory Group (TAG) with 6-10 senior engineers and architects from different parts of the org. Meet quarterly for about 2 hours. Before each meeting, collect nominations from the broader engineering team through a simple form: technology name, proposed ring, and a paragraph explaining why.
In the session, talk through each nomination. Consensus is great when you can get it, but the TAG lead makes the call when opinions split. Write down the rationale for every decision. After the session, publish the updated radar with a changelog that highlights what moved and the reasoning behind it.
Governance Without the Red Tape
The radar is guidance, not a hard gate. Teams can go a different direction if they document their reasoning in an Architecture Decision Record (ADR). This creates a healthy feedback loop. If lots of teams are deviating from a recommendation, that's a signal to update the radar, not to crack down harder on compliance. The point is informed decisions, not uniformity for its own sake.
Key Points
- •Use four rings (Adopt, Trial, Assess, Hold) to classify technologies by how ready your org is to use them
- •Run quarterly review sessions with senior engineers to keep the radar current and grounded in real experience
- •Cover more than just languages and frameworks. Include techniques, platforms, and architectural patterns too
- •Publish the radar openly so every team can make consistent technology choices without waiting for approval
- •Track adoption metrics. If something is in 'Adopt' but nobody's using it, you have a communication or tooling problem
Common Mistakes
- ✗Treating the radar as a top-down decree instead of a collaborative effort. Engineers ignore mandates they had no part in creating
- ✗Putting too many items in 'Adopt'. When everything is recommended, nothing is prioritized
- ✗Never moving anything to 'Hold'. Failing to sunset old technologies leads to fragmentation and maintenance headaches
- ✗Skipping the narrative. Each blip needs a short rationale explaining why it landed in that ring for your specific context