The Technology Radar is a technique originally created by ThoughtWorks for tracking and communicating technology choices across an organization. It provides a structured way to evaluate, categorize, and communicate the adoption status of tools, techniques, platforms, languages, and frameworks.
## Structure
The radar is organized along two dimensions:
### Quadrants (what kind of technology)
- **Techniques**: Methods and approaches (e.g., pair programming, trunk-based development)
- **Tools**: Software tools and utilities (e.g., Docker, Terraform)
- **Platforms**: Infrastructure and platform technologies (e.g., Kubernetes, AWS)
- **Languages & Frameworks**: Programming languages and frameworks (e.g., Rust, React)
### Rings (what to do with it)
- **Adopt**: Proven and recommended for broad use. The organization should be using these.
- **Trial**: Worth pursuing in low-risk projects. Positive experience is growing but more evidence is needed.
- **Assess**: Worth exploring to understand how it might affect your work. Not yet ready for trial.
- **Hold**: Proceed with caution. May be declining, superseded, or problematic. Don't start new work with these.
## Why radars matter
### For organizations
- **Alignment**: Creates shared vocabulary about technology choices across teams
- **Decision support**: Provides guidance without mandating—teams can make informed local decisions
- **Knowledge sharing**: Surfaces technologies that individual teams have evaluated, preventing redundant assessment
- **Risk management**: Makes technology risk visible (concentration on "Hold" technologies signals danger)
- **Strategic direction**: Communicates where the organization is heading technically
### For individuals
- **Learning prioritization**: Focus learning on "Adopt" and "Trial" technologies rather than spreading attention thin
- **Career development**: Understanding industry trends helps with skill investment decisions
- **Decision confidence**: Knowing what others have evaluated reduces uncertainty
## Building your own radar
1. **Gather input**: Collect technology assessments from across teams (what's working, what's not, what's emerging)
2. **Evaluate collectively**: Cross-functional groups discuss and place technologies on the radar
3. **Document rationale**: For each technology, capture *why* it's in its current ring (this complements ADRs)
4. **Publish and communicate**: Share the radar broadly and discuss changes
5. **Update regularly**: Review quarterly or semi-annually. Technologies move between rings as experience grows
## Radar as living document
A technology radar is most valuable when it evolves. Technologies move inward (from Assess to Trial to Adopt) as confidence grows, or outward (to Hold) as better alternatives emerge or problems surface. Each movement should be accompanied by documentation explaining the change—effectively creating a timeline of technology decisions.
## Relationship to ADRs
The technology radar and Architecture Decision Records serve complementary purposes. The radar provides a high-level overview of technology positioning; ADRs capture the detailed reasoning behind specific adoption or rejection decisions. When a technology moves from "Trial" to "Adopt" on the radar, an ADR documents why. When a technology moves to "Hold," an ADR explains what went wrong and what alternatives are recommended.
## Common pitfalls
- **Stale radars**: Publishing once and never updating makes the radar actively harmful
- **Top-down dictation**: Radars work best when informed by practitioners, not imposed by management
- **Too many items**: A radar with hundreds of entries is unusable. Focus on technologies where guidance adds value
- **Ignoring "Hold"**: The most valuable part of the radar is often what *not* to use—don't neglect it
- **No rationale**: A dot on the radar without explanation is just an opinion; documented reasoning is what creates value