Enterprise Technology Radar: Building Your Own
ThoughtWorks’ Technology Radar has become one of the most referenced tools in the CTO’s strategic toolkit. Published twice yearly, it categorises technologies, techniques, platforms, and tools into four rings — Adopt, Trial, Assess, and Hold — providing a curated view of the technology landscape that informs adoption decisions across the industry.
But the industry radar, while valuable for awareness, does not answer the enterprise-specific question: which technologies should our organisation adopt, given our specific context, constraints, and strategic direction? A technology that ThoughtWorks places in “Adopt” may be inappropriate for an organisation without the engineering maturity to use it effectively. A technology in “Assess” may be critical for an organisation with specific domain requirements.
The enterprise technology radar applies the same concept to the organisation’s specific context. It captures the collective wisdom of the engineering organisation about which technologies to embrace, which to experiment with, which to evaluate, and which to avoid. When maintained effectively, the enterprise radar serves as a governance tool, a communication mechanism, and a strategic planning input.
Radar Structure and Categories
The enterprise technology radar uses the same four-ring structure as the ThoughtWorks model, adapted for internal governance purposes.
The Adopt ring contains technologies that the organisation endorses for broad use. These technologies have been proven in production, have sufficient internal expertise, and are supported by the organisation’s platform and tooling. Teams should default to Adopt technologies for new projects. The bar for Adopt is high — the technology must be production-proven within the organisation, not just in the industry.
The Trial ring contains technologies that the organisation is actively experimenting with in controlled settings. These technologies have shown promise and are being evaluated through pilot projects. Teams working on appropriate pilot projects may use Trial technologies with the understanding that the evaluation results will inform whether the technology moves to Adopt or is removed.
The Assess ring contains technologies that the organisation is watching with interest but has not yet committed to evaluating. These are technologies that may be relevant to the organisation’s future needs, and the CTO or architecture team monitors their development. Teams should not use Assess technologies in production but may explore them in personal development or hackathon contexts.
The Hold ring contains technologies that the organisation recommends against for new projects. This includes previously adopted technologies that are being deprecated (where migration to a replacement is planned), technologies that have been evaluated and found unsuitable, and technologies whose risk profile is unacceptable. Existing systems using Hold technologies are not immediately affected, but new projects should not introduce additional dependencies.
The radar should categorise technologies across multiple quadrants: languages and frameworks, platforms and infrastructure, tools and libraries, and techniques and practices. This ensures that the radar covers the full spectrum of technology decisions teams face.
Building the Radar Process
The value of the enterprise radar depends on the process that creates and maintains it. A radar created by a single architect reflects one perspective. A radar created through a structured, inclusive process reflects the organisation’s collective intelligence.
The contribution process should enable any engineer to nominate a technology for placement on the radar. Nominations should include the technology name, the proposed ring placement, and a brief rationale explaining why the technology should be at that position. This open contribution model ensures that the radar captures insights from across the engineering organisation, not just from senior leadership.
The evaluation panel reviews nominations and makes placement decisions. This panel should include senior engineers and architects from diverse parts of the organisation, ensuring that different perspectives and use case requirements are represented. The panel meets quarterly (or semi-annually for larger organisations) to review nominations, discuss placements, and update the radar.
The evaluation criteria for each ring should be explicit. For a technology to move to Adopt, the panel should verify that it has been used successfully in production for a defined period, that the organisation has sufficient internal expertise to support it, that it is compatible with the enterprise architecture and security requirements, and that migration paths exist from current technologies. For Trial, the criteria include a clear hypothesis about the technology’s value, a defined pilot scope, and assigned evaluation ownership.
The publication process makes the radar accessible and understandable. The radar should be published as a visual document (the familiar circular radar format) with accompanying narrative that explains each entry’s placement and the reasoning behind changes from the previous edition. The narrative is as important as the visual — it communicates the strategic thinking behind technology decisions.
Using the Radar for Governance
The radar’s governance value comes from its integration with technology decision-making processes.
New project technology selection should reference the radar. When a team starts a new project, they should select technologies from the Adopt ring unless there is a compelling reason to use a Trial technology (which should be discussed with the architecture team) or a technology not on the radar (which should go through the evaluation process).
Architecture reviews should validate that proposed architectures align with the radar. A proposal that introduces a Hold technology should require explicit justification and a migration plan. A proposal that uses a technology not on the radar should trigger an evaluation.
The radar should inform training and hiring investments. Technologies in the Adopt and Trial rings should be reflected in the training programme and hiring criteria. Technologies moving from Trial to Adopt should trigger investment in broader skill development. Technologies moving to Hold should trigger migration planning and reduced investment in associated skills.
Vendor and tool evaluations should consider radar alignment. A new tool that integrates well with Adopt technologies is more attractive than one that requires technologies in the Hold ring. The radar provides context for vendor discussions about technology direction.
Maintaining Radar Relevance
The radar’s value degrades if it is not maintained. Technology moves fast, and a radar that is updated annually will contain stale entries that undermine credibility. Quarterly updates are ideal, with the flexibility for ad-hoc additions when significant technology developments occur.
Each update should explicitly note what has changed since the previous edition — technologies that have moved between rings, new entries, and removed entries. This changelog helps the organisation track the evolution of its technology strategy over time.
Feedback loops ensure that the radar reflects reality. If teams are consistently choosing technologies outside the Adopt ring, the radar may not be reflecting actual needs, and the evaluation panel should investigate. If Adopt technologies are creating operational challenges, they may need to be reconsidered.
The retirement process removes technologies from the radar when they are no longer relevant — either because they have been superseded or because the organisation has fully migrated away from them. A bloated radar with entries that no one references is less useful than a focused radar that reflects current strategic thinking.
The enterprise technology radar is a lightweight but powerful governance mechanism. It captures organisational knowledge about technology fitness, communicates strategic direction in an accessible format, and provides a framework for consistent technology decision-making across a distributed engineering organisation. For the CTO, it is a tool that scales strategic thinking beyond the decisions they can personally influence, embedding technology strategy into the organisation’s decision-making fabric.