practice

Ring Promotion Evidence

also called Blip Promotion Criteria, Radar Promotion Gate

The named evidence required to move a technology between radar rings - the control that stops a ring label transferring support cost from the team that wanted a technology to the group that has to operate it.

technology radarringsevidenceplatform ownershipreversibility

An architecture group votes a technology from assess to adopt. In their scheme adopt means the paved road will support it and teams may use it without a waiver. The evidence is one production use: a six-week internal tool, built by the two engineers who proposed it, still running.

The vote created three obligations for somebody else. The platform group now owes a supported build, an upgrade owner, and a place in the on-call rotation's mental model - none of which was discussed, because the discussion was about the technology rather than about the ring. Ring promotion evidence is the published answer to "what has to be true before a blip moves". Without it, a radar wired to a paved road becomes a mechanism for transferring cost from proposers to operators by majority vote.

Why it matters

The asymmetry is the whole argument. Promotion is cheap and demotion is not. Declining costs a conversation; reversing an adopt two years later means funding a migration for every service that took the ring at its word - 40 services at a couple of days each is roughly 100 days of other teams' work - so the moment of cheap refusal is the only moment the decision is genuinely open.

The evidence most proposals carry is evidence of the wrong thing. A pilot shows the technology can do the job, which is rarely the question. Support cost is dominated by upgrade behaviour and by how the thing fails to somebody who did not choose it, and a six-week pilot with its authors present measures neither. And if adopt removes a waiver requirement, teams who were not in the room are entitled to treat it as a promise.

Implementation patterns

  • Publish the bar with the rings. A workable ladder: assess needs curiosity; trial needs one team's production use with a time box and a named owner; adopt needs two independent teams in production and one survived upgrade.
  • Require the second team to be independent of the proposers. This is the load-bearing criterion - it tests whether the technology is adoptable without its champions available, which is the condition the estate will be in.
  • Count one handled incident as evidence. A technology nobody outside the proposing team has debugged under pressure is unassessed on the dimension that costs most.
  • Attach a person to every promotion: a named upgrade owner and a stated support window on the blip, plus one line on what the estate does if this is demoted in two years.
  • Keep a demotion path with its own evidence - two attributable incidents, a vendor abandoning it, a credible successor - so hold means something and the radar is not monotonic.
  • Date every blip, so nothing sits in trial for four years.

Industry example

Thoughtworks has published its Technology Radar since 2010, sorting technologies into adopt, trial, assess and hold from blips submitted by project teams and curated centrally. Its rings are deliberately advisory: the artefact is an opinion published twice a year, and nothing behind it commits anyone to operating anything.

That is the distinction organisations copying the format usually miss. The published radar's rings carry no support obligation, so its promotion bar is editorial judgement. An internal radar wired to a paved road and a waiver gate has rings that carry cost, and it needs an evidence bar the original never required. Copying the four rings without adding the bar produces an artefact that looks advisory and functions as procurement.

Failure scenarios

  • Promotion on proposer evidence, the default outcome wherever the proposer also presents the case.
  • A ring wired to a mechanism nobody reads as a mechanism, so the group believes it publishes advice while teams correctly read permission.
  • No upgrade owner, so the first major version bump has no funded path and the technology quietly becomes unsupported while still sitting in adopt.
  • A radar that only promotes. Without a demotion bar every technology ever trialled stays on adopt and the paved road's support surface grows without limit.
  • Evidence satisfied by a proof of concept labelled production. Specify what production means - real users, real data, on-call coverage - or the bar is met by renaming.

Trade-offs

Choose Gains Pays
Published evidence bar support cost consented to before it lands - fewer unowned technologies slower adoption of good tools - the radar lags the estate
Editorial judgement only fast - cheap - captures emerging practice early obligations transferred by vote - demotion requires funding migrations

The honest cost: an evidence bar will delay something that was right. Requiring two independent teams means somebody goes first without the paved road, which is friction aimed at exactly the people you want experimenting. The trial ring exists to absorb that, and a radar without a usable trial ring makes the bar punitive instead of orderly.

When not to use it

When the radar has nothing wired behind it. No paved road, no waiver gate, no platform commitment: the rings are opinions, and a two-team rule turns the radar into a lagging inventory of what you already run.

In an organisation under roughly 50 engineers, where there is one team, the second-independent-team criterion is unsatisfiable, and the decision is a conversation among the people who will operate it.

For a technology inside a single team's blast radius. A build tool nobody else depends on needs no ring. Reserve the radar for choices whose consequences land on people who did not make them.

Interview question

Q: Your internal radar's adopt ring removes the waiver requirement and puts a technology on the paved road. A team proposes promoting a database they have run in production for six weeks on one internal tool, and points out that the radar is published quarterly so a delay costs them a quarter. How do you respond, and what do you change so this argument does not recur?

What a strong answer covers: separating the team's actual need - permission to keep using it - from the request, a ring change that binds the estate, and meeting the first with a time-boxed trial entry plus a governed exception · naming the three obligations adopt creates and asking who owns each · why the second independent team is the criterion that matters · and the promotion and demotion asymmetry.

Quick check

Quiz: Why does an adopt vote on one team's six-week pilot transfer cost rather than record an opinion? — Adopt in that scheme obliges the platform group to provide a supported build, an upgrade owner and on-call familiarity, none of which the pilot evidenced and none of which the proposers pay for.

Flashcard: Which single promotion criterion matters most and why? — A second team in production that did not propose the technology. It is the only test of whether the thing is adoptable without its champions in the room, which is the condition the rest of the estate will be in.