You are asked to produce a technology radar for a 200-engineer organisation with no current standards. How do you build the first one?

Start from what is actually in use, not from what should be

Inventory the estate: languages, frameworks, datastores, queues, CI tooling, observability. Sources are the service catalogue if one exists, dependency manifests across repositories, and the cloud bill — which is unusually honest about what is running.

Expect the count to be higher than anyone believes. Discovering seven datastores where leadership thought there were three is a normal first finding and it is half the argument for having a radar at all.

Place items by decision, not by novelty

The rings are statements about how confidently something may be used:

Adopt — the default for new work. Keep this list short; if everything is adopted, nothing is a default.

Trial — bounded use with someone watching, and a date to decide.

Assess — investigation only, not in production.

Hold — in use, do not extend it.

Retire — with an owner and a removal plan.

Hold and retire are where the consolidation value is, and they are the rings first radars usually leave empty.

Decide with the people who will live with it

A radar written by an architecture function and published is ignored. Run it as a working session with senior engineers from each area, where each item's ring is argued and the rationale recorded. The session is most of the value: it is the first time the organisation has had the conversation.

Give it consequences

On-radar choices are self-service; off-radar choices need a decision record and a review. Without that link the radar is advisory and will be ignored.

Cadence

Quarterly. Annual is slower than the decisions it is meant to inform, and each movement between rings gets a one-line rationale so the history is readable.

What not to do

Do not copy a published industry radar. It knows nothing about your skills, your contracts or your estate — it is input, not output.