A tech radar is a visual tool that helps engineering organisations track, evaluate, and govern the technologies they use. Originally popularised by ThoughtWorks, the tech radar categorises technologies into rings - such as Adopt, Trial, Assess, and Hold - providing clear guidance on which technologies to embrace and which to phase out. This guide shows engineering managers how to implement a tech radar that drives informed technology decisions.
What Is a Tech Radar and Why You Need One
A tech radar is a structured framework for tracking the technology landscape within your organisation. It visualises technologies - languages, frameworks, tools, platforms, and techniques - on a radar diagram divided into quadrants (typically Tools, Techniques, Platforms, and Languages/Frameworks) and rings (Adopt, Trial, Assess, and Hold). Each technology is placed on the radar based on the organisation's collective assessment of its maturity and suitability.
Without a tech radar, technology decisions happen in silos. One team adopts GraphQL whilst another builds REST APIs. A third team experiments with a new database without understanding that another team already evaluated and rejected it. This fragmentation increases operational complexity, makes hiring harder, and creates knowledge silos that impede collaboration and mobility across teams.
The tech radar solves this by creating a shared, transparent view of your technology portfolio. It does not dictate every technical decision - engineers still exercise judgement - but it provides guardrails that prevent unchecked technology sprawl. When a team wants to introduce a new technology, the radar process ensures that the decision is informed, deliberate, and aligned with organisational strategy.
- Adopt - technologies that teams should use by default for new projects
- Trial - technologies that have been tested in limited contexts and show promise for broader adoption
- Assess - technologies that are worth exploring but have not yet been evaluated in your context
- Hold - technologies that should not be used for new projects, though existing usage may continue
- Update the radar quarterly or biannually to reflect evolving experience and market changes
Building Your Tech Radar
Start by assembling a technology advisory group - a cross-functional team of senior engineers, architects, and tech leads who represent the breadth of your engineering organisation. This group is responsible for evaluating technologies, facilitating discussions, and producing the radar. Aim for five to ten members who collectively cover your major technology domains.
Conduct a technology audit to understand what your organisation currently uses. Survey teams, review codebases, and catalogue every language, framework, tool, and platform in active use. This audit often reveals surprising findings - technologies you thought were retired may still be running in production, and technologies you assumed were standard may be used by only one team.
For each technology on your audit list, the advisory group should discuss and assign a ring placement. Use a structured evaluation that considers factors like team experience, community support, operational maturity, hiring implications, and alignment with your architectural direction. Document the rationale for each placement - the reasoning is as valuable as the placement itself.
Governing Technology Adoption
The tech radar works best when integrated into your engineering governance processes. When a team proposes adopting a new technology, require them to submit a lightweight RFC (Request for Comments) that references the radar. If the technology is in Adopt, the RFC can be brief. If it is in Assess or not yet on the radar, the RFC should include a more thorough evaluation covering the technology's fit for the use case, operational implications, team readiness, and a comparison with alternatives already on the radar.
Be careful not to make the governance process so heavy that it stifles innovation. The goal is informed decision-making, not bureaucratic gatekeeping. Engineers should feel empowered to explore new technologies - the Assess ring exists precisely for this purpose. What you want to prevent is production dependencies on technologies that nobody has evaluated or that the organisation has explicitly decided to move away from.
Track technology adoption metrics over time. Monitor how many technologies are in each ring, how quickly technologies move between rings, and whether teams are actually following the radar's guidance. If you find that the radar says 'Hold' on a technology but three teams adopted it last quarter, that signals either a governance gap or a need to revisit the assessment.
Common Mistakes and How to Avoid Them
The most common mistake is treating the tech radar as a top-down mandate from architecture or leadership. If engineers perceive the radar as dictatorial rather than collaborative, they will ignore it or find ways around it. The advisory group should include practising engineers, and the process should welcome input from anyone in the organisation. The radar should reflect collective wisdom, not a single person's preferences.
Another frequent error is creating the radar once and never updating it. Technologies evolve rapidly - a framework that was experimental six months ago may now be production-ready, and a tool that was standard may have been superseded. Schedule regular radar reviews and treat stale entries as a credibility risk. An outdated radar is worse than no radar because it creates false confidence in its guidance.
Avoid being too conservative with the Adopt ring. If your radar has dozens of technologies in Assess and Trial but only a handful in Adopt, engineers will struggle to make decisions. The radar should provide clear, opinionated guidance on default technology choices for common use cases. It is better to have strong defaults that can be overridden with justification than to have a radar that hedges on everything.
Practical Implementation Examples
ThoughtWorks publishes their tech radar publicly and it serves as an excellent template. However, your internal radar should be tailored to your organisation's specific context. A startup building a single product has very different technology needs than a large enterprise managing dozens of services. Your radar should reflect your reality, not the industry at large.
Consider using tools like Zalando's open-source tech radar visualisation, Backstage's tech radar plugin, or a simple spreadsheet if you are just starting out. The visualisation format matters less than the process behind it. A well-maintained spreadsheet with clear rationale is more valuable than a beautiful radar diagram that nobody updates.
Communicate radar changes broadly. When the radar is updated, send a summary to all engineers explaining what changed and why. Highlight technologies that moved rings and provide context for the decisions. This communication reinforces the radar's relevance and helps engineers stay informed about the organisation's technology direction without needing to attend every advisory group meeting.
Key Takeaways
- A tech radar prevents technology sprawl by providing clear, shared guidance on adoption decisions
- Build the radar collaboratively with input from engineers across the organisation
- Integrate the radar into your RFC and governance processes without creating bureaucratic overhead
- Update the radar regularly - quarterly or biannually - and communicate changes broadly
- Provide opinionated defaults in the Adopt ring to simplify decision-making for teams
Frequently Asked Questions
- How do you handle disagreements about where a technology should be placed on the radar?
- Disagreements are healthy and expected. Use a structured discussion format where each side presents evidence - production experience, community adoption data, operational costs, and team feedback. If consensus cannot be reached, the technology advisory group makes the final call, but the dissenting view should be documented alongside the decision rationale. Revisit contested placements at the next radar review cycle.
- Should the tech radar cover techniques and processes, or only tools and technologies?
- Include techniques and processes. Practices like trunk-based development, event-driven architecture, or infrastructure as code are technology decisions that benefit from the same structured evaluation as tools and frameworks. The ThoughtWorks model uses four quadrants - Tools, Techniques, Platforms, and Languages/Frameworks - which provides good coverage without being overly broad.
- How do you enforce the tech radar without being authoritarian?
- The radar should be advisory by default and mandatory only for the Hold ring. Technologies in Hold should genuinely require an exception process for new adoption. For other rings, use the radar as a conversation starter rather than a hard rule. If a team wants to use a technology in Assess for a critical production system, have a discussion about the risks rather than simply blocking it. Trust and transparency are more effective than enforcement.
Discover Engineering Manager Tools
Explore our collection of tools for technology governance, including tech radar templates, RFC frameworks, and architecture decision record generators.
Learn More