magnus919/hermes-profiles/technology-radar

Technology Radar

CTO methodology for making technology decisions, governing architecture, measuring engineering effectiveness, managing technical debt, and operating an innovation pipeline. These frameworks help a CTO balance short-term delivery velocity with long-term platform health.

Domain Model

When to Load

Load this skill when the task involves:

• Evaluating a new technology or tool for adoption
• Making a build-vs-buy decision with TCO analysis
• Designing or auditing architecture governance processes
• Setting up engineering metrics dashboards (DORA, SPACE)
• Quantifying and prioritizing technical debt remediation
• Running an innovation pipeline with POC-to-production gates
• Deprecating or retiring legacy technology
• Conducting an architecture review board session

Loading Order

skill_view('technology-radar')                      # This — methodology index
skill_view('executive-methodology')                  # Shared decision frameworks
skill_view('artifact-pyramids')                      # Output contract
skill_view('technology-radar', file_path='references/technology-radar.md')
skill_view('technology-radar', file_path='references/build-vs-buy.md')
skill_view('technology-radar', file_path='references/architecture-governance.md')
skill_view('technology-radar', file_path='references/engineering-metrics.md')

Reference Files

Design Principles

1. Technology is a means, not an end. Every technology decision must trace back to a business outcome. "Because it's new" is not a reason to adopt. "Because it solves X faster/safer/cheaper" is.
2. Radar is a living document. A technology radar updated once a year is a museum. Update it quarterly, or every time a significant adoption/hold/promote/promote-to-trial decision is made.
3. Build vs buy is never just cost. Total Cost of Ownership includes maintenance, hiring, training, integration, migration, and opportunity cost. A cheaper build today may be vastly more expensive over 3 years.
4. Engineering metrics measure the system, not the people. DORA metrics measure the delivery capability of the org. SPACE measures developer satisfaction. Neither is a performance review tool for individuals.
5. Technical debt has a principal and an interest payment. The principal is the cost to fix it properly. The interest is the recurring drag on velocity. Prioritize debt where interest/principal ratio is highest.
6. Production readiness gates exist to prevent crisis. Every gate that is skipped in the name of speed will be paid for in incident response time later.

Related Skills

• executive-methodology — shared decision frameworks and governance
• operational-design — COO-side process design and scaling
• artifact-pyramids — output contract specification
• platform-engineering — infrastructure and CI/CD implementation patterns