intermediate 2 min answer

An organisation maintains a technology radar that nobody consults before choosing tools. What makes a radar useful rather than decorative?

druvaradarstandardsgovernanceadoption
Show the full answer Hide the answer

Why it is ignored

  • It has no consequence. A radar with no relationship to what teams can actually provision, deploy or expense is a list of opinions.
  • It is not where decisions are made. Teams choose tools when building, and the radar lives in a document they visit annually.
  • It is out of date, which is inevitable if it is maintained by a central group rather than fed by the teams doing the work.
  • The categories are unclear. "Assess" and "trial" mean nothing operationally, so a reader cannot tell whether they are allowed to use something.

What makes it useful

  • Categories tied to consequence: adopt means it is on the paved road and supported; trial means you may use it and must record why; hold means new usage requires an exception with a named approver; retire means there is a migration date.
  • Placed where the decision happens — in the service template, in the provisioning tooling, in the review checklist — rather than in a document.
  • Fed by teams, with entries proposed by whoever is using something and reviewed rather than authored centrally.
  • A small number of entries. A radar with two hundred items expresses no preference; thirty means something.
  • A stated reason per entry, so a team can judge whether the reason applies to their case.

What it should govern

Only the choices where inconsistency across the organisation is genuinely costly: primary datastores, observability, identity, deployment, languages and runtimes with an operational cost. These have real network effects — expertise, tooling, on-call knowledge, hiring — and divergence is expensive.

Not libraries, frameworks within an established language, testing tools, or anything where a team can bear the consequence of its own choice alone.

The stronger mechanism

A paved road beats a radar. A template producing a compliant, observable, deployable service using the standard stack is used because it is fastest, and it enforces the standard without governance. The radar is the documentation of what the paved road contains, and where the paved road does not exist, the radar is an aspiration.