As the executive sponsor of an enterprise-wide tech radar program, how would you structure ownership, cadence, and metrics so the radar actually balances innovation against stack consolidation instead of either stalling into pure bureaucracy or becoming an ignored document nobody consults?

## The problem at enterprise scale At enterprise scale — dozens to hundreds of teams — the tech radar stops being primarily a technical artifact and becomes an **organizational-design problem**: - who has the legitimacy to make a binding decision on behalf of teams they don't manage, - how fast can that legitimacy act, - and how do you know the whole apparatus is actually earning its overhead rather than becoming ignored bureaucracy. ## Who owns the radar **Ownership:** a single central architect owning the radar tends to fail in one of two predictable ways: - either they lack the domain depth to evaluate proposals across every team's specialty and end up rubber-stamping or reflexively blocking, - or, more commonly, their decisions get perceived as personal taste rather than organizational consensus, so teams route around them. The more durable pattern is a **standing cross-team body** — an architecture guild, a Cloud Center of Excellence, a principal-engineer council — with rotating representation drawn from the major engineering areas, so a Trial-to-Adopt promotion decision carries the weight of 'the organization decided this' rather than 'one architect liked it.' That body needs an actual charter: - who can propose, - what evidence is required, - how ties are broken, - and, critically, how its own decisions get revisited if circumstances change. A governance body with no update mechanism ossifies exactly like the radar itself does when neglected. ## Cadence A single fixed review rhythm doesn't fit every kind of decision. - **Routine ring movement** (something graduating from Trial to Adopt after a successful pilot) fits a predictable, calendar-driven cadence — commonly quarterly — because it lets teams plan proposals around it and keeps the review body's workload bounded and schedulable. - **But security- and vendor-driven changes** (a critical CVE, a vendor announcing sudden end-of-life) cannot wait for a quarterly cycle without leaving the organization exposed, so a genuinely mature program runs a second, fast, out-of-band track specifically for deny-list-worthy events, explicitly decoupled from the routine cadence. Conflating the two — forcing an urgent security deny through the same slow quarterly process as a routine promotion — is a common and costly design mistake. ## Where scrutiny should concentrate **Balancing innovation against consolidation, the core tension in the question:** the mistake many programs make is applying uniform scrutiny to every ring. The actual organizational cost of a technology lives almost entirely at the Adopt ring and in deprecation — that's where training material, golden-path templates, on-call runbooks, and shared library investment get built, and where deprecating something later means unwinding all of that across every team that took the org's own recommendation seriously. Assess and Trial, by contrast, are cheap: a handful of engineers spending a sprint on a contained pilot costs little even if it goes nowhere. The right design keeps entry to the outer rings deliberately low-friction and high-volume — the organization wants a wide funnel of exploration — while concentrating real scrutiny, and a genuinely high bar, on the transition into Adopt and on running deprecations well, because those are the decisions with organization-wide blast radius in both directions (locking in a bad default, or failing to properly retire one). ## Shelfware, and how to see it **Avoiding shelfware and measuring it honestly:** a radar that nobody consults is worse than no radar, because it creates a false sense that governance exists. The signal that a program has become shelfware is usually structural, not anecdotal — - nobody submits new Assess proposals, - ring placements haven't changed in multiple review cycles, - or, most tellingly, new projects aren't actually defaulting to Adopt-ring choices even though the radar says they should. A principal running this program should track metrics deliberately in both directions: - **Growth-side metrics** (proposal volume into Assess, Trial-to-Adopt promotion rate) show the exploration funnel is alive. - **Consolidation-side metrics** (count of distinct technologies per category over time, Hold items whose dependent count has actually reached zero versus ones stuck at 'still migrating' for years, time-to-decision on pending proposals) show the program is doing the harder, less glamorous half of its job — actually shrinking the footprint, not just publishing new entries. A radar whose technology count only ever grows, however well-attended its quarterly meetings are, has failed at the consolidation half of its mandate even if the innovation half looks healthy. ## Three ways the program goes wrong **Failure modes at this scale:** - the review body becomes a rubber stamp that approves everything to avoid political friction, so the radar loses its consolidation function entirely; - or it becomes an over-cautious bottleneck that teams learn to avoid by not submitting proposals at all, pushing technology choice back underground into shadow IT; - or the fast-path security track gets skipped under the false belief that 'everything goes through the quarterly review,' leaving a known critical CVE live for months. ## How a large enterprise runs it A concrete instance: this is close to how a large bank's enterprise architecture function typically operates its Cloud Center of Excellence — a standing, cross-divisional body runs quarterly radar reviews for routine technology promotion while security holds an independent, always-on fast-track authority to deny-list a vulnerable dependency same-day, and leadership tracks both new-technology intake volume and the shrinking count of legacy platforms still awaiting full decommission as the program's actual health metrics, rather than treating a published radar diagram alone as evidence the governance is working.