Technology Radar & Standards

A Principal Engineer's technical strategy is only as effective as the standards and technology choices that implement it. Without a clear framework for what the organization adopts, trials, assesses, and holds, every team makes independent technology decisions — and the result is a sprawling landscape of languages, frameworks, databases, and tools that nobody can reason about holistically.

The Technology Radar model, popularized by ThoughtWorks, gives engineering organizations a shared vocabulary for technology governance. It classifies technologies into four rings — Adopt, Trial, Assess, and Hold — and provides a structured process for moving technologies between those rings. When done well, a technology radar reduces decision fatigue for teams, prevents unnecessary fragmentation, and creates space for controlled experimentation.

The Four Rings

Adopt

Technologies in the Adopt ring are the organization's defaults. When a team starts a new project, these are the tools and frameworks they should reach for first. There is strong organizational support — documentation, tooling, training, and internal expertise.

Languages:        Go, TypeScript
Databases:        PostgreSQL, Redis
Message brokers:  Kafka
Observability:    OpenTelemetry + Grafana
CI/CD:            GitHub Actions
Infrastructure:   Terraform + Kubernetes

The Adopt ring should be small. If everything is in Adopt, nothing is. A good target is 10-20 technologies that cover the core needs of 80% of projects.

Trial

Technologies in the Trial ring are being actively tested in production on a limited basis. One or two teams are using them on non-critical workloads. The organization is gathering evidence about whether these technologies should move to Adopt or back to Assess.

Trial technologies need an explicit owner — a team or individual who is responsible for documenting their experience and reporting back. Without an owner, trials drift indefinitely and become de facto standards without the support infrastructure that standards require.

Assess

Technologies in the Assess ring are on the organization's radar but have not been tried in production. Someone has evaluated them, found them potentially promising, and recommended further investigation through a proof of concept or structured evaluation.

Hold

Technologies in the Hold ring are explicitly not recommended for new projects. This does not mean existing systems must be migrated immediately — it means no new investment. Hold technologies are either ones the organization tried and moved away from, or ones that are redundant because a better alternative is in Adopt.

The Hold ring requires careful communication. Engineers who built systems on a Hold technology may feel their work is being criticized. Frame it clearly: "This technology served us well. Our needs have evolved, and for new projects, we recommend X instead."

Evaluating New Technologies

The most common failure mode is evaluating technologies based on excitement rather than fit. When a team proposes a new technology, run it through a consistent set of questions:

1. What problem does this solve that our current stack cannot?
2. How mature is it? (Community size, release cadence, corporate backing)
3. What is the operational cost? (Hiring, training, on-call burden)
4. How does it interact with our existing infrastructure?
5. What is the migration path if we decide to move away from it?
6. Who in the organization will own expertise in this technology?
7. What are the security and compliance implications?

At a logistics company, an engineering team proposed replacing PostgreSQL with CockroachDB for a new service that needed multi-region writes. The Principal Engineer ran the evaluation and found that while CockroachDB solved the multi-region problem, the organization had zero operational experience with it and the service's actual latency requirements could be met with PostgreSQL logical replication plus an application-level conflict resolution layer. The boring solution won because the framework forced the conversation beyond "this technology is cool" into "this technology fits our context."

Proof of Concept Requirements

When a technology moves from Assess to Trial, require a structured proof of concept:

Use production-like data volumes, not toy datasets
Test failure modes, not just happy paths
Measure operational overhead: deployment time, monitoring, on-call experience
Document the experience in a format that other teams can reference

A fintech company's Principal Engineer required every Trial technology to produce a one-page "operational readiness report" before broader adoption. The report covered deployment, monitoring, backup, restore, scaling, and incident response. This single requirement prevented three technologies from moving to Adopt because teams discovered unacceptable operational gaps that were invisible during initial evaluation.

Building Consensus on Standards

Standards imposed from above fail. Standards that emerge from consensus stick. When proposing a new standard, write an RFC that explains not just what the standard is, but why it matters and what alternatives were considered:

RFC-2024-031: Standard Observability Stack

Problem: Teams use 6 different observability approaches, making
cross-service debugging nearly impossible.

Proposed standard: OpenTelemetry for instrumentation, Grafana for
dashboards and alerting, Loki for logs.

Alternatives considered:
- Datadog (rejected: cost scales poorly beyond 200 services)
- Elastic stack (rejected: operational burden too high)

Migration path: New services must use the standard stack. Existing
services migrate within 6 months with platform team support.

Give the RFC at least two weeks for review. Hold a synchronous meeting for the most contentious points. The goal is not unanimity — it is informed consent. People need to feel heard, even if the final decision does not go their way.

Handle disagreement by acknowledging trade-offs openly and providing escape hatches: "If your workload genuinely cannot be served by the standard, bring a proposal to the architecture review. We will evaluate it on its merits."

When to Standardize & When to Allow Diversity

Standardize When

Operational cost scales with diversity. If every database choice adds on-call burden, standardize databases.
Team mobility matters. If engineers move between teams, standardize the tools they interact with daily.
Cross-system integration is common. If services communicate frequently, standardize communication patterns, serialization formats, and API contracts.

Allow Diversity When

The problem domain is genuinely diverse. A machine learning team and a web application team have fundamentally different needs.
Innovation requires experimentation. The Trial and Assess rings exist for this reason.
The cost of standardization exceeds the cost of diversity. Migrating 50 stable, rarely-modified services may not be worth the effort.

A healthcare technology company standardized on Java for all backend services. When they started building real-time data processing pipelines, Java's garbage collection pauses made it poorly suited for low-latency requirements. The Principal Engineer created an exception for data pipeline services, allowing Rust for latency-critical paths. The exception was explicit, documented, and bounded — not a blanket permission to use any language.

Governance Without Bureaucracy

If getting a new library approved takes six weeks and three committee reviews, engineers will quietly add it and hope nobody notices.

Default to trust. Teams can use anything in Adopt without asking. They need approval only for technologies outside the radar.
Right-size the review. A new npm package needs a security scan, not an architecture review. A new database needs thorough evaluation. Scale governance to the risk.
Automate compliance. Use build-time checks to flag non-standard dependencies rather than relying on manual reviews.
Publish the radar publicly. Make it easy to find and easy to read.

Example: automated governance in CI

step: check-technology-compliance
  script: |
    ./scripts/check-radar-compliance.sh
    # Warns for Hold technologies
    # Info for Trial technologies
    # Passes for Adopt technologies
    # Blocks only for explicitly banned technologies

For technologies not on the radar, hold a lightweight architecture review — a 30-minute conversation, not a committee meeting with formal presentations. At a media company, the Principal Engineer held weekly "tech office hours" — an open 30-minute slot for technology proposals. Most weeks, no one showed up. When someone did, the conversation was informal and productive. The low barrier meant teams actually used the process.

Updating the Radar

Review the radar quarterly. Each review should ask: Are any Adopt technologies showing cracks? Have Trial technologies proven themselves? Are there technologies in Assess worth trialing? Are there technologies not on the radar worth watching? Publish changes with context — a paragraph explaining each change, not just a spreadsheet update.

Real-World Example: Building a Radar from Scratch

A Series C startup with 80 engineers had no technology radar. Each of 12 teams made independent choices, resulting in four programming languages, three relational databases, two message brokers, and five configuration management approaches.

The Principal Engineer cataloged what existed by surveying every team and mapping operational support capacity. She found the team could operationally support about 40% of the technologies in production.

She drafted a radar as an RFC. The most contentious discussion was about languages — the Go and Python teams both wanted sole Adopt status. She put both in Adopt with clear guidance: Go for performance-critical services and infrastructure tooling, Python for data pipelines and internal tools.

The radar took three months from survey to published standard. Within six months, three teams had voluntarily migrated off Hold technologies because the Adopt alternatives had better tooling support. The radar's value was not in the document itself but in the conversations it forced and the shared vocabulary it created.

Common Pitfalls

Creating a radar and never updating it. A stale radar is worse than no radar because people lose trust in the process. Commit to quarterly reviews.
Putting too many technologies in Adopt. If the Adopt ring has 40 technologies, it provides no guidance. Be disciplined about what earns Adopt status.
Failing to provide migration support. Telling teams their technology is now Hold without helping them migrate breeds resentment. Budget time and resources for migration assistance.
Confusing preferences with standards. A standard is "all services must use structured logging." A preference is "we recommend structured logging." Be clear about which is which.
Ignoring operational readiness. A technology can be technically excellent but operationally disastrous if no one knows how to run it in production.
Governing too tightly. If teams need approval for every library version bump, the process will collapse. Focus governance on high-impact decisions.
Not involving teams in the process. A radar created in isolation by one person will face resistance. The collaborative process is as valuable as the artifact.

Key Takeaways

The Technology Radar model (Adopt, Trial, Assess, Hold) provides a shared vocabulary for technology governance that reduces decision fatigue and prevents uncontrolled sprawl
Evaluate new technologies through a structured framework that considers operational cost, organizational fit, and migration risk — not just technical capabilities
Build consensus on standards through RFCs and open discussion rather than top-down mandates
Standardize where diversity creates operational cost or hinders team mobility; allow diversity where problem domains genuinely differ or innovation requires experimentation
Governance should be lightweight and automated where possible — default to trust, right-size reviews, and make compliance easy
The radar is a living document requiring quarterly review and transparent communication about changes
The process of building a radar — the conversations, surveys, and debates — is often more valuable than the final document