Form
Published radar (for example ThoughtWorks format, markdown in repo or dedicated tool) with items per quadrant and ring, rationale per item (2-4 sentences), previous position note (movement), date, approver and date of next edition.
RunsheetDecision Making
Radar
ComplexityMedium
Time1-2 h
Participants2-10
FormatWorkshop + async
MaturityEstablished
01
Preparation
What needs to be ready before start
Materials
Whiteboard, Miro or table with radar template (for example Adopt/Trial/Assess/Hold rings or n-axis spoke diagram); stickies or cards with item names; evaluation rubric; timer; source list per item (use cases, tests, vendor material).
People / roles
One facilitator and one owner per item (pitch and defense); 2-10 evaluators with context knowledge; one scribe for rationales; for tech radar: architecture board or principal engineer as approver.
Pre-read
List of items to evaluate per quadrant (Techniques, Tools, Platforms, Languages & Frameworks for tech radar; adapted for other radars); one-pager per item with context, use case and known risks; previous edition as reference.
Time needed
1-2 h
Setup
Put radar axes or rings on the wall. Make evaluation rubric visible (for example Adopt: recommended in production; Trial: in pilot; Assess: learn; Hold: do not start). One card per item with owner name. Timer for first phase.
02
Core question
The one question this method answers
Which position on the radar most honestly reflects each item's current maturity and organization-wide recommendation?
03
Flow
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Clarify rubric and items | 10 min | Read rubric aloud and check against examples from previous edition. Review item list, add missing items, remove irrelevant ones. | If ring-specific thresholds do not clearly separate (for example Trial vs. Adopt), clarify them here. Otherwise contradictory placements emerge. |
2Phase 2: Item pitches | 20-40 min | Per item, owner gives 2-3 min pitch: use case, observed benefits, risks, proposed ring. Then 1-2 clarification questions. | Pitches are not lectures, not marketing. Owner should position the item critically, not sell it. Name risks explicitly, otherwise discussion turns into hype. |
3Phase 3: Evaluation | 20-40 min | Evaluate each item silently (cards or online tool), then discuss openly on spread. On consensus, place directly. On dissent: document arguments, approver decides. | Avoid pressure for consensus. If 3 voices say Hold and 5 say Adopt, that is a hot spot, not a democracy topic. Approver decides, not majority. |
4Phase 4: Cross-check and consistency | 15-20 min | Look at radar as a whole: do Adopt items fit together? Are there contradictions (for example two competing tools both Adopt)? Correct placements. | Individually correct items can collectively create a contradictory picture. Cross-check is mandatory, not optional. |
5Phase 5: Documentation and publication | 10-15 min | Write short rationale per item (2-4 sentences: why this ring, what would trigger ring change). Set next edition date. Clarify communication responsibility. | Without rationale, the radar will not be understandable in 3 months. Per item at least one sentence: "would become Adopt if X is measurably reached". |
04
Artifact
What comes out at the end
Versioning / ownership
One dedicated entry per edition with date. Keep previous editions, explicitly mark movement per item (Adopt -> Hold, Trial -> Adopt). At least semiannual edition recommended, otherwise Hold items become zombies.
Tool alternatives
- ThoughtWorks Build-Your-Own-Radar (CSV in HTML)
- Notion or Confluence page with tables per quadrant
- Backstage Tech Radar Plugin
- GitHub repo with markdown per item and SVG cleanup
radar-working-template.md
Compact working template for Radar with dimensions, scores, evidence, and action areas.
Radar Working Template
Goal
Compare capabilities, technologies, or topics on radar rings and derive clear action areas.
Context
When and for what do we use this method?
Input
Which data, observations, decisions, or materials are available?
Working area
- Dimensions:
- Scoring scale:
- Items or capabilities:
- Evidence:
- Action areas:
Output artifacts
- Radar map:
- Capability notes:
- Action backlog:
Open questions
- ...
Next step
Owner, date, and success signal.
05
Example output
Concrete filled scenario, fictional example
radar-beispiel.md
Concrete filled scenario, fictional example
Tech Radar - Engineering Org, Edition 2026.2 (cutoff 2026-05-15)
Approver: @marcus (Principal Engineer), 8 evaluators from 5 teams.
Techniques
- Adopt: Trunk-based Development (3rd edition Adopt, all 4 product teams use it). Pair Programming on critical paths (new Adopt, data from 6-week pilot Team Discovery).
- Trial: Continuous Profiling in production (new Trial, pilot Team Search).
- Hold: Branching strategies like Git Flow for internal services (from Trial to Hold, friction observed in 4 teams).
Tools
- Adopt: Postgres 16 with pgvector (from Trial to Adopt, 3 production workloads stable for 12 weeks).
- Trial: Bun for CI tools (not for production servers, explicit Hold path).
- Assess: DuckDB for ad-hoc analytics.
- Hold: Self-hosted ELK (from Adopt to Hold, move to managed stack recommended, migration running).
Rationale Trunk-based Development: 4 teams in production, average lead time reduced from 3.2 days to 0.8 days. Hold would only apply if compliance audit requires branch reviews; currently not the case.
Next edition: 2026-11-15, preparation from 2026-11-01.
06
Pitfalls
Recognize symptoms and steer against them
Trap
Adopt becomes wish list
Symptom
Items land in Adopt because the team finds them exciting, not because they are proven in production.
What to do
Clear threshold: Adopt requires multiple teams in production with data. Without that, item lands in Trial. Approver defends threshold.
Trap
Hold without migration
Symptom
Items land in Hold, but nobody plans migration away; team continues using them without consequence.
What to do
Hold items need migration plan or justified exception. Without plan, Hold is a symbol, not steering.
Trap
Consensus pressure
Symptom
Evaluation distorted by loud voices, quiet concerns overridden.
What to do
Silent evaluation as first round. Make dissent explicit. Approver decides on spread, not majority. Document rationale of both sides.
Trap
No cross-check
Symptom
Individual items fit, but two competing tools are both Adopt, teams use both and produce drift.
What to do
Do not skip Phase 4. Check every Adopt cluster: is it consistent or does it create choice that leads to fragmentation?
Trap
Radar outdated
Symptom
Last edition 18 months ago, Hold items no longer exist, Adopt items are no longer used.
What to do
Plan edition dates firmly (semiannual). If radar is not current, pause rather than show misleadingly. Place publication date prominently.
07
Stop criteria
Done signals checkable in under a minute
No item candidates with use cases available, radar would be theoretical.
No person with mandate as approver, decisions on dissent impossible.
Evaluators do not know items from their own practice, assessments are hearsay.
Organization is too small (1-2 teams), tech choices happen per team anyway; radar creates overhead.
Previous edition was not communicated or ignored; new edition does not solve distribution problem.
Item list mixes incomparable dimensions (tools with processes), quadrant choice becomes impossible.
Finished the runsheet?
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.