{
  "schema_version": 1,
  "skill_name": "technology-radar",
  "evals": [
    {
      "id": "quadrant-placement",
      "prompt": "Our engineering org wants a technology radar to govern what we adopt. We are considering several technologies including a new frontend framework, an internal tool we already use everywhere, and a database that won a hackathon. How do I place technologies in the Adopt, Trial, Assess, and Hold quadrants, and what distinguishes them?",
      "expected_output": "A radar placement framework with the quadrants defined by their operational meaning: Adopt for technologies we use widely with demonstrated fit and are confident recommending; Trial for technologies we are running in limited production scope with deliberate evaluation; Assess for technologies we are exploring with a small prototype to build evidence; and Hold for technologies we deliberately do not adopt or are phasing out. The response applies the definitions to the examples: the frontend framework goes to Assess or Trial depending on evidence so far, the internal tool's placement depends on whether it is a proven default (Adopt) or a growing liability (Hold), and the hackathon database goes to Assess — exploration is fine, but a hackathon demo is not evidence for production adoption. It explains the cardinal rules: a technology cannot move to Adopt without production evidence, Hold is a decision not a punishment, and placement is reviewed on a cadence.",
      "assertions": [
        "The quadrants are defined by operational meaning: production evidence, trial scope, exploration, and deliberate non-adoption",
        "Each example technology is placed with reasoning tied to evidence",
        "The hackathon-database example is placed in Assess with the explanation that demos are not adoption evidence",
        "The rules about evidence requirements for Adopt and the meaning of Hold are stated",
        "A review cadence for placements is included"
      ]
    },
    {
      "id": "build-vs-buy-tco",
      "prompt": "We need a feature that some teams think we should build and others want to buy. The build team says 'it is only a few weeks of work' and the buy advocates point to the sticker price. How do I structure a build-versus-buy decision with a real TCO analysis?",
      "expected_output": "A build-versus-buy decision structured around total cost of ownership rather than the sticker price or the build estimate: the response defines the cost model covering build cost (development plus ongoing maintenance, support, and feature evolution at a stated annual maintenance rate), buy cost (license or subscription plus integration, customization, and vendor management), and the less tangible dimensions: time to capability, control and extensibility, risk (abandonment, lock-in, security posture), and fit to the actual requirement. It makes the assumptions explicit — including that the build estimate usually understates maintenance — and identifies the decision's critical uncertainty with the smallest step to resolve it, such as a scoped trial of the vendor product against a prototype of the built version. The output names the decision, alternatives, evidence, and the conditions that would change it.",
      "assertions": [
        "TCO covers build plus maintenance and buy plus integration and vendor management, not just headline numbers",
        "Non-financial dimensions such as time to capability, control, and risk are included",
        "The maintenance-cost assumption and build-estimate optimism are made explicit",
        "The critical uncertainty and the smallest resolution step are identified",
        "The output records the decision, alternatives, evidence, and change conditions"
      ]
    },
    {
      "id": "deprecation-policy",
      "prompt": "We have a legacy database that is stable but increasingly hard to staff, and a library that we know is unmaintained and vulnerable. I want to move both to Hold and phase them out. What does a deprecation policy look like, and how do I communicate it without alienating teams?",
      "expected_output": "A deprecation policy that treats Hold as the start of a managed retirement, not a label: the response defines the policy components for each technology — the stated reason for the hold (maintainability, security, strategic fit), the transition guidance (what to use instead and who helps migrate), the timeline and milestones with migration support and owners, and the exceptions process for genuinely blocked cases. It explains the communication approach: the radar entry names the alternative and the support path so teams are not left stranded, deprecation is announced with enough runway for existing commitments, and the policy is enforced at the gate for new usage (no new systems on a Held technology) while existing systems get a realistic migration window. The response also covers measuring the retirement: tracking remaining usage and completing the removal when the last workload migrates.",
      "assertions": [
        "The policy defines reason, alternative, support path, timeline, owners, and an exceptions process",
        "Hold blocks new usage at the gate while existing systems get a migration window",
        "Communication includes the replacement and support so teams are not stranded",
        "The deprecation is measured by remaining usage with a defined completion",
        "The policy differentiates the database and library cases appropriately"
      ]
    },
    {
      "id": "governance-process",
      "prompt": "Right now any team can introduce any technology and we discover the consequences later. I want architecture governance that reviews technology choices without becoming a bureaucratic approval board that blocks everything. How do I design the process?",
      "expected_output": "A proportional governance process that first assesses reversibility, scope, risk, blast radius, regulation, and cross-team impact, then selects the lightest adequate mode: automated policy, federated decision, advice process, or centralized review. It gives each mode a clear authority model and minimum evidence, uses centralized review only for genuinely consequential choices, and records exceptions, conditions, and reconsideration triggers. It also closes the loop by feeding implementation and operational evidence into standards and radar decisions, while preserving explicit boundaries with enterprise architecture, ADR authoring, implementation, security engineering, and operations.",
      "assertions": [
        "The process assesses reversibility, scope, risk, blast radius, regulation, and cross-team impact",
        "Automated policy, federated decision, advice process, and centralized review are distinguished as governance modes",
        "The output avoids treating a standing board or fixed process timing as mandatory for every decision",
        "Exceptions include scope, reason, owner, compensating controls, and an expiry or revisit trigger",
        "Implementation and operational evidence feeds later standards or radar decisions"
      ]
    },
    {
      "id": "governance-mode-selection",
      "prompt": "A team wants to change an internal library used by three services. The change is easy to revert, has no regulatory implications, but could create incompatible interfaces if other teams are surprised. Which architecture-governance path should we use and what should we record?",
      "expected_output": "A federated decision or advice process is selected instead of mandatory centralized approval, because the change is reversible and bounded but has cross-team interface impact. The response names the local decision owner, affected consultees, compatibility checks, published scope, decision rationale, and an escalation condition if the change expands or creates an unresolved shared contract conflict.",
      "assertions": [
        "A local or federated path is preferred over centralized review because the change is reversible and bounded",
        "Cross-team interface impact leads to consultation, compatibility checks, or published notice",
        "The output names decision ownership and an escalation condition",
        "The response does not pretend that low risk means no coordination is needed"
      ]
    },
    {
      "id": "automated-policy-and-exception",
      "prompt": "We want a CI rule requiring approved encryption settings across all new services, but teams sometimes need a documented exception for an external integration. Design the governance approach.",
      "expected_output": "An automated policy is used for the objective encryption requirement, with a visible failing check, rationale, owner, and a bounded exception path. The exception record includes scope, reason, risk, compensating controls, accountable owner, expiry or review trigger, and closure evidence. The response says to escalate if exceptions become frequent or the rule is masking a judgment that automation cannot safely decide.",
      "assertions": [
        "The objective requirement is assigned to automated policy rather than a recurring manual approval",
        "The policy has an owner, visible failure output, and a stated rationale",
        "The exception path records scope, reason, compensating controls, owner, and expiry or revisit trigger",
        "Recurring or unsafe exceptions trigger policy review or stronger governance"
      ]
    },
    {
      "id": "governance-boundary",
      "prompt": "An executive asks for an enterprise capability map and target-state roadmap, while another team asks for an ADR template and a production incident runbook. Should the technology-radar architecture-governance method own all three?",
      "expected_output": "No. Enterprise capability mapping and target-state roadmaps belong to enterprise architecture; ADR structure belongs to ADR authoring; and incident response/runbooks belong to operations or SRE. Technology-radar may supply technology portfolio posture, governance-mode selection, standards, exceptions, and feedback links at the boundaries, but it should not absorb those neighboring workflows.",
      "assertions": [
        "Enterprise capability and target-state roadmap work is routed away from technology-radar",
        "The enterprise-architecture owner is named for capability and target-state work",
        "ADR authoring is identified as a separate neighboring owner",
        "Incident response and operational runbooks are identified as separate operational ownership",
        "The response preserves technology-radar's technology portfolio and governance boundary"
      ]
    },
    {
      "id": "tech-debt-prioritization",
      "prompt": "Our codebase has accumulated technical debt: an aging build system, duplicated modules, an outdated library with known issues, and a growing test suite that takes too long. The team wants to 'fix the debt' but disagrees on what to do first. How do I quantify and prioritize remediation?",
      "expected_output": "A technical-debt register and prioritization that makes the trade-offs visible: the response builds a register with an entry per debt item — principal (the cost of remediation estimated from the affected code), interest (the ongoing cost of not fixing: maintenance friction, incident risk, slower delivery), and the trigger conditions (the pain is paid when a change touches that area), then prioritizes by interest relative to principal and by how much the debt blocks current and planned work. The response explains the framework's rule: a debt is worth fixing when its interest exceeds the cost of remediation, and prioritization accounts for touch frequency — the build system that every change passes through pays interest daily and outranks a rarely touched module even if its principal is similar. It prescribes the sequencing and the metrics to show progress (remediation velocity, interest trend) so the work is not a one-time cleanup that regenerates.",
      "assertions": [
        "Debt items are entered in a register with principal, interest, and trigger conditions",
        "Prioritization compares interest to principal and considers touch frequency",
        "The frequently-touched build system is prioritized over a rarely touched module on interest grounds",
        "Sequencing and progress metrics are prescribed",
        "The framework prevents remediation from being a one-time cleanup that regenerates"
      ]
    }
  ]
}

# Architecture Governance

Architecture governance is a decision system, not a standing meeting. Its purpose is to keep consequential technology choices coherent while leaving routine, reversible choices with the people closest to the work. Select the governance path from the decision's consequences and evidence, not from an organization's preferred ceremony.

## Establish the Decision Context

Before choosing a process, capture:

- **Outcome:** the product, customer, operational, or organizational result sought.
- **Scope:** one component, one team, a shared capability, a portfolio, or the wider organization.
- **Reversibility:** how easily the choice can be changed, including data migration, contracts, training, and sunk operational work.
- **Risk and blast radius:** plausible harm, affected users and systems, failure propagation, and recovery options.
- **Regulation and obligations:** legal, contractual, safety, privacy, security, or audit constraints that require named controls or authority.
- **Cross-team impact:** coupling, shared interfaces, platform dependencies, duplicated investment, and coordination cost.
- **Evidence and uncertainty:** what is observed, what is assumed, and the smallest experiment or consultation that would reduce the important uncertainty.

Do not collapse these dimensions into a universal numeric threshold. A reversible decision with broad coordination cost may need advice or federation; a local decision can still require centralized authority when regulation or blast radius demands it.

## Choose a Governance Mode

Choose the least costly mode that controls the credible downside. A decision can move to a stronger mode when new evidence changes its consequence profile.

| Mode | Best fit | Minimum controls | Escalate when |
|---|---|---|---|
| **Automated policy** | The requirement is objective, repeatable, and machine-checkable, such as a required configuration or compatibility rule. | A stated rationale, an executable check, an owner, visible failure output, and a bounded exception path. | The check is a proxy for a judgment, exceptions become common, or the policy creates material cross-team or regulatory consequences. |
| **Federated decision** | A team or domain owns the outcome and the choice is local or reasonably reversible, while a shared convention prevents avoidable divergence. | Local decision authority, published decision and scope, compatibility expectations, and a route for affected peers to raise a conflict. | Shared interfaces, platform dependencies, duplicated investment, or accumulated divergence makes the choice enterprise-relevant. |
| **Advice process** | The proposer owns the decision but needs input from people who bear consequences or hold relevant expertise. This is useful for cross-team conceptual integrity without default veto power. | Named proposer and owner, identified consultees, written advice and dissent, response to material concerns, and a recorded decision. | Advice identifies an irreversible or high-blast-radius change, a mandatory control, unresolved authority conflict, or a need for portfolio-level coordination. |
| **Centralized review** | The choice is difficult to reverse, high impact, materially regulated, or spans teams that cannot resolve the trade-off locally. | A named decision authority, concise evidence package, alternatives and consequences, affected-team input, decision record, conditions, and an appeal or escalation route. | The authority lacks the required expertise, evidence is too weak for a responsible decision, or the review is redesigning implementation rather than governing the boundary. |

The modes are not maturity levels. Automated policy is not automatically more decentralized than advice, and a centralized review is not automatically better. Match authority, consultation, and automation to the failure modes the decision can create.

## Standards and Guardrails

Create a standard only when a shared rule produces more value than local variation. Each standard should state:

1. **Intent and benefit:** the problem or risk it addresses.
2. **Scope:** the systems, teams, lifecycle stages, and explicit exclusions.
3. **Requirement:** a testable rule, recommendation, or decision constraint.
4. **Owner and authority:** who maintains it and who can change it.
5. **Enforcement mode:** automated check, federated expectation, advice, or review.
6. **Exception path:** who may grant an exception, what evidence is needed, compensating controls, expiry or revisit conditions, and how exceptions are visible.
7. **Feedback signals:** implementation and operational evidence that may confirm, weaken, or invalidate it.

Avoid counting standards as a proxy for governance quality. A small organization may need several precise controls; a large regulated estate may need more. Prefer deleting, combining, automating, or narrowing a standard when it no longer earns its coordination cost.

## Decision Records and Advice

Use a concise decision record for any choice whose rationale or consequences will outlive the current conversation. Include the context, options, chosen path, owner, affected parties, assumptions, conditions, evidence, and reconsideration triggers. Use an ADR when the decision itself needs durable architectural history; this reference governs how to select the process, not the ADR format.

For advice processes, distinguish advice from approval. The proposer must seek input from people materially affected, consider the advice, and explain unresolved disagreement. Advice does not silently create a veto. If a mandatory control or authority boundary exists, name it and escalate rather than disguising it as consultation.

## Feedback From Delivery and Operations

Close the loop after implementation and during operation:

- Compare the intended outcome and constraints with observed behavior.
- Record surprises, incidents, support burden, delivery friction, cost, performance, adoption, and exceptions.
- Decide whether to keep, narrow, automate, revise, supersede, or retire the standard or radar entry.
- Update the decision record and notify affected owners; do not silently rewrite history.
- Promote recurring evidence into a better guardrail or experiment, and remove controls that no longer prevent a meaningful failure.

Operational evidence does not transfer incident command or service ownership to this skill. It supplies feedback for technology posture and governance decisions; operations teams retain operational response and reliability ownership.

## Exceptions and Proportional Escalation

An exception is a governed deviation, not an informal bypass. Record the requested scope, reason, affected assets, risk, compensating controls, accountable owner, expiry or review trigger, and evidence of closure. Emergency exceptions may use a shorter path, but they still require retrospective recording and review when the immediate risk is controlled.

Escalate when any of these becomes true:

- the choice cannot be reversed without material customer, data, contract, or migration cost;
- the blast radius or cross-team impact exceeds the local owner's authority;
- a regulatory, legal, safety, privacy, or security obligation requires a designated control owner;
- local decisions are creating incompatible interfaces, duplicated platforms, or portfolio-level cost;
- evidence is insufficient to understand a material downside;
- an exception is recurring, expanding, or compensating controls are failing.

De-escalate when an experiment reduces uncertainty, automation makes the rule objective, ownership becomes local, or the change is safely reversible. Stronger governance should not persist merely because it was used once.

## Neighboring Ownership

- **Enterprise architecture:** capability maps, business/technology alignment, operating models, target and transition states, and enterprise roadmaps belong there. This skill governs technology portfolio posture and decision paths.
- **ADR authoring:** durable records for consequential decisions and their fitness evidence belong there. This skill decides when and how governance is applied.
- **Implementation skills:** code, service design, API contracts, data models, migrations, and platform changes belong to their specialist owners. Governance sets boundaries and evidence; it does not design every implementation.
- **Secure software engineering:** threat modeling, security requirements, authentication/authorization, and secure implementation belong there. A security obligation may be an escalation input or automated guardrail here.
- **Operations and SRE:** deployment operations, incident command, SLOs, monitoring, and recovery runbooks belong there. Their evidence feeds governance; this skill does not replace operational ownership.

## Practical Output

Produce an artifact that makes authority and learning inspectable:

```markdown
# Governance decision: [subject]

## Context
- Outcome:
- Scope and affected teams:
- Reversibility and blast radius:
- Risk, regulation, and cross-team impact:
- Evidence and uncertainty:

## Chosen governance mode
[Automated policy | Federated decision | Advice process | Centralized review]

## Authority and controls
- Decision owner:
- Consultees or approving authority:
- Required checks or conditions:
- Exception path and compensating controls:

## Feedback plan
- Implementation evidence:
- Operational signals:
- Reconsideration triggers:
- Owner and next review point:

## Boundary and links
- Radar entry or standard:
- ADR, if needed:
- Specialist implementation, security, or operations owners:
```

# Build vs Buy Decision Framework

A systematic approach to evaluating whether to build a capability internally or buy/license it from a vendor. The decision is never just about cost — it's about strategic control, opportunity cost, and long-term flexibility.

## Decision Tree

Use this as the first filter before doing any detailed analysis:

```
Is this capability core to our competitive advantage?
├── YES → Is it available to buy with acceptable terms?
│   ├── YES → Buy, but plan to insource over time
│   └── NO → Build (strategic investment)
└── NO → Is it a commodity?
    ├── YES → Buy (cheaper, faster, maintained)
    └── NO → Is the vendor market mature?
        ├── YES → Buy (market has validated solutions)
        └── NO → Build or partner (market is too immature)
```

## TCO Analysis

Total Cost of Ownership over a 3-year period. The first-year cost is often misleading — the true cost comparison requires a multi-year view.

### Build Costs (3-Year TCO)

| Cost Category | Year 1 | Year 2 | Year 3 | Total |
|---------------|--------|--------|--------|-------|
| Engineering (design + build) | $XXX | $XX | $XX | $XXX |
| Infrastructure (hosting, CDN, DB) | $XX | $XX | $XX | $XXX |
| Ongoing maintenance (20% of build/yr) | $0 | $XX | $XX | $XXX |
| Support & on-call rotation | $XX | $XX | $XX | $XXX |
| Documentation & training | $X | $X | $X | $XXX |
| Opportunity cost (what else could this team build?) | $XXX | $XXX | $XXX | $XXX |

### Buy Costs (3-Year TCO)

| Cost Category | Year 1 | Year 2 | Year 3 | Total |
|---------------|--------|--------|--------|-------|
| License/subscription fees | $XX | $XX | $XX | $XXX |
| Implementation & migration | $XX | $0 | $0 | $XX |
| Custom integration | $XX | $X | $X | $XXX |
| Training | $X | $X | $X | $XXX |
| Vendor management overhead | $X | $X | $X | $XXX |
| Renewal escalation (3-10% annual) | $0 | $X | $XX | $XXX |
| Exit cost (if vendor changes terms) | $0 | $0 | $0 | $XXX (contingent) |

### Hidden Costs (Often Missed)

**Build hidden costs:**
- Testing and QA infrastructure
- Security hardening and compliance certification
- Internal user support and troubleshooting
- Documentation maintenance
- Technical debt from rushed delivery
- Knowledge loss if a key engineer leaves

**Buy hidden costs:**
- Data egress/ingress fees
- Integration maintenance across vendor API changes
- Vendor lock-in (data portability, migration cost)
- Feature gaps that require workarounds
- SLA enforcement and vendor management
- Multiple vendor coordination in the same workflow

---

## Decision Matrix

After TCO analysis, score both options against weighted criteria.

### Standard Criteria

| Criterion | Typical Weight | Build Score (1-5) | Buy Score (1-5) |
|-----------|---------------|-------------------|-----------------|
| Strategic alignment | 25% | | |
| Total cost (3-year) | 20% | | |
| Time to value | 15% | | |
| Customizability | 15% | | |
| Maintenance burden | 10% | | |
| Vendor risk/lock-in | 10% | | |
| Team satisfaction | 5% | | |

### Scoring Template

```
Criterion: Strategic alignment
- 5: Directly creates competitive advantage, core to our moat
- 3: Supports the business but not differentiating
- 1: Commodity capability

Criterion: Time to value
- 5: Working in <1 month
- 3: Working in 1-3 months
- 1: Working in >6 months

Criterion: Maintenance burden
- 5: Near-zero maintenance (vendor handles everything)
- 3: Regular maintenance, dedicated team not required
- 1: Requires dedicated team for ongoing maintenance
```

---

## When Build is Right

1. **Core differentiator.** The capability is central to your competitive advantage. Owning it gives you control over your product's future.
2. **No adequate vendor.** The market doesn't offer what you need, or vendors are too immature/unstable.
3. **Existing capability.** You already built something similar. The marginal cost of extending it is lower than buying.
4. **Data advantage.** Your proprietary data makes the build significantly better than any off-the-shelf solution.
5. **Cost structure.** At scale, the build becomes dramatically cheaper than buying (common in infrastructure).

## When Buy is Right

1. **Commodity capability.** Payroll, email, analytics, maps, auth. Don't build what everyone already has.
2. **Speed to market.** The vendor can have you running in days. Building would take months.
3. **Non-core.** The capability is necessary but not differentiating. Buy preserves engineering capacity for what matters.
4. **Mature vendor market.** Multiple vendors compete on the feature you need. Price and quality are market-validated.
5. **Difficult to build well.** Encryption, compliance, payment processing, fraud detection. These domains have deep complexity and regulatory requirements.

## Build vs Buy Anti-Patterns

- **The "it's simple" fallacy.** "How hard can it be to build a chat system?" Very hard, if you need reliability, search, file sharing, compliance, and mobile sync.
- **The "we'll save money" trap.** First-year cost favors build. Three-year TCO with maintenance, support, and opportunity cost often favors buy.
- **Build because we're engineers.** Engineers want to build things. That doesn't mean they should build everything. The company's strategic priorities, not engineering preferences, should drive the decision.
- **Buy because we're in a hurry.** Urgency isn't a decision framework. A rushed buy that doesn't fit the architecture costs more than a delayed build.
- **The "not invented here" syndrome.** Organizational pride in building internally. Recognize it and evaluate honestly.
- **The "invented here" syndrome.** The opposite — assuming external vendors are always better. Apply the same scrutiny either way.

# Engineering Metrics

Frameworks for measuring engineering effectiveness, developer productivity, and delivery health. The goal is insight, not judgment — metrics should inform improvement, not evaluate individuals.

## DORA Metrics

DORA (DevOps Research and Assessment) defines four key metrics that predict organizational performance. They are the most widely adopted benchmark for software delivery capability.

### The Four Metrics

| Metric | Definition | Elite | High | Medium | Low |
|--------|-----------|-------|------|--------|-----|
| **Deployment Frequency** | How often code is deployed to production | On demand (multiple/day) | Between once/day and once/week | Between once/week and once/month | Between once/month and once/6 months |
| **Lead Time for Changes** | Time from commit to production | < 1 hour | < 1 day | < 1 week | > 6 months |
| **Mean Time to Recover (MTTR)** | Time to restore service after incident | < 1 hour | < 1 day | < 1 day | > 1 week |
| **Change Failure Rate** | % of deployments causing a failure | 0-5% | 5-10% | 10-15% | 15%+ |

### Benchmarking

Use these benchmarks to understand where your organization falls, but don't chase elite performance if your context doesn't require it.

| Industry | Typical Performance |
|----------|-------------------|
| SaaS (consumer) | High to Elite |
| SaaS (enterprise) | Medium to High |
| Fintech/Healthcare | Low to Medium (regulatory constraints) |
| Hardware/Firmware | Low to Medium |
| Internal tools | Varies widely |

### Improving DORA Metrics

| Metric | Lever | Intervention |
|--------|-------|-------------|
| Deployment frequency | Trunk-based development, CI/CD automation | Adopt feature flags, automate testing, reduce batch size |
| Lead time | Review speed, CI pipeline, deploy automation | Small PRs, auto-merge on passing CI, deploy previews |
| MTTR | Observability, incident response, rollback capability | Monitoring investment, incident playbooks, canary deployments |
| Change failure rate | Testing, code review, gradual rollout | Automated testing pyramid, load testing, feature flags |

### DORA Pitfalls

- **Measuring without context.** A low change failure rate might mean "good engineering" or "never deploying." Always interpret metrics together.
- **Comparing teams directly.** Teams doing different work will have different DORA profiles. Compare a team to its own trend, not to other teams.
- **Chasing elite on all four.** Some contexts (regulatory, safety-critical) cannot achieve elite change failure rate or lead time. Optimize for your constraints.

---

## SPACE Framework

DORA measures delivery. SPACE measures the human side of productivity — developer satisfaction and the quality of their work experience.

### The Dimensions

| Dimension | What It Measures | Sample Metrics |
|-----------|-----------------|----------------|
| **S**atisfaction & Well-being | How developers feel about their work, tools, and environment | eNPS, burnout survey, tool satisfaction score |
| **P**erformance | Outcomes and value delivered | Deploy frequency, feature adoption, MTTR |
| **A**ctivity | Quantity of output (use with caution) | PRs created, code reviews completed, commits |
| **C**ommunication & Collaboration | How effectively developers work together | Review cycle time, cross-team PRs, docs contributions |
| **E**fficiency & Flow | How easily developers can stay in flow state | Time in IDE, context switches, wait time for reviews |

### Using SPACE

- **Don't track all five equally.** Pick 2-3 dimensions that matter for your current challenges. If burnout is the issue, focus on Satisfaction. If bottlenecks are the issue, focus on Flow.
- **Pair SPACE with DORA.** DORA measures the system. SPACE measures the people. Both are needed for a complete picture.
- **Survey quarterly, not weekly.** Satisfaction and well-being don't change fast enough for frequent measurement. Quarterly surveys + monthly pulse checks.
- **Avoid activity myopia.** "PRs per developer" alone drives bad behavior (tiny PRs). Always pair activity metrics with outcome metrics.

### Common SPACE Anti-Patterns

- **Treating satisfaction as a metric.** It's a dimension. The metric within it should be specific (e.g., "I have adequate time for focused work" scored 1-5).
- **Survey fatigue.** If you survey developers about satisfaction too often, they stop giving honest answers.
- **Ignoring the results.** Asking developers about their experience and then doing nothing is worse than not asking at all. Close the feedback loop publicly.

---

## DevEx (Developer Experience)

Developer Experience focuses on the friction developers encounter in their daily work. Reducing friction is a force multiplier — minutes saved per developer translate to significant organizational throughput.

### The DevEx Framework

| Layer | What It Covers | Friction Signals |
|-------|---------------|-----------------|
| **Local Development** | IDE, dev environment, local testing | Long build times, complex setup, "it works on my machine" |
| **Inner Loop** | Code, build, test, debug cycle | Slow feedback, flaky tests, context switching |
| **Outer Loop** | CI/CD, review, deploy, monitor | Long CI, slow reviews, complex deployment |
| **Cognitive Load** | How much a developer needs to know | Complexity of architecture, number of tools, documentation quality |

### Measuring DevEx

| Method | What It Captures | Frequency |
|--------|-----------------|-----------|
| **Developer survey (Dx or SPACE)** | Subjective experience, satisfaction | Quarterly |
| **Time-to-first-commit** | Onboarding friction | Tracked per new hire |
| **IDE time in flow** | Focused work time | Weekly (via tool telemetry) |
| **Build/CI wait times** | Infrastructure bottlenecks | Weekly |
| **Context switch count** | Fragmentation of work | Monthly via calendar analysis |

### DevEx Improvement Levers

| Lever | Impact | Effort |
|-------|--------|--------|
| Standardized development environment (DevContainer, Nix) | High | Medium |
| Local development with production-like data | High | Medium-High |
| CI/CD pipeline optimization | Medium-High | Medium |
| Documentation-as-code for architecture decisions | Medium | Low |
| Automated dev environment setup (single command) | High | Medium |
| Flaky test remediation | High | Medium |

### DevEx Pitfalls

- **Building internal tools that don't solve real friction.** Survey developers about their top 3 pains before building anything.
- **Measuring the wrong thing.** Time in IDE could mean "in flow" or "stuck and trying to figure things out." Combine tool data with qualitative feedback.
- **One-size-fits-all solutions.** Different teams have different friction points. Let teams opt into platform improvements rather than mandating them.
- **Ignoring cognitive load.** The most expensive friction is mental — having to keep too many details in your head to be productive. Invest in abstractions and documentation.

# Source index

- **Source repository:** https://github.com/magnus919/hermes-profiles
- **Inspected commit:** `867a555`
- **Imported source directory:** `technology-radar`
- **Porting boundary:** Retained portable methodology, templates, scripts, and references. Removed or generalized Hermes profile, task-orchestration, memory, and rigid response-handoff assumptions.

## Issue 340 revision provenance

- **Revision basis:** Original synthesis of the repository's existing technology-radar material, issue #340 requirements, the repository's Agent Skills authoring guidance, and the safe architecture comparison supplied for this task.
- **Added emphasis:** Decision locality, reversibility, consequence-based governance selection, advice and federated processes, automated guardrails, implementation and operational feedback, exceptions, and proportional escalation.
- **Originality boundary:** No purchased ebook was read or quoted for this revision. All guidance, examples, tables, and evaluation fixtures in this directory are newly authored for this repository.
- **Scope boundary:** Enterprise capability and target-state architecture, ADR composition, implementation, security engineering, and operations remain neighboring ownership areas rather than new technology-radar responsibilities.

# Technology Radar

The technology radar is a structured approach to tracking, evaluating, and deciding on technologies. It categorizes technologies into four quadrants and two rings.

## The Radar Framework

### Quadrants (Technology Categories)

| Quadrant | What It Covers | Example |
|----------|---------------|---------|
| **Languages & Frameworks** | Programming languages, web frameworks, application frameworks | Python, React, Django, Go |
| **Platforms & Infrastructure** | Cloud providers, container orchestration, databases, message queues | Kubernetes, AWS, Postgres, Kafka |
| **Tools & Techniques** | CI/CD, monitoring, testing, security scanning, project management | GitHub Actions, Prometheus, Terraform |
| **Patterns & Practices** | Architectural patterns, development methodologies, operational practices | Microservices, event sourcing, GitOps |

### Rings (Maturity Levels)

| Ring | Meaning | Policy |
|------|---------|--------|
| **Adopt** | Proven in production, recommended for all relevant new projects | Actively promoted, documented standards exist |
| **Trial** | Worth pursuing, low-risk to experiment | Sandboxed POC allowed, must revisit decision within 6 months |
| **Assess** | Worth investigating, but not ready for commitment | Research and small experiments only, no production use |
| **Hold** | Not recommended for new projects, plan migration away | No new usage, existing usage must have migration plan |

### Transition Rules

| Transition | When | Process |
|------------|------|---------|
| Assess → Trial | Team assessed, sees potential, has a POC plan | Brief written recommendation, tech lead approval |
| Trial → Adopt | Successful in 2+ projects with documented results | Full review, standardization of patterns, documentation |
| Adopt → Hold | Newer better alternative, maintenance burden, strategic shift | Migration plan for existing systems, deprecation notice |
| Hold → (Retire) | No remaining users, migration complete | Archive docs, remove from supported list |
| Trial → Hold | Experiment failed the thesis | Document learnings, archive. Not a failure — it's data. |

### Radar Review Cadence

Set review timing according to change rate, risk, evidence quality, and the cost of stale guidance. A low-change internal tool portfolio may need less frequent review than a regulated or fast-moving platform portfolio. Significant adoption, hold, promotion, retirement, security, or strategy evidence should trigger an update outside the normal cadence. New technology intake may be continuous or batched, provided urgent risks and opportunities have an explicit path.

---

## Tool Selection Criteria

When evaluating whether to Adopt, Trial, or Hold a technology, use this criteria framework.

### Evaluation Dimensions

| Dimension | Weight | Scoring (1-5) | Notes |
|-----------|--------|---------------|-------|
| **Fit for purpose** | 30% | Does it solve the actual problem? | Beware over-engineering. "Does it work?" is the first question. |
| **Community & ecosystem** | 20% | Active development, documentation, community support | GitHub stars, contributor count, release cadence, Stack Overflow activity |
| **Operational maturity** | 20% | Production readiness, monitoring, upgrade stability | Does the community have a track record of stable releases? |
| **Talent availability** | 15% | Can we hire/develop people who know this? | Market availability, learning curve, internal expertise |
| **Integration complexity** | 15% | How hard is it to integrate with our existing stack? | Migration cost, interoperability, dependency conflicts |

### Scoring Guide

| Score | Meaning |
|-------|---------|
| 5 | Excellent — best in class for our context |
| 4 | Good — strong fit with minor concerns |
| 3 | Adequate — works but not differentiated |
| 2 | Poor — significant concerns |
| 1 | Unacceptable — does not meet requirements |

### Red Flags (Automatic Hold)

Any of these flags should move a technology to Hold regardless of other scores:

- **Single point of failure.** Core dependency managed by a single person or company without redundancy.
- **No clear governance.** Unclear licensing, governance model, or contribution process.
- **Security concerns.** Known unpatched vulnerabilities, history of supply-chain attacks.
- **EOL or deprecated.** No active development, community migration away.
- **License incompatibility.** License conflicts with company policy or distribution model.

---

## Deprecation Policy

Removing technology is harder than adding it. A clear deprecation policy prevents the accumulation of zombie technologies.

### Deprecation Process

1. **Announce intent.** "We plan to deprecate Technology X. Here's why, and here's the migration path."
2. **Freeze new usage.** No new projects may adopt the deprecated technology.
3. **Provide a migration window.** Set it from workload criticality, consumer count, migration complexity, contractual obligations, and available support; document the rationale rather than applying a universal duration.
4. **Support during migration.** Documentation, office hours, migration tools.
5. **Sunset date.** After this date, no support, no security patches, no guarantees.
6. **Archive.** Final documentation archived. Technology removed from radar.

### Deprecation by Volume

| Scenario | Migration Window | Support Level |
|----------|-----------------|---------------|
| <5 consumers | 3 months | Documentation only |
| 5-20 consumers | 6 months | Dedicated migration guide + office hours |
| 20-100 consumers | 9-12 months | Migration tools, paired support, extended support |
| 100+ consumers | 12+ months | Automated migration, phased approach, extended support |

### Pitfalls

- **Deprecation without migration path.** You cannot remove a technology without showing people what to replace it with. "Don't use X anymore" without "use Y instead" creates chaos.
- **Too many holds without removal.** If technologies sit on Hold indefinitely, the Hold ring loses meaning. Set sunset dates for every Hold decision.
- **Ignoring the migration cost.** For deeply embedded technologies (e.g., a database, a framework), the migration cost may exceed the benefit of deprecation. Be honest about the economics.