Stackbook Logo
decision-makingestablished · low operational burden

Technology Radar

Also known as: tech-radar, adopt-trial-assess-hold

Intent

Publish a living, opinionated map of technologies the organization adopts, trials, assesses, or holds.

Problem

Teams choose languages, databases, and frameworks independently, leading to sprawl and unsupported stacks. Leadership lacks a shared view of where the organization is heading. Knowledge of experiments stays inside single teams.

Forces

  • •Autonomy encourages experimentation across teams
  • •Every new technology adds support and hiring cost
  • •Evidence from experiments is rarely shared
  • •Technology choices age and need explicit retirement

Solution

Overview

A technology radar is a structured, public record of what an engineering organization thinks about its tools and techniques. It was popularized by Thoughtworks and works best as an internal artifact reflecting your own production experience.

The radar works because it is small and opinionated. A hundred entries with no movement is an inventory, not a radar. Aim for a few dozen items, each with an owner who can answer questions about it.

How it works

Entries are stored as data and rendered into a radar. Movement requires evidence.

- name: Kafka
  quadrant: platforms
  ring: adopt
  since: 2024-Q2
  evidence: adr-0042, 3 teams in prod
- name: GraphQL federation
  ring: trial
  owner: team-api
- name: Self-managed Redis
  ring: hold
  replacement: managed-cache

Ring definitions should be written down. For example, Adopt means at least two teams run it in production with on-call support from the platform group. Trial means one team uses it with a sponsor. Assess means a spike is allowed. Hold means no new usage and a migration guide exists.

Pitfalls

  • No named owner, so the radar is updated once and forgotten
  • Using Hold without a migration path, which creates resentment
  • Adding entries based on conference hype rather than a spike
  • Hiding the discussion; publish rationale, not only rings

Key takeaways

  • Rings should mean support level and require evidence
  • Review on a fixed cadence with a small cross-team group
  • Pair Hold with a recommended replacement
  • Keep the radar in version control next to ADRs

✓ When to Use

  • •Many teams make independent technology choices
  • •You need to steer toward a smaller supported stack
  • •Onboarding engineers who ask which tools are approved

✗ When Not to Use

  • •A single small team shares one stack
  • •The radar would be a mandate with no feedback loop
  • •No one will own the quarterly review

Pros

  • +Gives shared vocabulary for technology direction
  • +Captures experiment results across teams
  • +Makes deprecation visible and intentional

Cons

  • −Becomes stale without an owner and cadence
  • −Can be perceived as a veto on experimentation
  • −Rings without criteria become opinion contests

Cost Profile

Infrastructure

None - a document or small site

Operational

Low - quarterly review

Cognitive

Low

Failure Modes

  • Radar goes stale and is ignored

  • Hold ring used as a ban without migration support

  • Adopt ring contains tools no team actually runs in production

Real-World Examples

Alternatives

    Related Patterns

    • architecture-decision-records
    • platform-engineering

    Competency Domains

    economics evolutionrequirements constraints