Who Moves the Dots?
A Tech Radar is useless if it is dictated by an Ivory Tower Architect who hasn't written production code in years. Developers will ignore it, route around it, or comply on paper while violating it in practice.
The governance process must be Guild-Driven — meaning the people who use the technologies every day have a formal voice in the decisions.
The Guild model works like this:
- The Guild: A standing group of Senior and Staff Engineers from different product teams, plus representatives from Platform Engineering and Security. They meet monthly or quarterly.
- The Proposal (RFC): If a developer wants to move a technology — for example, promoting "Kotlin" from Assess to Trial — they write a short Request for Comments (RFC) document. This is not bureaucracy for its own sake; it forces the proposer to think rigorously about the implications.
- The Evaluation Criteria: The guild evaluates proposals against a standard rubric:
- Does it solve a problem that our current "Adopt" tools genuinely cannot solve, or solve poorly?
- Who will own it? Who will be on-call for it?
- How does it integrate with our existing observability stack (metrics, logs, traces)?
- What are the security implications? Does it have a strong CVE track record?
- What is the hiring market like for this skill?
The RFC Template (Minimal)
A good RFC for a radar change doesn't need to be long. A one-page document covering these points is sufficient:
## Technology: [Name]
## Proposed Movement: [From Ring] → [To Ring]
### Problem Statement
What specific problem does this solve that our current Adopt-ring tools cannot?
### Evidence
- Production usage at other companies (links to case studies)
- Internal prototype results (if moving from Assess to Trial)
- Performance benchmarks (if relevant)
### Risk Assessment
- Security: [CVE history, audit status]
- Hiring: [Market availability of engineers]
- Operational: [Observability, debugging tooling maturity]
### Support Plan
- Who owns this if it breaks at 3am?
- What Golden Path support will the Platform team provide?
### Rollback Plan
- If the Trial fails, how do we migrate back?
The "Golden Path" Connection
Your Platform Engineering team builds Golden Paths — opinionated templates, CI/CD pipelines, and scaffolding — primarily for items in the Adopt ring.
If a team chooses a Trial technology, they must explicitly accept that there is no Golden Path. They are responsible for their own tooling, their own pipeline configuration, and their own debugging when the compiler breaks at 2am. This is sometimes called the "You build it, you run it, you fix it" contract for Trial-ring technologies.
This creates a natural economic incentive: choosing an Adopt-ring technology is fast and cheap (the platform does the heavy lifting). Choosing a Trial-ring technology is slower and more expensive (the team carries the full burden). Teams that want to use Trial technologies must justify that the benefit outweighs this cost.