magnus919 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.
When Not to Use
- Route enterprise capability maps, operating-model design, and current/target-state roadmaps to
enterprise-architecture. This skill stays focused on technology portfolio posture and governance mechanics; usesoftware-architecturefor system-level target design. - Route the durable record of one consequential decision to
adr-authoring; use this skill to choose the governance path and connect the decision to standards or radar feedback. - Route system design and code changes to the relevant engineering skill, security requirements and threat modeling to
secure-software-engineering, and live operations or SLO work tosite-reliability-engineering.
Domain Model
| Domain | Covers | Artifact |
|---|---|---|
| Technology Radar | Adopt/Trial/Assess/Hold quadrants, tool selection criteria, deprecation policy | Technology radar document |
| Build vs Buy | TCO analysis, decision matrices, vendor evaluation, integration cost | Build-vs-buy recommendation |
| Architecture Governance | Automated policy, federated decisions, advice processes, centralized review, standards, exceptions, and feedback | Governance decision record, standard, exception, radar update |
| Engineering Metrics | DORA (deploy frequency, lead time, MTTR, change failure rate), SPACE, DevEx | Engineering dashboard, health report |
| Technical Debt | Interest calculation, remediation prioritization, principal estimation | Technical debt register |
| Innovation Pipeline | Horizon scanning, POC criteria, production readiness gates | Innovation funnel, POC report |
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
- Selecting or auditing automated policy, federated decisions, advice processes, or centralized review
Governance Workflow
For architecture or technology-governance work, read references/architecture-governance.md and:
- Establish the decision, intended outcome, affected systems and teams, evidence available, and the decision owner.
- Assess reversibility, scope, risk, blast radius, regulatory exposure, and cross-team impact. Record uncertainty instead of converting it into a false score.
- Select the lightest governance mode that still controls the credible downside: automated policy, federated decision, advice process, or centralized review. Escalate when evidence shows that the decision is less reversible, broader, riskier, or more regulated than first assumed.
- Define the decision record, implementation checks, exception path, and signals that will cause reconsideration.
- Feed implementation and operational evidence back into the decision, standards, exceptions, and radar posture. Treat feedback as a reason to learn, not as retroactive blame.
Reference Files
| Reference | Load When | File |
|---|---|---|
| Technology Radar | You need to evaluate and categorize a technology or tool for adoption, trial, assessment, or hold | references/technology-radar.md |
| Build vs Buy | You're comparing build vs buy options with TCO analysis and decision criteria | references/build-vs-buy.md |
| Architecture Governance | You're choosing or auditing proportional governance modes, standards, exceptions, escalation, or feedback | references/architecture-governance.md |
| Engineering Metrics | You need to measure engineering effectiveness with DORA, SPACE, or DevEx frameworks | references/engineering-metrics.md |
Design Principles
- 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.
- Radar is a living document. A technology radar should be refreshed when evidence, strategy, risk, or usage changes materially. Set a cadence that fits the portfolio, and make significant adoption, hold, promotion, or retirement decisions trigger an update rather than waiting for a calendar event.
- 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.
- 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.
- 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.
- 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.
- Governance should follow consequence. Local and reversible decisions should stay local; irreversible, regulated, high-blast-radius, or materially cross-team decisions need stronger coordination or authority.
Portability
This skill is intentionally host-neutral. Use your agent's normal mechanisms to load the references, templates, and scripts listed here. Do not assume a particular profile system, task orchestrator, memory service, or response-handoff format.