How can a technology radar function as lightweight governance, and what makes it degrade into a list nobody consults?

What it is for

A radar places technologies into rings — commonly adopt, trial, assess, hold — as a shared, published statement of the organisation's current position, updated periodically.

Its value is that it is advisory, specific and revisable, which makes it usable where a formal standards document is not. It answers the question an engineer actually has: "is it acceptable to use this here, and what does the organisation already know about it?"

Why it works better than a standards document

• It has a temporal dimension. "Assess" and "trial" express genuine organisational states that a binary approved/forbidden list cannot, and most technologies are in one of those states.
• It is expected to change, so updating it is routine rather than an amendment process.
• It records reasoning, not just verdicts — which is what makes it useful to someone deciding.
• It is discussable. A team can argue that something should move rings, and that argument is the governance functioning rather than failing.

Making it real

• Entries carry a short rationale and a named contact — someone who has actually used it here and can be asked. Without the contact it is an opinion; with it, it is a route to experience.
• Ring changes require evidence from within the organisation, not from external popularity. A radar reflecting industry fashion rather than internal experience is worse than nothing, because it carries institutional authority it has not earned.
• "Hold" means something specific: no new usage, existing usage documented, with a migration plan where the hold is due to risk rather than preference.
• Reviewed on a fixed cadence by a group with actual practitioners on it, not only architects.
• Linked to the paved road — adopt-ring technologies should be the ones with platform support, and a divergence between the radar and the platform's actual capabilities is a defect in one of them.
• Published where engineers already are, and referenced in design reviews and templates.

How it degrades

• Written once and never updated, becoming a snapshot of a past enthusiasm and losing credibility permanently.
• Compiled by architects with no recent implementation experience, so practitioners recognise it as disconnected and ignore it.
• Treated as binding, at which point it stops being a shared view and becomes a gate — and the honest discussion that made it valuable ends.
• Too large. A radar with two hundred entries is a catalogue; the useful version is opinionated and short, covering the decisions that recur.
• Rings assigned by preference rather than evidence, which is detectable and destroys trust.
• Disconnected from procurement and platform reality, so "adopt" describes something the organisation cannot actually provision.

The honest limitation

A radar is not a substitute for governance of expensive, irreversible decisions. It works well for the frequent, low-stakes question of "which library, which tool, which pattern", and it is not the mechanism for deciding a core datastore or a strategic vendor.

Conflating the two produces either an overweight radar or an under-governed strategic choice, and the practical answer is to keep the radar advisory and handle the small number of genuinely significant decisions through a review with authority.