Tech Radar
Status: Complete
Category: Management
Default enforcement: Advisory
Author: PushBackLog team
Tags
- Topic: management, engineering-strategy, technology
- Skillset: engineering-management, cto, engineering
- Technology: generic
- Stage: planning
Summary
A Tech Radar is a living document that catalogues the technologies, techniques, platforms, and tools an engineering organisation uses, evaluates, or avoids. Inspired by the Thoughtworks Technology Radar, it organises entries into four rings — Adopt, Trial, Assess, and Hold — and provides engineering teams with clear, opinionated guidance about what to use, what to experiment with, and what to stop using. A well-maintained Tech Radar reduces inconsistency across teams, enables informed technology selection, and externalises the CTO’s technology strategy into a shared reference.
Rationale
Inconsistency is the cost of no shared alignment
Without a shared view of technology choices, teams make independent decisions that diverge over time. Team A chooses Kafka, Team B chooses SQS, Team C chooses RabbitMQ. All are reasonable choices in isolation; collectively, they require three operational expertise areas, three sets of runbooks, and no knowledge transfer between teams. A tech radar creates alignment without mandating uniformity — teams are guided but not blocked.
Technology adoption needs a lifecycle
Technologies have a lifecycle: they are assessed speculatively, trialled on real projects, adopted as standard, and eventually deprecated. Without a mechanism for managing this lifecycle, deprecated technologies persist long after better alternatives exist (because no one officially said to stop using them), and promising new tools never graduate from experimental use (because no one officially endorsed them). The tech radar provides the mechanism.
Guidance
The four rings
| Ring | Meaning | Guidance |
|---|---|---|
| Adopt | We use this; it is our default choice | Use in all new work; no justification needed |
| Trial | We are using this on real projects to evaluate it | Use with intent to assess; document findings |
| Assess | Worth exploring; low-risk, exploratory use only | Spike or prototype only; don’t use in production |
| Hold | We are moving away from this or not recommending it | Do not use for new work; migrate existing usage when viable |
Entries move between rings over time as the team gains experience and as the technology landscape changes.
The four quadrants
The Thoughtworks model uses four quadrants — adapt to fit your context:
| Quadrant | What goes here |
|---|---|
| Techniques | Practices and methodologies (DDD, TDD, trunk-based development) |
| Platforms | Cloud services and infrastructure (AWS, Kubernetes, RDS) |
| Tools | Development and operational tooling (Terraform, DataDog, k6) |
| Languages & Frameworks | Programming languages and frameworks (TypeScript, Fastify, React) |
Radar update process
# Tech Radar Update Process
**Cadence**: Update quarterly (or when a significant technology decision is made)
**Who contributes**: Any engineer can propose an entry
**Who decides**: Tech Radar committee (CTO + senior engineers + tech leads)
**Proposal template**:
---
Entry: [Technology name]
Ring: [Adopt | Trial | Assess | Hold]
Quadrant: [Techniques | Platforms | Tools | Languages & Frameworks]
Summary: [1-2 sentence description]
Rationale: [Why this ring? What is the evidence?]
Links: [Blog posts, internal ADRs, team experience notes]
---Tooling options
| Tool | Approach |
|---|---|
| Thoughtworks Radar Byor | Spreadsheet → HTML radar |
| Zalando Tech Radar | JS-based visual radar from JSON config |
| Confluence/Notion page | Simple table-based version — low overhead |
| Published static site | Most visible and accessible to external candidates |
A simple Notion table is better than a sophisticated HTML radar that nobody updates. Start with whatever format the team will actually maintain.
Example entries
| Entry | Quadrant | Ring | Notes |
|---|---|---|---|
| TypeScript | Languages & Frameworks | Adopt | Default for all new services |
| Bun | Languages & Frameworks | Assess | Evaluate as Node.js alternative |
| Terraform | Tools | Adopt | IaC standard |
| Pulumi | Tools | Trial | Evaluate for next infra project |
| AWS Lambda | Platforms | Adopt | Serverless standard for event-driven workloads |
| AWS Lightsail | Platforms | Hold | Use ECS or Lambda instead |
| Domain-Driven Design | Techniques | Adopt | Standard for complex domain modelling |
| Mob Programming | Techniques | Trial | Evaluating for complex feature work |
Linking to ADRs
Tech Radar entries are complementary to Architecture Decision Records. An ADR captures the reasoning for a specific decision; the Tech Radar reflects the current collective guidance. An ADR to adopt Terraform would result in a “Terraform → Adopt” entry on the radar.
Review checklist
- Tech Radar is published and accessible to all engineers
- Radar is reviewed and updated at least quarterly
- Every entry has a brief rationale explaining the ring placement
- New technology proposals have a defined process (not ad hoc Slack conversations)
- “Hold” entries are accompanied by a migration plan or guidance on what to use instead