This blog post has been adapted from this Tech Talk by Richard Brown, Technical Director at Audacia.
Technology leaders regularly make decisions that shape the technical direction of organisations. Each choice regarding frameworks, languages or tools influences how systems are built, maintained and evolve. The challenge is keeping those decisions aligned across teams, projects and time.
One of the most effective ways to achieve that alignment is by using a Tech Radar.
What is a Tech Radar?
At its simplest, a Tech Radar is a visual representation of technology choices within your organisation. It shows where each tool, framework or platform sits in terms of maturity and adoption.
A Tech Radar makes it easy to answer key questions: what should we be adopting? What's being trialled? What’s emerging? What’s being phased out?
The concept originated at Thoughtworks, but every organisation can adapt it to fit their own priorities.
Why Tech Radars are Important
Without an explicit method for tracking technology choices, teams can drift, and tools can be selected based on convenience or habit rather than strategy. Over time, this results in inconsistency, unnecessary effort and risk.
A Tech Radar forces deliberate conversations about technology. It provides a shared view of what’s recommended, what’s under evaluation, and what’s no longer safe to use.
For technology leaders, the benefits are clear:
- Knowledge sharing
In large organisations or consultancies, there is a danger that teams can become siloed. A radar combats this by makes choices visible. It becomes a central reference point for engineers starting new projects or exploring unfamiliar tools. - Risk management
Technologies age, licensing models change, maintainers move on. When a framework is deprecated or a tool becomes risky, the radar is the single source of truth that makes this clear. - Future direction
By looking at what’s being trialled or assessed, you can see where the organisation is heading. It informs hiring, training, and investment decisions.
Anatomy of a Tech Radar
A radar has two main elements:
- Segments (or quadrants): Categories of technology. These can be as traditional as ‘Languages & Frameworks’ or as precise as ‘Customer Experience Platforms’.
- Rings: Levels of maturity. Thoughtworks use:
- Hold: Do not use (either immature or on the way out).
- Assess: Watch closely.
- Trial: Test in a controlled way.
- Adopt: Recommended for general use.
At Audacia, we adapted this structure to reflect the way our projects are structured and the services we deliver.
For example, our Cloud & DevOps quadrant spans everything from CI/CD pipelines to infrastructure-as-code tools. Data & AI merges data engineering with machine learning, because these disciplines are often inseparable in practice. Additionally, we renamed ‘Hold’ to ‘Avoid’. If a tool has been deprecated or poses security risks, its position in the ‘Avoid’ ring makes this explicit. New teams no longer waste time rediscovering the same issues.
This tailoring is important. Choose quadrants and rings that reflect how you work, rather than adopting someone else’s model. For some organisations, that might mean categories around business domains rather than tools. Copying another company’s structure rarely gives good results.
How To Manage a Tech Radar
A Tech Radar is not a one-off exercise. It must be living and breathing.
At Audacia, we’ve built a lightweight internal web application to host our Tech Radar. It’s updated continuously, with a clear owner for each quadrant. Every blip includes context: where it’s used, why it’s recommended or avoided and who to talk to. Because the radar is visible, it keeps everyone informed and turns technical direction from implicit knowledge into a documented, shared resource.
We also make it easy for engineers to suggest updates through a feedback mechanism. This lowers the barrier to contribution, ensuring the radar reflects the collective expertise of the organisation. People on the ground often see trends earlier than leadership.
Ensure that your Tech Radar is reviewed regularly – a stale radar is worse than no radar. Additionally, make changes visible to everyone. When a significant shift occurs, such as a major library deprecation, communicate it internally beyond the radar itself.
Common Questions
How long should you keep a deprecated technology on the radar?
It depends on how widely it was used. If it was central to past projects, leave it visible in the ‘Avoid’ ring for longer so that future teams know to avoid it.
Should cost factor into a decision?
A Tech Radar provides visibility on what is and is not recommended, which could be for several reasons: technical, cost, licensing or others. Therefore, if licensing costs make a tool unviable, that should be reflected in its position.
How can we build one?
You can start with a simple shared document. Over time, invest in a web-based version that supports filtering, links and feedback. Several open-source templates exist, but building your own allows the flexibility to match your structure.
A Tech Radar is a conversation starter, a knowledge-sharing tool and a governance mechanism. The radar is also a way of making risk visible, such as licensing changes, security vulnerabilities or shifts in community support. It keeps technology choices deliberate and visible, ensuring that decisions made today continue to serve the organisation.
For technology leaders, it is one of the simplest, most effective ways to set direction, manage risk and explain choices.
If you don’t already have one, now is the time to start.
