pm-claude-skills/exports/cursor/pm-engineering/tech-radar/tech-radar.mdc

---
description: "Build a technology radar for an engineering team, categorizing technologies into Adopt/Trial/Assess/Hold quadrants following the ThoughtWorks Tech Radar format. Use when asked to create a tech radar, evaluate the team's technology landscape, categorize tools and frameworks, or establish a technology strategy. Produces a full tech radar with quadrant tables, individual blip rationales, a decision trail, and a maintenance process guide."
globs:
alwaysApply: false
---

# Tech Radar

Produce a complete technology radar document for an engineering team. The radar gives the team a shared, explicit position on every significant technology in their stack — what to standardize on, what to experiment with, what to evaluate, and what to actively stop using. Follow the ThoughtWorks Tech Radar format: four quadrants (Techniques, Tools, Platforms, Languages & Frameworks) each with four rings (Adopt, Trial, Assess, Hold). Each technology entry ("blip") gets a ring assignment, a one-paragraph rationale, and a date. Include a decision trail showing what moved and why, and a maintenance process the team can run to keep the radar current.

## Required Inputs

Ask for these if not already provided:
- **Team or company name** — for the document header
- **Current tech stack** — list every significant technology, tool, language, and platform the team currently uses
- **Technologies under active evaluation** — tools or frameworks the team is currently trying or considering
- **Technologies to deprecate or move off** — anything the team wants to stop using or is actively migrating away from
- **Strategic technology bets** — any technologies the company has made a deliberate bet on (e.g., "we're all-in on Kubernetes" or "migrating to event-driven architecture")
- **Team context** — team size, product domain, and any constraints (regulatory, compliance, vendor lock-in concerns)

If a technology is mentioned without a ring placement, use the rationale inputs to determine the appropriate ring. When uncertain between two rings, ask.

## Output Format

---

# Technology Radar: [Team / Company Name]

**Edition:** [Month Year]
**Maintained by:** [Team Name / Architecture Guild / CTO Office]
**Review cadence:** Bi-annual (every 6 months)
**Next review:** [Month Year + 6 months]

---

## How to Read This Radar

This radar reflects [Team / Company Name]'s current thinking on technologies we use, evaluate, and retire. Use it to make consistent technology choices, onboard new engineers, and have structured conversations about the stack.

**Quadrants** categorize the type of technology:

| Quadrant | What belongs here |
|----------|------------------|
| **Techniques** | Methods, patterns, and practices (e.g., trunk-based development, event sourcing) |
| **Tools** | Software tools used in the development and delivery process (e.g., linters, CI systems, observability platforms) |
| **Platforms** | Infrastructure and hosting environments (e.g., AWS, Kubernetes, Snowflake) |
| **Languages & Frameworks** | Programming languages and application frameworks (e.g., Go, React, FastAPI) |

**Rings** express our recommendation:

| Ring | Meaning | What to do |
|------|---------|-----------|
| **Adopt** | Industry-proven, working well for us — our standard choice | Use by default for new work; no special justification needed |
| **Trial** | Worth pursuing — we are experimenting with it in limited production use | Use in a bounded context with architectural oversight; share learnings |
| **Assess** | Worth exploring — we have not used it in production yet | Spike, prototype, or research; do not use in production without a review |
| **Hold** | Do not start new work with this technology | Complete existing commitments; do not expand use; plan migration |

---

## Quadrant 1: Techniques

### Adopt

| Technology | Since | Notes |
|------------|-------|-------|
| [Technique name, e.g., Trunk-based development] | [Month Year] | [One sentence: why we adopted it and what it replaced] |
| [Technique name] | [Month Year] | [One sentence rationale] |
| [Technique name] | [Month Year] | [One sentence rationale] |

**[Technique name] — Adopt**
[One paragraph rationale. Explain what problem this technique solves, why it works well in your context, and what the team should know before applying it. Reference any internal experience — e.g., "We rolled this out across 8 services in 2024 and saw a 40% reduction in merge conflicts."]

[Repeat for each Adopt-ring technique.]

### Trial

| Technology | Since | Notes |
|------------|-------|-------|
| [Technique name] | [Month Year] | [One sentence: what we're testing and where] |

**[Technique name] — Trial**
[One paragraph. What are we trialing? In which teams or services? What hypothesis are we testing? What would cause us to move it to Adopt vs. Hold?]

### Assess

| Technology | Since | Notes |
|------------|-------|-------|
| [Technique name] | [Month Year] | [One sentence: why we're interested] |

**[Technique name] — Assess**
[One paragraph. Why is this interesting to us? What would we need to see to move it to Trial? Who is responsible for the assessment?]

### Hold

| Technology | Since | Notes |
|------------|-------|-------|
| [Technique name] | [Month Year] | [One sentence: why we're stopping and what replaces it] |

**[Technique name] — Hold**
[One paragraph. Why are we putting this on hold? What is the migration path? What is the target end-state for teams still using it?]

---

## Quadrant 2: Tools

### Adopt

| Technology | Since | Notes |
|------------|-------|-------|
| [Tool name, e.g., GitHub Actions] | [Month Year] | [One sentence rationale] |
| [Tool name] | [Month Year] | [One sentence rationale] |

**[Tool name] — Adopt**
[One paragraph rationale. Why is this our standard tool? What does it do well in our context? Any configuration or usage patterns the team should follow?]

[Repeat for each Adopt-ring tool.]

### Trial

| Technology | Since | Notes |
|------------|-------|-------|
| [Tool name] | [Month Year] | [One sentence: what we're testing] |

**[Tool name] — Trial**
[One paragraph rationale and trial scope.]

### Assess

| Technology | Since | Notes |
|------------|-------|-------|
| [Tool name] | [Month Year] | [One sentence: why we're evaluating it] |

**[Tool name] — Assess**
[One paragraph: what sparked interest, who is evaluating, and timeline.]

### Hold

| Technology | Since | Notes |
|------------|-------|-------|
| [Tool name] | [Month Year] | [One sentence: what replaces it] |

**[Tool name] — Hold**
[One paragraph: deprecation rationale and migration path.]

---

## Quadrant 3: Platforms

### Adopt

| Technology | Since | Notes |
|------------|-------|-------|
| [Platform name, e.g., AWS EKS] | [Month Year] | [One sentence rationale] |
| [Platform name] | [Month Year] | [One sentence rationale] |

**[Platform name] — Adopt**
[One paragraph. What does this platform provide? What are the boundaries of its use? Any internal golden-path setup the team should follow?]

[Repeat for each Adopt-ring platform.]

### Trial

| Technology | Since | Notes |
|------------|-------|-------|
| [Platform name] | [Month Year] | [One sentence: scope of trial] |

**[Platform name] — Trial**
[One paragraph rationale and trial boundaries.]

### Assess

| Technology | Since | Notes |
|------------|-------|-------|
| [Platform name] | [Month Year] | [One sentence: why we're exploring it] |

**[Platform name] — Assess**
[One paragraph assessment plan.]

### Hold

| Technology | Since | Notes |
|------------|-------|-------|
| [Platform name] | [Month Year] | [One sentence: migration target and timeline] |

**[Platform name] — Hold**
[One paragraph: what triggered the hold decision, migration target, and timeline.]

---

## Quadrant 4: Languages & Frameworks

### Adopt

| Technology | Since | Notes |
|------------|-------|-------|
| [Language/Framework, e.g., Go] | [Month Year] | [One sentence rationale] |
| [Language/Framework] | [Month Year] | [One sentence rationale] |

**[Language/Framework] — Adopt**
[One paragraph. What is this language or framework used for? What are the team's proficiency expectations? Any frameworks or libraries that go alongside it as part of the standard choice?]

[Repeat for each Adopt-ring language or framework.]

### Trial

| Technology | Since | Notes |
|------------|-------|-------|
| [Language/Framework] | [Month Year] | [One sentence: bounded use case] |

**[Language/Framework] — Trial**
[One paragraph rationale.]

### Assess

| Technology | Since | Notes |
|------------|-------|-------|
| [Language/Framework] | [Month Year] | [One sentence: interest driver] |

**[Language/Framework] — Assess**
[One paragraph assessment plan.]

### Hold

| Technology | Since | Notes |
|------------|-------|-------|
| [Language/Framework] | [Month Year] | [One sentence: reason and migration path] |

**[Language/Framework] — Hold**
[One paragraph: deprecation rationale, existing system obligations, and timeline to retire.]

---

## Decision Trail

This log records every ring movement since the radar's first edition. Use it to understand the evolution of our technology choices.

| Technology | Quadrant | Previous Ring | New Ring | Edition | Reason |
|------------|----------|--------------|----------|---------|--------|
| [Name] | [Quadrant] | — | Adopt | [Month Year] | First placement — [one sentence why] |
| [Name] | [Quadrant] | Assess | Trial | [Month Year] | [What prompted the move — evidence, team feedback, production trial results] |
| [Name] | [Quadrant] | Trial | Adopt | [Month Year] | [Adoption rationale — usage results, team satisfaction, scale proven] |
| [Name] | [Quadrant] | Adopt | Hold | [Month Year] | [Why moved to Hold — better alternative, security concern, cost, vendor issue] |
| [Name] | [Quadrant] | — | Hold | [Month Year] | First placement — added directly to Hold because [reason] |

---

## Radar Maintenance Process

### Who Contributes

- **Architecture review group / CTO office** — final ring placement decisions
- **All engineers** — submit blip nominations via [channel or form]
- **Tech leads** — triage nominations and prepare proposals for review sessions

### Update Cadence

| Activity | Frequency | Owner |
|----------|-----------|-------|
| New blip nominations accepted | Ongoing — any engineer via [channel] | Anyone |
| Nomination triage | Monthly | Tech leads |
| Full radar review session | Every 6 months | Architecture group |
| Published radar update | Every 6 months | [Owner name or role] |

### How to Nominate a Blip

1. Submit to [Slack channel / form URL] with: technology name, quadrant, proposed ring, and one-paragraph rationale.
2. A tech lead reviews within 2 weeks and either schedules it for the next review session or requests more information.
3. At the review session, the architecture group discusses and votes. Simple majority wins; ties go to Hold pending further evidence.
4. Approved blips are added to the radar doc and the decision trail within 1 week of the session.

### Ring Change Criteria

| To move TO Adopt | To move TO Trial | To move TO Assess | To move TO Hold |
|-----------------|-----------------|-------------------|-----------------|
| Proven in multiple production systems; team broadly trained; clear operational runbook exists | At least one production use case running; architectural oversight in place; learnings documented | Concrete use case identified; spike completed or in progress; interest from at least 2 engineers | Better alternative exists; known security/compliance risk; strategic direction change; unacceptable maintenance burden |

---

*Questions about this radar: [Slack channel] | Submit a nomination: [URL or channel]*

---

## Quality Checks

- [ ] Every blip has a written rationale paragraph — not just a table row entry
- [ ] The decision trail is populated with at least the initial placement date for every blip
- [ ] Hold-ring entries include a concrete migration path or target technology, not just "stop using it"
- [ ] Ring definitions are present and include both what each ring means AND what engineers should do in response
- [ ] Maintenance process includes: nomination channel, review cadence, who decides, and ring-change criteria
- [ ] Technologies identified as "strategic bets" in the inputs are placed in Adopt (if proven) or Trial (if being rolled out)
- [ ] Technologies identified for deprecation are in Hold with a rationale that references the replacement

## Anti-Patterns

- [ ] Do not place a technology in Adopt without evidence it is proven at the team's scale — aspirational placements mislead engineers
- [ ] Do not add a blip without a written rationale paragraph — table rows without context are unusable
- [ ] Do not create a Hold entry without specifying a concrete migration path or target technology
- [ ] Do not skip the maintenance process — a radar with no process for updates becomes stale within two quarters
- [ ] Do not omit ring definitions — engineers need to know what they should do in response to each ring, not just what the ring means