Tech Radar

Last updated:

What it is

A Tech Radar is a visual artifact and governance tool that documents an organization's current perspective on the technologies, tools, platforms, and techniques it uses or is evaluating. Popularized by Thoughtworks, who publish their own public edition biannually, the Tech Radar organizes items into two dimensions: quadrants that categorize the nature of the technology, and rings that indicate the organization's recommended stance on it. Together, these dimensions provide a compact, scannable summary of the organization's technology landscape and directional intent.

The four standard quadrants are: Techniques (practices, patterns, and approaches — e.g., trunk-based development, fitness functions, blue-green deployment); Tools (software tooling used in development and operations — e.g., Spectral, Trivy, Backstage); Platforms (managed services, cloud platforms, infrastructure — e.g., Kubernetes, AWS EKS, Confluent Cloud); and Languages & Frameworks (programming languages, runtimes, and application frameworks — e.g., Python, Rust, FastAPI, React). Organizations sometimes customize quadrant names to fit their domain, but the four-category structure is widely understood.

The four standard rings express the organization's recommended action for each item: Adopt — the item is recommended for production use in new projects and is a default choice when the applicable problem arises; Trial — the item is being used in production in specific contexts and teams are encouraged to try it with appropriate oversight; Assess — the item is being evaluated and teams should be aware of it, but widespread production adoption is premature; Hold — the item is not recommended for new projects, either because a superior alternative exists or because it is deprecated or carries risks that outweigh its benefits.

Why it exists

Engineering organizations face a continuous stream of technology choices — new frameworks, new tools, new cloud services, new techniques. Without a shared mechanism for evaluating and communicating the organization's stance on each, three problems emerge. First, different teams make the same evaluation independently, duplicating effort. Second, there is no shared signal for which technologies are safe bets for new projects and which are experimental or deprecated. Third, technology proliferation grows unchecked because there is no friction against adopting new technologies and no mechanism for retirement.

The Tech Radar addresses all three by externalizing the implicit knowledge of the organization's architecture community. When an engineer asks "should I use X for this new project?", the Tech Radar provides an immediate, authoritative answer with the reasoning behind it. This reduces the decision cost for individual teams, reduces the burden on architects and senior engineers who would otherwise answer the same question repeatedly, and creates a shared mental model of the organization's technology direction that all engineers can navigate by.

The radar's ring structure communicates direction as well as current state. An item that has moved from Assess to Trial between radar editions signals increasing organizational confidence. An item that has moved from Adopt to Hold signals a deprecation decision. These movements tell a story of evolving organizational learning — which experiments succeeded, which technologies disappointed, which new options have matured enough to recommend. Over multiple editions, the Tech Radar becomes a historical record of the organization's technology evolution.

When to use

  • Organizations with multiple teams making independent technology choices who need a shared coordination mechanism.
  • Platform engineering or architecture teams who need a publishing mechanism for their technology recommendations that reaches all engineers without requiring synchronous communication.
  • Organizations going through significant technology transitions (cloud migration, microservices adoption, ML capability build-out) where clear directional signals accelerate alignment.
  • Companies that want to create a culture of deliberate technology adoption — treating technology choices as governance decisions rather than individual team preferences.

When NOT to use

  • Small organizations (under ~30 engineers) where the overhead of a formal Tech Radar process outweighs the coordination benefit — informal architecture discussions and a simple approved technology list may suffice.
  • A Tech Radar that is published once and never updated becomes stale quickly and erodes trust. Only publish if the organization commits to a regular review cadence (quarterly or biannually).

Typical architecture


 TECH RADAR STRUCTURE
 ┌────────────────────────────────────────────────────────────────┐
 │                                                                │
 │          TECHNIQUES          │        TOOLS                   │
 │  ADOPT:                      │  ADOPT:                        │
 │    Trunk-based development   │    Spectral API linting        │
 │    Fitness functions         │    OpenTelemetry               │
 │    Architecture Decision     │    Trivy (container scanning)  │
 │    Records (ADR)             │  TRIAL:                        │
 │  TRIAL:                      │    Temporal workflows          │
 │    Team topologies           │    Buf (Protobuf tooling)      │
 │  ASSESS:                     │  ASSESS:                       │
 │    Wardley Mapping           │    Dagger (CI pipelines)       │
 │  HOLD:                       │  HOLD:                         │
 │    Feature branching         │    Jenkins (legacy CI)         │
 │──────────────────────────────┼────────────────────────────────│
 │        PLATFORMS             │   LANGUAGES & FRAMEWORKS       │
 │  ADOPT:                      │  ADOPT:                        │
 │    Kubernetes (EKS)          │    Python 3.11+                │
 │    PostgreSQL                │    TypeScript                  │
 │    Apache Kafka              │    FastAPI                     │
 │  TRIAL:                      │  TRIAL:                        │
 │    Temporal (orchestration)  │    Rust (performance-critical) │
 │    Weaviate (vector search)  │    React Server Components     │
 │  ASSESS:                     │  ASSESS:                       │
 │    WASM edge runtimes        │    Bun runtime                 │
 │  HOLD:                       │  HOLD:                         │
 │    Self-managed Kubernetes   │    Python 2.x                  │
 │    Heroku                    │    AngularJS (legacy)          │
 └────────────────────────────────────────────────────────────────┘

 RADAR PROCESS (quarterly cycle)
 ┌──────────────────────────────────────────────────────────────┐
 │  1. Nominations: any engineer can nominate an item           │
 │  2. Triage: architecture guild scores nominations            │
 │  3. Scoring session: deliberate ring placement per item      │
 │  4. Publication: radar HTML artifact + portal update         │
 │  5. Communication: all-hands presentation + changelog        │
 └──────────────────────────────────────────────────────────────┘

Pros and cons

Pros

  • Provides every engineer with immediate, authoritative answers to "what should I use for X?" — reducing decision costs and the burden on senior architects.
  • Makes technology direction explicit and searchable rather than implicit in the heads of senior engineers who happened to be present in architecture meetings.
  • The ring movement over time communicates organizational learning and direction — teams can anticipate deprecations and plan migrations before they are forced.
  • Reduces technology proliferation by creating friction against adopting items not on the radar and signaling when items should be retired.

Cons

  • A stale radar is worse than no radar — an outdated edition actively misleads engineers. The cadence commitment must be honored for the radar to be trusted.
  • The ring placement process can become political — teams advocate for their preferred technologies to be Adopted and resist moves to Hold, creating governance friction.
  • The radar format does not capture nuance well — an item can be "Adopt for use case A but Hold for use case B," which the simple ring structure cannot express. Entries require enough prose context to disambiguate.
  • Building and maintaining custom radar tooling is non-trivial; use existing open-source tooling (AOE Tech Radar, Thoughtworks build-your-own-radar) rather than building from scratch.

Implementation notes

Use an open nomination process — any engineer can propose that a technology be added, moved, or removed. This distributes radar maintenance beyond the architecture team and surfaces technologies that are in use by teams but not yet on the radar. Provide a simple nomination form (GitHub issue template, Backstage plugin, Google Form) and commit to a response time for each nomination. The architecture guild reviews nominations in a regular triage meeting and decides whether to escalate to the full scoring session or handle quickly as a minor update.

The scoring session is where ring placements are decided. Bring together senior engineers and architects from different domains; present each item with context (what problem it solves, who is using it, what alternatives exist); and use structured discussion to reach consensus on the appropriate ring. Document the rationale for each ring placement in the radar entry — a one-sentence justification like "moved to Hold because vendor announced EOL in Q4 2025; migrate to [alternative] before that date" is far more useful than a bare ring classification. Teams need to understand the reasoning to trust and apply the guidance.

Publish the radar as a searchable HTML artifact hosted in your developer portal. Generate it from a structured data format (YAML or JSON) so that the radar data can be queried programmatically — for example, to build a "what technologies does my service use that are on Hold?" report, or to automatically flag dependency additions that reference Hold-status technologies in CI/CD. Several open-source tools (AOE Tech Radar, the Thoughtworks build-your-own-radar tool) accept simple JSON/CSV inputs and produce the interactive radar visualization without requiring custom frontend development.

Common failure modes

  • Publish once, never update: The most common Tech Radar failure is publication without commitment to the quarterly review cadence. Within 6-12 months, the radar is clearly stale; teams stop trusting it; it becomes an embarrassing artifact rather than a governance tool. Treat the review cadence as a non-negotiable organizational commitment before publishing the first edition.
  • No Hold enforcement: Items on Hold continue to be adopted because there is no mechanism that creates friction — the radar communicates the decision but teams ignore it. Integrate the radar's Hold list into CI/CD dependency gates: pull requests adding Hold-status technologies should trigger a reviewer warning or require explicit exception approval.
  • Entries without context: A Tech Radar whose entries say only "Adopt" or "Hold" without explanatory prose is not useful — engineers cannot distinguish between "Hold because it's deprecated" and "Hold because we're replacing it with something better" from the ring alone. Every entry should include at least 2-3 sentences of context, including the reason for the ring placement and what to use instead for Hold entries.
  • Quadrant creep: Adding extra quadrants or custom rings to better represent the organization's domain can improve specificity but increases complexity and undermines the radar's legibility. Stick to the four standard quadrants and four rings; use entry prose to express nuance that the structure cannot capture.

Decision checklist

  • Is there a committed quarterly or biannual review cadence for the Tech Radar with named owners responsible for running the process?
  • Is there an open nomination process that allows any engineer to propose additions or ring movements?
  • Does each radar entry include the rationale for its ring placement, not just the ring itself?
  • Is the radar published in a searchable, developer portal-integrated format that all engineers can access easily?
  • Is there a mechanism to enforce Hold decisions in CI/CD, not just communicate them?
  • Are Hold entries paired with migration guidance and timelines for teams using the deprecated technology?

Example use cases

  • New service technology decisions: An engineer starting a new microservice consults the Tech Radar before choosing a framework; they find their first preference is in Hold (the organization is phasing it out in favor of FastAPI); they adopt the Adopt-ring alternative without needing to escalate to an architect; a technology decision that would have taken a week of back-and-forth is resolved in minutes.
  • Organizational ORM consolidation: The architecture guild's quarterly review identifies that three different ORM frameworks are in use across the organization; all three are evaluated; SQLAlchemy is moved to Adopt; the other two are moved to Hold with a 12-month migration timeline; teams using the Hold ORMs receive migration guides; the CI/CD dependency gate flags new usage immediately.
  • Thoughtworks-inspired public radar: A consultancy publishes its own public Tech Radar as a talent and marketing asset — demonstrating the organization's engineering culture and attracting engineers who share its technology philosophy; the radar also serves as a lightweight account for client engagements by showing which technologies the organization has production depth in.

Further reading