version: "1.0.1" name: tech-radar 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."

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:

Rings express our recommendation:

Quadrant 1: Techniques

Adopt

[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

[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

[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

[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

[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

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

Assess

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

Hold

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

Quadrant 3: Platforms

Adopt

[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

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

Assess

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

Hold

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

Quadrant 4: Languages & Frameworks

Adopt

[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

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

Assess

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

Hold

[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.

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

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

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