blockmine 1.21.0 → 1.22.0

package/.claude/skills/infrastructure-strategy/SKILL.md

@@ -0,0 +1,924 @@
+# Infrastructure Strategy for Engineering Leaders
+
+**For VPs, Directors, and Senior Managers setting multi-year infrastructure direction.**
+
+> Infrastructure strategy is about making big bets that enable your business for years to come - cloud platform choices, build vs buy decisions, technology investments, and multi-year roadmaps.
+
+---
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+🎯 SKILL ACTIVATED: infrastructure-strategy
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+
+## When to Use This Skill
+
+**You need help with:**
+- Cloud strategy (AWS vs Azure vs GCP, multi-cloud vs single-cloud)
+- Build vs buy decisions for infrastructure components
+- Platform investment ROI calculations
+- Multi-year infrastructure roadmapping
+- Technology evaluation and selection (technology radar)
+- Migration planning at executive level
+- Balancing innovation vs stability
+- Infrastructure budget prioritization
+
+**This skill does NOT cover:**
+- Day-to-day technical decisions (see technical-leadership)
+- Hands-on implementation (see technical skills)
+- Operational management (see engineering-operations-management)
+
+---
+
+## 1. Cloud Strategy
+
+### Single Cloud vs Multi-Cloud
+
+**Single Cloud (Recommended for most)**
+```
+Pros:
+✅ Deep integration with platform services
+✅ Team becomes expert in one platform
+✅ Simpler operations and tooling
+✅ Lower cost (volume discounts, reserved instances)
+✅ Faster development (use platform services)
+
+Cons:
+❌ Vendor lock-in risk
+❌ Less negotiating leverage
+❌ Subject to platform outages
+❌ Limited to platform capabilities
+
+Best for:
+- Startups and scale-ups
+- Teams < 100 engineers
+- Standard workloads
+- Cost-sensitive orgs
+```
+
+**Multi-Cloud (For specific use cases)**
+```
+Pros:
+✅ Avoid vendor lock-in
+✅ Negotiating leverage
+✅ Use best-of-breed services
+✅ Geographic coverage (e.g., China requires local cloud)
+
+Cons:
+❌ Operational complexity (2-3x overhead)
+❌ Team knowledge fragmentation
+❌ Higher costs (no volume discounts)
+❌ Integration challenges
+❌ Security complexity
+
+Best for:
+- Large enterprises (500+ engineers)
+- Regulatory requirements (data sovereignty)
+- M&A integration (acquired companies on different clouds)
+- Specific workload requirements
+```
+
+**Decision Framework:**
+1. **Start with single cloud** unless you have specific reason for multi-cloud
+2. **Choose cloud based on:**
+   - Existing team skills
+   - Services needed (ML, analytics, compute)
+   - Geographic presence
+   - Pricing for your workload
+3. **Design for portability** (Kubernetes, IaC) but don't pay multi-cloud tax
+
+### Which Cloud Provider?
+
+| AWS | Azure | GCP | Oracle Cloud (OCI) |
+|-----|-------|-----|-------------------|
+| **Strengths:** Largest ecosystem, most services, mature, global coverage | **Strengths:** Enterprise sales, Microsoft integration, hybrid cloud (Arc) | **Strengths:** Data/ML services, Kubernetes, developer experience, pricing | **Strengths:** Oracle DB, enterprise support, government clouds |
+| **Weaknesses:** Complexity, older UI, pricing opacity | **Weaknesses:** Service quality inconsistency, documentation gaps | **Weaknesses:** Smaller ecosystem, fewer enterprise features | **Weaknesses:** Smaller ecosystem, fewer services |
+| **Best for:** Startups, tech companies, most use cases | **Best for:** Enterprises with Microsoft stack, hybrid cloud | **Best for:** Data-heavy workloads, ML/AI, Kubernetes-first | **Best for:** Oracle workloads, government, highly regulated |
+
+**Choosing strategy:**
+- **Startup/scale-up:** AWS (ecosystem) or GCP (developer experience)
+- **Enterprise:** Azure (if Microsoft shop) or AWS (if tech-forward)
+- **Regulated/government:** AWS GovCloud, Azure Government, or OCI
+- **Oracle DB heavy:** OCI (database licensing savings)
+
+### Cloud Strategy Scenarios
+
+**Scenario: "Should we go all-in on AWS or stay flexible?"**
+- **All-in (Recommended):** Use AWS-specific services (Lambda, DynamoDB, etc.) for faster development
+- **Flexible:** Use portable tech (Kubernetes, Postgres) but sacrifice AWS integration benefits
+- **Reality:** Portability is expensive. Most companies that plan for multi-cloud never actually migrate.
+- **Decision:** Go all-in unless you have specific multi-cloud requirement
+
+**Scenario: "Is multi-cloud worth the complexity?"**
+- **Answer:** Usually NO. Multi-cloud costs 2-3x in operational overhead
+- **Only do multi-cloud if:**
+  - Large enterprise (500+ engineers) with resources
+  - Regulatory requirement (data must stay in specific regions/clouds)
+  - M&A (acquired company on different cloud, temporary state)
+- **Alternative:** Design for cloud portability (Kubernetes, Terraform) but run on single cloud
+
+**Scenario: "Do we need disaster recovery in another cloud?"**
+- **Question:** "What's the failure mode? Entire AWS region or all of AWS?"
+- **Reality:** Multi-region in same cloud is simpler and handles 99.9% of DR scenarios
+- **Multi-cloud DR:** Only for catastrophic cloud-wide failures (extremely rare)
+- **Decision:** Multi-region DR first, multi-cloud DR only if mandated by compliance
+
+**Scenario: "Serverless vs container strategy?"**
+- **Serverless (Lambda/Cloud Functions):**
+  - Best for: Event-driven, variable load, stateless functions
+  - Not for: Long-running, stateful, complex orchestration
+- **Containers (ECS/EKS/Cloud Run):**
+  - Best for: Always-on services, stateful apps, complex dependencies
+  - Not for: Simple event handlers, variable load (without autoscaling)
+- **Decision:** Use both - serverless for events, containers for services
+
+**Scenario: "Moving from on-prem to cloud?"**
+- **Timeline:** 12-36 months depending on complexity
+- **Strategy:**
+  - Phase 1: Lift-and-shift (VMs) to derisk
+  - Phase 2: Re-platform (containerize, use managed services)
+  - Phase 3: Re-architect (cloud-native, serverless)
+- **Don't:** Big-bang migration. Do: Incremental, service by service
+
+**Scenario: "Cost difference between clouds?"**
+- **Reality:** Pricing is similar for compute/storage (within 10-20%)
+- **True cost differences:**
+  - Data egress (can be 3-5x different)
+  - Managed services (varies widely)
+  - Enterprise support (20% of spend)
+  - Reserved instance discounts (negotiate these!)
+- **Decision:** Choose based on services/expertise, not just pricing
+
+**Scenario: "Should we use GCP for ML workloads and AWS for everything else?"**
+- **Sounds smart, but:** Operational complexity of managing two clouds
+- **Better:** Use AWS SageMaker or GCP Vertex AI - both are excellent
+- **Only split if:** ML team is separate and has strong GCP preference
+- **Reality:** Integration complexity usually outweighs best-of-breed benefits
+
+**Scenario: "GovCloud requirement - what changes?"**
+- **Limited services:** Not all AWS services available in GovCloud
+- **Higher cost:** Separate infrastructure, lower economies of scale
+- **Compliance burden:** STIG hardening, continuous monitoring, audit paperwork
+- **Staffing:** Need cleared personnel for some operations
+- **Timeline:** Add 3-6 months to normal cloud migration
+
+**Scenario: "Cloud-native vs cloud-agnostic?"**
+- **Cloud-native:** Use cloud-specific services (managed databases, serverless)
+  - Faster development, lower operational burden
+  - Trade-off: Harder to migrate clouds
+- **Cloud-agnostic:** Use portable tech (Kubernetes, open source)
+  - Flexibility to move clouds
+  - Trade-off: More operational burden, slower development
+- **Recommendation:** Be pragmatic - use cloud services but document dependencies
+
+### Government and Cleared Clouds
+
+**For regulated industries:**
+- **FedRAMP:** AWS GovCloud, Azure Government, GCP for Government, OCI Government
+- **IL4/IL5:** AWS Secret Region, Azure Government Secret, GCP Assured Workloads
+- **IL6 (Top Secret):** AWS Top Secret Region, Azure Government Top Secret
+
+**Considerations:**
+- Limited service availability in government clouds
+- Higher costs (separate infrastructure)
+- Longer procurement cycles
+- Compliance overhead (STIG, NIST 800-53)
+
+---
+
+## 2. Build vs Buy Decisions
+
+### Framework for Deciding
+
+```
+BUILD when:
+✅ Core differentiator for your business
+✅ Existing solutions don't meet needs
+✅ You have unique requirements
+✅ Team has expertise and capacity
+✅ Long-term cost justifies initial investment
+
+BUY when:
+✅ Not a differentiator (infrastructure, auth, payments)
+✅ Commodity problem with good solutions
+✅ Time to market is critical
+✅ Team lacks expertise
+✅ Ongoing maintenance would be burden
+```
+
+### Decision Matrix
+
+| Component | Build | Buy | Rationale |
+|-----------|-------|-----|-----------|
+| **Authentication** | ❌ | ✅ Buy (Auth0, Okta) | Commodity, security-critical, complex |
+| **CI/CD** | ❌ | ✅ Buy (GitHub Actions, CircleCI) | Mature market, not differentiator |
+| **Observability** | ❌ | ✅ Buy (Datadog, New Relic) | Complex to build, mature vendors |
+| **Internal Developer Platform** | ✅ | ❌ | Core to productivity, unique needs |
+| **ML Platform** | ✅ | ❌ If ML is core business | Differentiator, specific workflows |
+| **API Gateway** | Maybe | Maybe | Depends on customization needs |
+
+### Total Cost of Ownership (TCO)
+
+**Build TCO:**
+```
+Initial Development:
+├── Engineering time (months × $150K/year avg)
+├── Opportunity cost (what else could they build?)
+└── Infrastructure costs
+
+Ongoing:
+├── Maintenance (20-30% of dev cost annually)
+├── Operations (monitoring, on-call)
+├── Updates and security patches
+├── Documentation and training
+└── Infrastructure costs
+
+3-Year TCO = Initial + (3 × Annual Ongoing)
+```
+
+**Buy TCO:**
+```
+Year 1:
+├── Vendor cost (licenses/seats)
+├── Implementation/integration (1-3 months engineer time)
+├── Training
+└── Infrastructure (if self-hosted)
+
+Years 2-3:
+├── Annual license growth (plan for 20-30% growth)
+├── Support/premium features
+├── Minimal maintenance
+└── Infrastructure
+
+3-Year TCO = Y1 + Y2 + Y3
+```
+
+**Example: Auth System**
+```
+BUILD:
+├── 6 months × 2 engineers = $150K initial
+├── Ongoing: $60K/year maintenance
+└── 3-year TCO: $150K + $180K = $330K
+
+BUY (Auth0):
+├── $2/MAU × 100K users = $200K/year
+├── Integration: $30K one-time
+└── 3-year TCO: $30K + $600K = $630K
+
+Conclusion: Build seems cheaper BUT:
+- Auth0 includes: MFA, SSO, compliance, security updates
+- Building all that: 12+ months, $300K+
+- Hidden costs: security incidents, compliance audits
+- Decision: BUY unless auth is your core business
+```
+
+### Build vs Buy Checklist
+
+```
+□ Is this a core differentiator for our business?
+□ Do existing solutions meet 80%+ of our needs?
+□ Do we have team expertise to build and maintain?
+□ Have we calculated full 3-year TCO for both options?
+□ Can we afford the opportunity cost of building?
+□ Is vendor lock-in acceptable? (most cases: yes)
+□ What's the risk if we choose wrong? Can we switch later?
+□ Does "buy" option have enterprise SLA and support?
+```
+
+### Build vs Buy Scenarios
+
+**Scenario: "Should we build an internal platform like Heroku?"**
+- **Build cost:** 8-12 engineers × 12 months = $2M+ initial, $1.5M/year ongoing
+- **Buy alternative:** Heroku, Cloud Run, App Runner - $50-200K/year
+- **Build if:** 150+ engineers, unique workflows, platform is differentiator
+- **Buy if:** < 100 engineers, standard app deployment, want speed
+- **Hidden costs of building:** In-house support, documentation, feature requests, security updates
+
+**Scenario: "Payment processing - build or use Stripe?"**
+- **Build:** PCI compliance alone costs $500K+/year
+- **Stripe:** 2.9% + $0.30 per transaction
+- **Break-even:** Only makes sense at $100M+ annual GMV with specialized needs
+- **Decision:** Almost always buy. Payments are not your core business.
+
+**Scenario: "APM - commercial (DataDog/New Relic) vs open source (Prometheus/Grafana)?"**
+- **Commercial ($200-500K/year):**
+  - Full-featured, hosted, 24/7 support
+  - Fast time to value (days)
+  - Best for teams < 50 engineers
+- **Open Source ($100-200K/year in engineering time):**
+  - Self-hosted, requires dedicated team
+  - Slower time to value (months)
+  - Best for teams > 100 engineers with SRE expertise
+- **Decision:** Buy commercial until you have SRE team to run OSS
+
+**Scenario: "Service mesh - build custom vs buy Istio/Linkerd vs buy Consul?"**
+- **Build custom:** 6-12 months, ongoing maintenance nightmare
+- **Open source (Istio/Linkerd):** Complex to operate, requires expertise
+- **Commercial (Consul Enterprise, Gloo):** Easier, supported, expensive
+- **Reality:** Most companies don't need service mesh. Use it if:
+  - 50+ microservices
+  - Need mTLS everywhere
+  - Complex traffic routing requirements
+- **Decision:** Buy managed service mesh or don't use one
+
+**Scenario: "Managed Kubernetes (EKS/GKE) vs self-hosted?"**
+- **Managed ($150/cluster/month):**
+  - Control plane managed, auto-updates, integrated
+  - Still need to manage worker nodes
+- **Self-hosted (save $150/month, cost $10K/month in engineering time):**
+  - Full control, complex setup, manual updates
+- **Decision:** Always use managed unless you have 10+ dedicated Kubernetes experts
+
+**Scenario: "Observability - should we buy DataDog or build our own?"**
+- **Build cost:** $500K-1M first year, $300K/year ongoing
+- **DataDog:** $100-300K/year depending on scale
+- **Build if:** > 500 engineers, unique observability needs, cost > $1M/year
+- **Buy if:** < 500 engineers, standard needs, want to focus on product
+- **Hidden build costs:** Integration with all services, alerting, dashboards, on-call for observability platform
+
+**Scenario: "Should finance approve this observability tooling?"**
+- **Cost:** $200K/year for observability seems expensive
+- **Value:** Reduce MTTR from 2 hours to 15 minutes
+  - 100 incidents/year × 1.75 hours saved × 3 engineers × $100/hour = $52.5K/year
+  - Prevented outages: 10/year × $50K revenue impact = $500K/year saved
+- **ROI:** $752K value for $200K cost = 276% ROI
+- **Decision:** Approve - observability prevents costly outages
+
+**Scenario: "Terraform Cloud vs self-hosted Terraform?"**
+- **Terraform Cloud:** $20/user/month = $24K/year for 100 engineers
+- **Self-hosted:** Free but requires CI/CD integration, state management, RBAC
+  - Engineering cost: $50K/year
+- **Decision:** Use Terraform Cloud unless you already have robust CI/CD for state management
+
+---
+
+## 3. Platform Investment ROI
+
+### Calculating Platform ROI
+
+**Formula:**
+```
+ROI = (Productivity Gains - Platform Cost) / Platform Cost × 100%
+
+Productivity Gains = (Time Saved × Engineer Count × Avg Salary)
+Platform Cost = (Team Cost + Infrastructure Cost)
+```
+
+**Example: Internal Developer Platform**
+```
+Investment:
+├── Platform team: 8 engineers × $200K = $1.6M/year
+├── Infrastructure: $400K/year
+└── Total Cost: $2M/year
+
+Productivity Gains:
+├── Faster deployments: 2 hours/week saved × 50 engineers
+├── Reduced incidents: 50% reduction = 10 hours/week saved
+├── Faster onboarding: 2 weeks → 1 week for 20 new hires/year
+├──Total time saved: ~5,000 hours/year
+├── Value: 5,000 hours × $100/hour = $500K/year
+
+Wait, that's negative ROI!
+
+But indirect benefits:
+├── Faster time to market: 2 week reduction × 12 features = 24 weeks
+├── Value of shipping faster: $5M revenue brought forward
+├── Reduced risk: Fewer outages = better customer retention
+├── Improved hiring: Better developer experience attracts talent
+
+True ROI: Hard to quantify, but likely 3-5x over 3 years
+```
+
+### When to Invest in Platform
+
+**Invest when:**
+- Team size > 30-50 engineers
+- Development velocity slowing down
+- High cognitive load on engineers
+- Inconsistent practices across teams
+- Frequent production incidents
+- Hard to hire/onboard engineers
+
+**Don't invest when:**
+- Team < 30 engineers (not enough leverage)
+- Business model unproven (premature scaling)
+- Existential priorities (fundraising, shipping core product)
+
+### ROI Calculation Scenarios
+
+**Scenario: "How do we calculate platform team ROI?"**
+- **Direct metrics:**
+  - Deployment frequency: 1/week → 10/day
+  - Lead time: 2 weeks → 2 days
+  - MTTR: 4 hours → 30 minutes
+  - Onboarding time: 4 weeks → 1 week
+- **Value calculation:**
+  - 50 engineers × 5 hours/week saved = 250 hours/week
+  - 250 hours × 50 weeks × $100/hour = $1.25M/year
+- **Platform cost:** 8 engineers × $200K = $1.6M
+- **ROI:** Breakeven year 1, positive thereafter
+- **Intangibles:** Better hiring, less burnout, faster innovation
+
+**Scenario: "Justifying Kubernetes migration"**
+- **Cost of migration:** 6 months × 4 engineers = $400K
+- **Benefits:**
+  - Better resource utilization: Save 30% on infrastructure = $150K/year
+  - Faster deployments: 2 hours → 10 minutes = 100 hours/week saved = $250K/year
+  - Multi-cloud optionality (intangible)
+- **Payback period:** 12-18 months
+- **Decision:** Worth it if infrastructure cost > $500K/year or scaling quickly
+
+**Scenario: "Platform team value - what should we measure?"**
+- **Avoid vanity metrics:**
+  - ❌ Number of deployments (more isn't always better)
+  - ❌ Lines of code (meaningless)
+  - ❌ Tickets closed (focuses on wrong thing)
+- **Focus on impact metrics:**
+  - ✅ Developer survey scores (NPS for platform)
+  - ✅ Time to first deployment (new engineer)
+  - ✅ DORA metrics (deployment frequency, lead time, MTTR, change failure rate)
+  - ✅ Time saved per engineer per week
+  - ✅ Incident reduction (fewer production issues)
+
+**Scenario: "Infrastructure cost per developer?"**
+- **Calculate:** Total infrastructure cost / number of engineers
+- **Benchmarks:**
+  - Early stage: $2-5K per engineer/month
+  - Scale-up: $5-10K per engineer/month
+  - Enterprise: $10-20K per engineer/month
+- **High cost reasons:** Data-intensive, ML workloads, inefficient usage, overprovisioning
+- **Optimization:** Right-size instances, use spot/reserved, implement autoscaling
+
+**Scenario: "How do we measure developer velocity improvement?"**
+- **Lead Time for Changes:**
+  - Before: 2 weeks from commit to production
+  - After platform investment: 2 days
+  - Improvement: 10x faster
+- **Developer satisfaction:**
+  - Survey: "How easy is it to deploy a new service?" 1-10
+  - Target: Improve from 4 → 8
+- **Time to productivity:**
+  - New engineer: Productive in 1 week vs 4 weeks
+  - Value: 3 weeks × 20 new hires/year = 60 weeks saved
+
+**Scenario: "Service mesh cost-benefit analysis"**
+- **Cost:**
+  - 2 engineers × 6 months setup = $200K
+  - Ongoing: 1 engineer × $200K/year
+  - Overhead: 10% latency increase, 20% infrastructure increase = $100K/year
+  - **Total:** $200K + $300K/year
+- **Benefit:**
+  - mTLS everywhere (security win)
+  - Traffic management (canary deploys)
+  - Observability (better debugging)
+  - **Value:** Hard to quantify - mainly security/compliance
+- **Decision:** Only do it if:
+  - Security/compliance requirement
+  - 50+ microservices
+  - Sophisticated traffic management needs
+
+**Scenario: "Platform break-even point"**
+- **Question:** "When does investing in platform pay off?"
+- **Formula:** Break-even when (Time Saved Value) > (Platform Cost)
+- **Example:**
+  - Platform team cost: $2M/year (10 engineers)
+  - Time saved: 100 engineers × 10 hours/week × $100/hour = $5M/year
+  - **Break-even:** Immediate (2.5x return)
+- **Reality:** Benefits compound - velocity improvements enable more velocity
+
+**Scenario: "Opportunity cost of platform investment"**
+- **Question:** "What else could these 8 engineers build instead of platform?"
+- **Option A:** Platform team → enables 100 engineers to be 20% more productive = 20 FTE equivalent
+- **Option B:** Product team → ship 2-3 more features/year
+- **Trade-off:** Short-term features vs long-term productivity
+- **Decision:** At 50+ engineers, platform investment usually wins
+
+### Investment Priorities by Stage
+
+**Startup (0-30 engineers):**
+```
+Priority 1: Ship product, find product-market fit
+Infrastructure: Use managed services, don't build platform
+Investment: Observability, CI/CD (buy, don't build)
+```
+
+**Scale-up (30-150 engineers):**
+```
+Priority: Scale engineering productivity
+Infrastructure: Start investing in platform
+Investment:
+├── Developer experience (CI/CD optimization, faster builds)
+├── Observability (centralized logs, metrics, traces)
+├── Self-service infrastructure (IaC templates, K8s)
+└── SRE function (reliability, on-call)
+```
+
+**Enterprise (150+ engineers):**
+```
+Priority: Maintain velocity as org scales
+Infrastructure: Platform as product
+Investment:
+├── Internal developer platform (self-service everything)
+├── Platform teams (dedicated orgs)
+├── SRE org (production excellence)
+├── Security org (AppSec, compliance)
+└── Data platform (analytics, ML)
+```
+
+---
+
+## 4. Multi-Year Roadmapping
+
+### Infrastructure Roadmap Framework
+
+**Year 1: Foundation**
+```
+Q1-Q2: Stabilize
+├── Production reliability (reduce incidents)
+├── Observability (visibility into systems)
+├── CI/CD basics (automated deployments)
+└── Security fundamentals (secrets management, scanning)
+
+Q3-Q4: Optimize
+├── Developer experience improvements
+├── Performance optimization
+├── Cost optimization
+└── Team hiring and growth
+```
+
+**Year 2: Scale**
+```
+Q1-Q2: Platform Investment
+├── Internal developer platform (IDP) foundation
+├── Self-service infrastructure
+├── Advanced observability (tracing, SLOs)
+└── Expand platform team
+
+Q3-Q4: Productivity
+├── Faster deployments (reduce cycle time)
+├── Better testing (reduce bugs)
+├── Documentation and enablement
+└── Platform adoption
+```
+
+**Year 3: Excellence**
+```
+Q1-Q2: Maturity
+├── Platform as product mindset
+├── Multi-region/global infrastructure
+├── Advanced security and compliance
+└── Disaster recovery and business continuity
+
+Q3-Q4: Innovation
+├── Emerging technologies (ML, edge computing)
+├── Next-generation architecture
+├── Strategic bets
+└── Continuous improvement
+```
+
+### Balancing Roadmap
+
+**The 70-20-10 Rule:**
+- **70% Core Business:** Keep the lights on, support product roadmap
+- **20% Platform Investment:** Developer experience, reliability, security
+- **10% Innovation:** Experiments, R&D, emerging tech
+
+**Adjust by maturity:**
+- Early stage: 85% core, 10% platform, 5% innovation
+- Growth stage: 70% core, 20% platform, 10% innovation
+- Mature: 60% core, 25% platform, 15% innovation
+
+### Roadmap Communication
+
+**Quarterly Infrastructure Review (with leadership):**
+```
+1. Last Quarter Recap (15 min)
+   ├── What we shipped
+   ├── Impact and metrics
+   └── What we learned
+
+2. This Quarter Plan (20 min)
+   ├── Top 3-5 priorities
+   ├── Resource allocation
+   ├── Dependencies and risks
+   └── Success criteria
+
+3. Long-term Strategy (15 min)
+   ├── Year-ahead preview
+   ├── Strategic bets
+   └── Investment needs
+
+4. Q&A (10 min)
+```
+
+---
+
+## 5. Technology Radar
+
+### What is a Technology Radar?
+
+**A framework for tracking and evaluating technologies.**
+
+**Four Rings:**
+1. **Adopt:** Proven, ready for production, recommended
+2. **Trial:** Worth exploring, pilot projects
+3. **Assess:** Interesting, but not ready yet
+4. **Hold:** Avoid for now, or phase out
+
+**Four Quadrants:**
+1. **Techniques:** Development practices, architectures
+2. **Tools:** Software, frameworks, products
+3. **Platforms:** Infrastructure, cloud services
+4. **Languages & Frameworks:** Programming languages, libraries
+
+### Example Technology Radar (Infrastructure)
+
+**ADOPT (Use in production):**
+```
+├── Kubernetes (Container orchestration)
+├── Terraform (Infrastructure as Code)
+├── GitHub Actions (CI/CD)
+├── Datadog (Observability)
+├── PostgreSQL (Relational database)
+└── AWS (Cloud platform)
+```
+
+**TRIAL (Pilot projects):**
+```
+├── ArgoCD (GitOps)
+├── Pulumi (IaC alternative to Terraform)
+├── Temporal (Workflow orchestration)
+├── ClickHouse (Analytics database)
+└── OpenTelemetry (Observability standard)
+```
+
+**ASSESS (Evaluate):**
+```
+├── WebAssembly (Edge computing)
+├── Serverless containers (AWS Fargate, Cloud Run)
+├── Service mesh (Istio, Linkerd)
+└── eBPF (Observability and security)
+```
+
+**HOLD (Avoid or deprecate):**
+```
+├── Monolithic architectures (favor microservices)
+├── Manual deployments (automate everything)
+├── Homegrown auth (use Auth0/Okta)
+└── [Legacy tool you're migrating from]
+```
+
+### Technology Evaluation Process
+
+**Before adopting new technology:**
+```
+1. Problem Validation
+   └── What problem does this solve?
+   └── Do we actually have this problem?
+   └── How are we solving it today?
+
+2. Technology Research
+   └── Maturity: Production-ready? Stable?
+   └── Community: Active? Well-supported?
+   └── Ecosystem: Good documentation? Libraries? Integrations?
+
+3. Proof of Concept
+   └── Build small prototype (2-4 weeks max)
+   └── Test with real use case
+   └── Assess developer experience
+
+4. Team Assessment
+   └── Do we have skills? Can we learn?
+   └── Can we operate and maintain this?
+   └── What's the training investment?
+
+5. Decision
+   └── Adopt: Roll out to production
+   └── Trial: More POCs, pilot projects
+   └── Assess: Keep watching, not ready
+   └── Hold: Not right for us, pass
+
+6. Review Annually
+   └── Revisit decisions yearly
+   └── Move technologies between rings
+   └── Deprecate old choices
+```
+
+---
+
+## 6. Migration Planning (Executive Level)
+
+### Types of Migrations
+
+**1. Cloud Migration (On-prem → Cloud)**
+```
+Approaches:
+├── Lift-and-shift (Rehost): Fast, minimal changes, technical debt
+├── Replatform: Optimize for cloud (managed services, containers)
+├── Refactor: Rewrite for cloud-native (microservices, serverless)
+└── Recommended: Hybrid (replatform most, refactor critical)
+
+Timeline: 12-36 months depending on scope
+Investment: 20-40% of engineering capacity
+Risk: Medium-High
+```
+
+**2. Multi-Cloud (Single cloud → Multi-cloud)**
+```
+Why:
+├── Vendor negotiation leverage
+├── Regulatory requirements (data sovereignty)
+├── M&A integration
+└── Avoid vendor lock-in
+
+Cost: 2-3x operational overhead
+Timeline: 18-36 months
+Recommendation: Only if compelling business reason
+```
+
+**3. Modernization (Monolith → Microservices)**
+```
+Approach:
+├── Strangler fig pattern (gradually extract services)
+├── Don't rewrite everything at once
+└── Extract highest-value services first
+
+Timeline: 24-48 months
+Investment: 30-50% of engineering capacity
+Risk: High (many fail, scope creep)
+```
+
+### Migration Planning Framework
+
+**Phase 1: Assessment (2-3 months)**
+```
+├── Current state analysis
+│   ├── Inventory of systems
+│   ├── Dependencies mapped
+│   └── Technical debt identified
+├── Target state definition
+│   ├── Architecture vision
+│   ├── Technology choices
+│   └── Success criteria
+└── Migration strategy
+    ├── Wave planning (which systems, what order)
+    ├── Risk assessment
+    └── Resource planning
+```
+
+**Phase 2: Pilot (3-6 months)**
+```
+├── Choose 1-2 non-critical systems
+├── Migrate end-to-end
+├── Learn and refine process
+├── Build runbooks and automation
+└── Validate costs and effort estimates
+```
+
+**Phase 3: Execution (12-24 months)**
+```
+├── Migrate in waves (monthly or quarterly)
+│   ├── Wave 1: Easy wins (stateless apps)
+│   ├── Wave 2: Medium complexity
+│   └── Wave 3: Complex/critical systems
+├── Decommission old systems
+└── Continuous optimization
+```
+
+**Phase 4: Optimization (Ongoing)**
+```
+├── Cost optimization
+├── Performance tuning
+├── Security hardening
+└── Team training
+```
+
+### Migration Risks and Mitigations
+
+| Risk | Impact | Mitigation |
+|------|--------|------------|
+| **Cost overruns** | Budget exceeded 2-3x | Detailed estimation, quarterly reviews, kill switch |
+| **Timeline delays** | Migration takes 2x longer | Conservative estimates, buffer time, phased approach |
+| **Data loss** | Critical data corrupted/lost | Backups, dual-write, rollback plan |
+| **Performance issues** | System slower after migration | Load testing, gradual rollout, performance baseline |
+| **Team burnout** | Engineers exhausted | Limit migration to 30-40% capacity, rotations |
+| **Vendor lock-in** | Stuck with new vendor | Design for portability (Kubernetes, IaC) |
+
+---
+
+## 7. Balancing Innovation vs Stability
+
+### The Innovation Spectrum
+
+```
+Bleeding Edge → Leading Edge → Mainstream → Legacy
+     ↑              ↑              ↑            ↑
+  High Risk    Medium Risk    Low Risk     High Risk
+  High Reward  Medium Reward  Low Reward   Technical Debt
+```
+
+**Where to be:**
+- **Core infrastructure:** Mainstream (proven, stable)
+- **Product features:** Leading edge (competitive advantage)
+- **Experiments:** Bleeding edge (limited blast radius)
+- **Legacy:** Migrate to mainstream
+
+### Innovation Budget
+
+**Allocate engineering time:**
+```
+├── 70% Mainstream: Proven technologies, low risk
+├── 20% Leading Edge: 1-2 year old, early adopters
+└── 10% Bleeding Edge: New, experimental, R&D
+```
+
+**Example:**
+- Mainstream: Kubernetes, Postgres, AWS
+- Leading Edge: ArgoCD (GitOps), OpenTelemetry
+- Bleeding Edge: WebAssembly at edge, new ML frameworks
+
+### Decision Framework: When to Adopt New Technology?
+
+**Adopt if:**
+- ✅ Solves real problem we have today
+- ✅ Mature enough (1-2 years in production elsewhere)
+- ✅ Active community and support
+- ✅ Team excited and willing to learn
+- ✅ Can pilot with low risk
+
+**Wait if:**
+- ❌ No clear problem it solves
+- ❌ Too new (< 1 year, frequent breaking changes)
+- ❌ Small community, unclear future
+- ❌ Team lacks bandwidth to learn
+- ❌ Can't fail safely
+
+---
+
+## Key Takeaways for Leaders
+
+1. **Cloud strategy:** Single cloud for most, multi-cloud only if required
+2. **Build vs buy:** Buy unless it's your core differentiator
+3. **Platform ROI:** Invest when team > 30-50 engineers
+4. **Roadmap balance:** 70% core, 20% platform, 10% innovation
+5. **Technology radar:** Be deliberate about tech adoption
+6. **Migration planning:** 12-36 months, 20-40% capacity
+7. **Innovation budget:** 70% mainstream, 20% leading edge, 10% experimental
+8. **Make reversible decisions:** Avoid vendor lock-in where possible
+9. **Measure everything:** Track productivity, costs, reliability
+10. **Think in years:** Infrastructure strategy is long-term game
+
+**Remember:** Infrastructure strategy is about enabling your business to move faster, scale efficiently, and compete effectively - not about using the coolest technology.
+
+---
+
+## Templates
+
+### Technology Decision Template
+
+```markdown
+# Technology Decision: [Technology Name]
+
+## Problem
+[What problem are we solving?]
+
+## Proposed Solution
+[Technology/approach we're evaluating]
+
+## Alternatives Considered
+1. [Alternative 1]
+2. [Alternative 2]
+3. Status quo
+
+## Evaluation
+| Criteria | Weight | Score (1-5) | Notes |
+|----------|--------|-------------|-------|
+| Solves problem | High | | |
+| Maturity | High | | |
+| Team skills | Medium | | |
+| Cost | Medium | | |
+| Vendor support | Low | | |
+
+## Decision
+[Adopt | Trial | Assess | Hold]
+
+## Next Steps
+- [ ] Prototype (if Trial)
+- [ ] Training plan
+- [ ] Migration plan
+- [ ] Success metrics
+
+## Review Date
+[When we'll revisit this decision]
+```
+
+---
+
+## Integration with Other Skills
+
+**This skill works with:**
+- **technical-leadership** - Evaluating technical proposals, architecture reviews
+- **engineering-management** - Resource planning, team organization
+- **budget-and-cost-management** - Infrastructure budgets, cost optimization
+- **engineering-operations-management** - SRE strategy, reliability
+
+Your infrastructure strategy should enable your business strategy, not constrain it.