CTO Advisor
Key Workflows
Workflow 1: Comprehensive Technical Debt Assessment
Time: 3-4 hours (data gathering and analysis)
Steps:
- Gather system data across 5 categories - Collect metrics from engineering systems
- Code metrics: Test coverage, cyclomatic complexity, code duplication percentage
- Infrastructure: Deployment frequency, change lead time, incident rate, uptime
- Architecture: Service coupling, deprecated patterns, monolith vs microservices assessment
- Team velocity: 5-sprint trend, bug rate trend, refactoring time allocation
- Technical: Outdated dependencies, security vulnerabilities, scalability assessment
- Source data from: CI/CD dashboards, incident management systems, code analysis tools, sprint metrics
- Run tech debt analyzer Python tool - Execute comprehensive analysis
python scripts/tech_debt_analyzer.py system_data.json
- Scores each category 0-100 (100=excellent, 0=critical)
- Produces prioritized reduction plan with estimated effort
- Identifies which debt is blocking velocity, reliability, or hiring
- Interpret results and identify root causes - Understand debt landscape
- Critical debt (score <40): Must address immediately (blocking scaling/reliability)
- High debt (40-60): Needs attention next quarter (affecting efficiency)
- Medium debt (60-80): Tactical improvements (quality enhancements)
- Emerging debt (80+): Well-managed, preventive focus
- Root cause analysis: Why did debt accumulate? Speed over quality, architectural limitation, team growth?
- Develop quarterly reduction strategy - Create actionable paydown plan
- Tier 1 (Critical): Allocate 10-15% engineering capacity, target 2-sprint completion
- Tier 2 (High): Allocate 5-10% engineering capacity, target next quarter
- Tier 3 (Medium): Allocate 2-5% engineering capacity, target next half year
- Balance: Don't allocate >20% to debt without impacting feature delivery
- Create executive business case - Present with impact analysis
- Current impact: How is debt affecting velocity, reliability, hiring, or product?
- Financial impact: Cost of incidents, developer productivity loss, hiring difficulty?
- Paydown investment: How many engineer-months and cost?
- Expected benefits: Faster deployments, fewer bugs, easier hiring, better retention?
- Timeline: How many quarters to address critical debt?
- See references/templates.md for executive presentation template
- Get leadership approval and allocation - Secure commitment to plan
- Present to CTO, VP Engineering, and CFO
- Get committed budget and engineer allocation
- Set quarterly targets and review cadence
Expected Output: Quantified technical debt landscape with severity scores, prioritized reduction roadmap, business case for investment, and leadership-approved engineering allocation for debt paydown. Engineering team has clear guidance on what to fix first.
See references/tools.md for detailed tech debt analyzer documentation, scoring methodology, and reduction planning.
Workflow 2: Plan Engineering Team Scaling
Time: 3-4 hours (analysis and planning)
Steps:
- Assess current team state - Establish baseline for scaling decisions
- Headcount by discipline: Frontend, backend, QA, DevOps, data engineers, etc.
- Seniority distribution: % junior, mid, senior, staff engineers
- Current velocity and throughput (story points/sprint)
- Attrition rate and retention trends (% turnover annually)
- Skill gaps: Missing expertise, bottleneck persons, weak areas
- Geographic distribution and time zone coverage
- Current hiring velocity (people hired per month)
- Define business-driven scaling needs - Understand what growth requires
- Revenue growth targets: How much larger is business in 12-24 months?
- Feature roadmap: How many new products, features, or services?
- Platform initiatives: Architecture changes, tech debt paydown, infrastructure modernization?
- Capability expansion: New skills needed (AI/ML, security, data, mobile)?
- Quality improvements: Need for QA, DevOps, site reliability engineers?
- Run team scaling calculator - Calculate optimal hiring plan
python scripts/team_scaling_calculator.py team_data.json
- Outputs: Recommended team size, hiring plan by quarter, budget projections
- Models: Conservative (10% growth/quarter), Steady (20% growth/quarter), Aggressive (40% growth/quarter)
- Factors: Historical hiring velocity, onboarding ramp time, market competition, budget constraints
- Evaluate scenarios and pick growth strategy - Make informed choice
- Conservative (slow scale): Low hiring risk, easier onboarding, may constrain growth
- Steady (moderate scale): Balanced growth and risk, sustainable long-term
- Aggressive (fast scale): Enables rapid growth but high coordination/onboarding overhead
- Trade-offs: Speed to market vs quality vs team stability
- Review budget impact, cash runway, and hiring market feasibility
- Design team organization structure - Plan the team for growth
- Squad/team count: 1 squad (10 people), 2 squads (20 people), etc.
- Leadership model: Engineering manager per squad, tech lead structure
- Team missions: Backend squad, frontend squad, infrastructure squad, etc.
- Cross-functional dependencies: Shared platforms, data, or services?
- Onboarding infrastructure: Mentoring, bootcamps, documentation needed?
- Create hiring and budget plan - Execute scaled growth
- Quarterly hiring targets (Q1: 2 engineers, Q2: 3 engineers, Q3: 4 engineers)
- Roles to recruit: Mix of junior, mid, senior by team need
- Compensation bands and budget total
- Sourcing strategy: Referrals, agencies, direct recruitment, universities?
- Onboarding plan: Bootcamp, buddy system, ramp-up timeline
- Retention strategy: Career development, promotion paths, compensation reviews
- Present to board and secure approval - Get executive buy-in
- Show connection between team growth and business impact
- Budget approved: Total cost of planned hiring
- Hiring authority: Authority to approve hires per role/quarter
- Runway impact: Does hiring fit with cash constraints?
Expected Output: Detailed engineering hiring plan with quarterly targets by role, team organization design, budget projections, and board-approved hiring authority. Organization can execute growth strategy with clear goals and constraints.
See references/tools.md for team scaling calculator documentation, scenario analysis examples, budget modeling, and risk assessment.
Workflow 3: Make Architecture Decisions Using ADR Process
Time: 1-2 weeks from proposal to decision
Steps:
- Identify architecture decision point - When to formally decide
- New system/service design: Microservice vs monolith vs serverless?
- Technology selection: Database (PostgreSQL vs MongoDB), language, framework
- Integration approach: API-first, event-driven, batch processing, real-time streaming?
- Data strategy: Schema design, replication, backup, disaster recovery?
- Migration initiative: Cloud migration, platform changes, major refactoring?
- Research and evaluate options - Systematic evaluation of alternatives
- List 2-3 viable options (always include status quo)
- For each option: Pros/cons, effort to implement, long-term maintenance, cost, risk
- Prototype or spike if decision is critical and uncertain
- Gather input: Team technical discussion, stakeholder concerns, security/compliance review
- Create Architecture Decision Record (ADR) - Document using template
- Status: Proposed (being evaluated), Accepted (decided), Deprecated (no longer used), Superseded (replaced)
- Context: What problem are we solving? Business drivers? Technical constraints?
- Decision: Which option did we choose and why?
- Consequences: Positive and negative trade-offs of chosen approach
- Alternatives considered: Why we didn't choose other options
- See references/templates.md for ADR template
- Get stakeholder buy-in - Review and approval process
- Architecture review board: Senior engineers discuss, challenge assumptions, approve
- Engineering team: Broader discussion, concerns, implementation questions
- Security/compliance: Ensure meets standards, no vulnerabilities introduced
- Executive review: If impacts budget, timeline, or strategy
- Document approvals and who signed off
- Communicate decision widely - Announce and build shared understanding
- Share ADR with full engineering organization
- Update architecture documentation (diagrams, decision log, runbooks)
- Conduct tech talk or workshop explaining decision
- Q&A session for concerns or questions
- Execute and monitor implementation - Track decision outcome
- Project team implements architecture per ADR
- Validate: Is the system performing as expected? Trade-offs real?
- Adjust: If assumptions were wrong, document lessons and potential revisions
- Review periodically (quarterly or at 6 month mark)
- Maintain ADR as living document
Expected Output: Formalized architecture decision with clear rationale, stakeholder consensus, and implementation plan. Organization learns from decisions, documentation becomes reference for future similar decisions.
See references/frameworks.md for architecture governance patterns, design review checklists, and technology evaluation frameworks.
Workflow 4: Establish DORA Metrics and Engineering Excellence
Time: 4-6 weeks for implementation, ongoing monitoring
Steps:
- Understand DORA metrics framework - The 4 key engineering performance indicators
- Deployment Frequency: How often do we deploy to production? (Target: Daily or on-demand, Elite: >1/day, High: 1/week, Medium: 1/month)
- Lead Time for Changes: From code commit to production deploy? (Target: <1 day, Elite: <1 day, High: <1 week, Medium: <1 month)
- Mean Time to Recovery (MTTR): How fast do we recover from production incidents? (Target: <1 hour, Elite: <1 hour, High: <4 hours, Medium: <1 day)
- Change Failure Rate: What % of production changes cause incidents? (Target: <15%, Elite: <15%, High: 15-30%, Medium: 30-45%)
- Baseline current state - Measure where we are today
- Deployment frequency: Review last 3-6 months of Git commits, releases, deployments
- Lead time: Measure time from commit to production using Git/CI/CD pipeline
- Recovery time: Review incident data (PagerDuty, on-call logs) for MTTR
- Failure rate: Incidents caused by deployments vs total incidents
- Tools: Git logs, CI/CD pipeline data, incident tracking, APM/monitoring
- Set ambitious targets - Define where we want to be
- Elite level: Daily deployments, <1 day lead time, <1 hour recovery, <15% failure rate
- High level: Weekly+ deployments, <1 week lead time, <4 hour recovery, <30% failure rate
- Current state + 20-30% quarterly improvement targets
- Tailor to business criticality (SaaS = higher availability, B2B = more conservative)
- Identify improvement initiatives - What changes will move metrics?
- If lead time is long → Continuous integration bottlenecks, review process slow, complex builds
- If deployment frequency is low → Manual processes, complex releases, fear of deploying (test/quality gaps)
- If recovery time is slow → Lack of runbooks, slow diagnosis, manual rollback processes
- If failure rate is high → Insufficient testing, staging gaps, lack of monitoring/alerts
- Implement improvements - Execute concrete changes
- CI/CD: Faster builds (parallelization, caching), automated testing gates, progressive deployment
- Testing: Better test coverage (unit, integration, E2E), automated quality gates, staging environment parity
- Process: Trunk-based development, feature flags for safe deployments, automated rollback capability
- Monitoring: Better observability (logs, traces, metrics), alert tuning, incident playbooks
- Culture: On-call training, blameless post-mortems, learning from incidents
- Measure and report progress - Track metrics monthly
- Dashboard: Real-time DORA metrics visible to team
- Monthly review: Are metrics trending toward targets? Which initiatives are working?
- Root cause analysis: If metric regressed, what happened? (Incident spike, team changes, new complexity)
- Report to leadership: Show correlation between metrics and business outcomes (delivery speed, reliability, customer satisfaction)
- Celebrate wins: Highlight improvements, acknowledge effort
- Maintain and evolve continuously - Ongoing improvement cycle
- Quarterly review: Adjust targets as we improve, new baseline setting
- Major initiatives: Cloud migration, architecture change, new product may temporarily impact metrics
- New practices: Incorporate learnings, improve processes
- Benchmark: Compare against industry standards, peer companies, historical trends
- Iterate: Continuous improvement mindset, test changes, measure impact
Expected Output: Defined DORA metrics with baseline measurements, improvement initiatives underway, automated dashboards for visibility, and clear targets. Engineering team focused on operational excellence. Leadership sees correlation between engineering metrics and business outcomes.
See references/frameworks.md for detailed DORA implementation guide, improvement patterns, industry benchmarks, and red flag indicators.
Overview
The CTO Advisor skill provides comprehensive frameworks, tools, and templates for technical leadership excellence. It combines technology strategy methodologies, team scaling frameworks, architecture governance patterns, and engineering metrics to support CTOs in building world-class engineering organizations.
This skill addresses the full scope of CTO responsibilities: defining technology vision and roadmap, scaling engineering teams effectively, establishing architecture standards, managing vendor relationships, and driving engineering excellence through metrics and culture. All content is designed for immediate application in quarterly planning, architecture reviews, hiring initiatives, and engineering transformation programs.
Core Capabilities
Technology Strategy & Planning
- 3-5 year technology vision development
- Quarterly roadmap planning and execution
- Innovation management frameworks
- Technical debt assessment and reduction
- Python-based tech debt analyzer tool
Team Scaling & Development
- Engineering team scaling strategies
- Hiring velocity and pipeline planning
- Performance management frameworks
- Engineering culture building
- Python-based team scaling calculator
Architecture Governance
- Architecture Decision Records (ADR) templates
- Technology standards and guidelines
- System design review processes
- Vendor evaluation frameworks
- Build vs buy analysis
Engineering Excellence
- DORA metrics implementation
- Quality metrics tracking
- Team health indicators
- Incident management processes
- Post-mortem frameworks
Stakeholder Management
- Board and executive reporting
- Cross-functional partnerships
- Strategic initiative planning
- Crisis management playbooks
- Communication templates
Quick Start
Technical Debt Assessment
# Analyze technical debt across 5 categories with prioritized reduction plan
python scripts/tech_debt_analyzer.py system_data.json
# Generate JSON output for executive dashboards
python scripts/tech_debt_analyzer.py system_data.json --output json -f debt_report.json
# View help and input schema
python scripts/tech_debt_analyzer.py --help
See references/tools.md for detailed tool documentation, scoring guidelines, and reduction planning.
Team Scaling Planning
# Calculate optimal hiring plan, team structure, and budget projections
python scripts/team_scaling_calculator.py team_data.json
# Generate JSON output for board planning
python scripts/team_scaling_calculator.py team_data.json --output json -f scaling_plan.json
# View help and input schema
python scripts/team_scaling_calculator.py --help
See references/tools.md for scenario examples, budget estimation, and risk assessment guidance.
Key Workflows
1. Conduct Technical Debt Assessment
Time: 2-4 hours for comprehensive analysis
Gather System Data - Collect technical debt across all categories
- Code quality metrics (test coverage, complexity, duplication)
- Infrastructure issues (outdated dependencies, security vulnerabilities)
- Architecture debt (tight coupling, missing abstractions)
- Documentation gaps (missing or outdated docs)
- Testing coverage (unit, integration, E2E test gaps)
Run Tech Debt Analyzer - Generate prioritized reduction plan
python scripts/tech_debt_analyzer.py system_data.json
Review Analysis - Examine debt categorization and severity scores
- Critical debt (blocks features or causes incidents)
- High priority (impacts velocity or quality)
- Medium priority (technical quality improvements)
- Low priority (nice-to-have improvements)
Create Reduction Roadmap - Plan quarterly debt paydown
- Allocate 10-20% of engineering capacity to debt reduction
- Prioritize by risk and business impact
- Set measurable targets (test coverage, incident reduction)
Expected Output: Prioritized technical debt inventory with quarterly reduction plan and capacity allocation recommendations.
2. Plan Engineering Team Scaling
Time: 3-5 hours for comprehensive planning
Assess Current State - Analyze team structure and capacity
- Current headcount by role and seniority
- Team velocity and throughput metrics
- Skills gaps and hiring needs
- Budget constraints and runway
Run Team Scaling Calculator - Generate hiring plan and budget projections
python scripts/team_scaling_calculator.py team_data.json
Evaluate Recommendations - Review optimal team structure
- Hiring velocity and pipeline requirements
- Team composition (IC vs. leadership ratios)
- Budget impact and runway implications
- Risk assessment (key person dependencies, burnout indicators)
Build Execution Plan - Create quarterly hiring roadmap
- Prioritize critical roles (engineering managers, senior ICs)
- Establish hiring pipelines and sourcing strategies
- Plan onboarding and ramp-up timelines
- Set retention and culture preservation strategies
Expected Output: Data-driven hiring plan with budget projections, team structure recommendations, and execution timeline.
3. Make Architecture Decision (ADR Process)
Time: 1-2 weeks from proposal to decision
Identify Decision Point - Define architecture challenge or technology choice
- Business context and requirements
- Technical constraints and trade-offs
- Stakeholder needs and concerns
- Timeline and urgency
Research Options - Evaluate alternatives systematically
- List all viable options (including status quo)
- Assess pros/cons for each option
- Prototype or spike if needed
- Gather team and stakeholder input
Create ADR - Document decision using template from references/templates.md
- Status: Proposed/Accepted/Deprecated/Superseded
- Context: Problem statement and business drivers
- Decision: Chosen approach and rationale
- Consequences: Positive and negative impacts
Review and Approve - Get stakeholder buy-in
- Architecture review board discussion
- Engineering team feedback
- Security and compliance review
- Executive approval if budget/strategy impact
Communicate and Execute - Announce decision and track implementation
- Share ADR with engineering organization
- Update architecture documentation
- Track implementation progress
- Review decision after 6-12 months
Expected Output: Formalized ADR with clear rationale, stakeholder alignment, and implementation plan.
4. Establish Engineering Metrics (DORA Implementation)
Time: 2-4 weeks for initial setup, ongoing monitoring
Select Metrics Framework - Choose appropriate metrics for org maturity
- DORA metrics (deployment frequency, lead time, MTTR, change fail rate)
- Quality metrics (test coverage, bug rates, technical debt)
- Team health (satisfaction, retention, velocity)
- Business impact (feature adoption, customer satisfaction)
Instrument Data Collection - Set up automated tracking
- CI/CD pipeline metrics (GitHub Actions, CircleCI)
- Incident management data (PagerDuty, Opsgenie)
- Code quality tools (SonarQube, CodeClimate)
- Survey tools for team health (Culture Amp, Officevibe)
Build Dashboards - Create executive and team-level views
- Real-time DORA metrics dashboard
- Quarterly trend analysis
- Team-specific performance views
- Benchmarking against industry standards
Establish Targets - Set improvement goals
- Elite performers: Deploy frequency >1/day, lead time <1 day, MTTR <1 hour, change fail rate <15%
- High performers: Deploy frequency 1/week, lead time <1 week, MTTR <1 day, change fail rate <30%
- Current state baseline and quarterly improvement targets
Review and Iterate - Monthly metric reviews with leadership
- Identify trends and anomalies
- Celebrate wins and improvements
- Address regression areas
- Refine metrics based on learnings
Expected Output: Automated DORA metrics dashboard with quarterly improvement targets and executive reporting cadence.
Python Tools
tech_debt_analyzer.py
Analyzes technical debt across 5 categories with severity scoring and prioritized reduction recommendations.
Key Features:
- Multi-category debt assessment (code quality, infrastructure, architecture, documentation, testing)
- Severity scoring (0-100 scale with critical/high/medium/low classification)
- Impact analysis (velocity, quality, incident risk)
- Prioritized reduction roadmap with effort estimates
- JSON and human-readable output formats
- Capacity planning recommendations (10-20% allocation guidance)
Common Usage:
# Basic analysis
python scripts/tech_debt_analyzer.py system_data.json
# Generate JSON output for executive dashboards
python scripts/tech_debt_analyzer.py system_data.json --output json -f debt_report.json
# View input schema and examples
python scripts/tech_debt_analyzer.py --help
Use Cases:
- Quarterly technical debt assessments for executive planning
- Budget justification for engineering quality initiatives
- Risk assessment before major product launches
- New CTO onboarding to understand inherited debt
See references/tools.md for input format specifications, scoring algorithms, and integration examples.
team_scaling_calculator.py
Calculates optimal hiring plans, team structure recommendations, and budget projections for engineering organizations.
Key Features:
- Hiring velocity modeling based on growth targets
- Team composition recommendations (IC vs. manager ratios by org size)
- Budget projections with salary bands by role and location
- Risk assessment (key person dependencies, burnout indicators)
- Scenario planning (conservative, moderate, aggressive growth)
- JSON and human-readable output formats
- Runway impact analysis
Common Usage:
# Basic team scaling analysis
python scripts/team_scaling_calculator.py team_data.json
# Generate JSON output for board planning
python scripts/team_scaling_calculator.py team_data.json --output json -f scaling_plan.json
# View input schema and examples
python scripts/team_scaling_calculator.py --help
Use Cases:
- Annual and quarterly hiring planning
- Board-level budget discussions
- Fundraising planning (runway and hiring velocity modeling)
- Organization design and restructuring initiatives
- New CTO transition planning (understanding team structure needs)
See references/tools.md for input format specifications, calculation methodologies, and scenario examples.
Reference Materials
All detailed frameworks, templates, and tool documentation have been organized into focused reference files:
Technical Leadership Frameworks
- Technology strategy and roadmap development
- Innovation management frameworks
- Technical debt assessment strategies
- Team scaling and structure patterns
- Performance management systems
- Architecture governance (ADRs)
- Technology evaluation frameworks
- Vendor relationship management
- DORA and quality metrics
- Crisis management playbooks
- Stakeholder reporting frameworks
- Strategic initiatives (cloud, AI/ML, platform)
Communication Templates
- Weekly CTO schedule template
- Technology strategy presentation
- Team all-hands structure
- Board update email format
- ADR (Architecture Decision Record) template
- Incident post-mortem template
- Technology evaluation scorecard
- Engineering team OKR template
- Hiring scorecard template
- 1-on-1 meeting template
Python Tools Guide
- Tech debt analyzer comprehensive documentation
- Team scaling calculator detailed guide
- Input format specifications and examples
- Output interpretation guidelines
- Integration workflow examples
- Best practices and troubleshooting
- Real-world scenario examples
- Data privacy and security notes
Success Indicators
Technical Excellence
- System uptime >99.9%
- Deploy frequency >1 per day
- Technical debt <10% capacity allocation
- Zero critical security incidents
- Lead time for changes <1 day
Team Success
- Team satisfaction score >8/10
- Voluntary attrition <10% annually
- Key positions filled >90%
- Diversity metrics improving
- Internal promotion rate >30%
Business Impact
- Features delivered on-time >80%
- Engineering enables revenue growth
- Cost per transaction decreasing
- Innovation driving competitive advantage
- Customer-reported issues declining
Red Flags
- Technical debt increasing quarter-over-quarter
- Attrition rate rising above 15%
- Sprint velocity declining consistently
- Production incidents increasing
- Team morale scores dropping
- Budget overruns (>10% variance)
- Vendor lock-in concerns growing
- Security vulnerabilities accumulating
1---2name: cto-advisor3description: Technical leadership guidance for engineering teams, architecture decisions, and technology strategy. Includes tech debt analyzer, team scaling calculator, engineering metrics frameworks, technology evaluation tools, and ADR templates. Use when assessing technical debt, scaling engineering teams, evaluating technologies, making architecture decisions, establishing engineering metrics, or when user mentions CTO, tech debt, technical debt, team scaling, architecture decisions, technology evaluation, engineering metrics, DORA metrics, or technology strategy.4license: MIT5---67# CTO Advisor89## Key Workflows1011### Workflow 1: Comprehensive Technical Debt Assessment1213**Time:** 3-4 hours (data gathering and analysis)1415**Steps:**161. **Gather system data across 5 categories** - Collect metrics from engineering systems17 - Code metrics: Test coverage, cyclomatic complexity, code duplication percentage18 - Infrastructure: Deployment frequency, change lead time, incident rate, uptime19 - Architecture: Service coupling, deprecated patterns, monolith vs microservices assessment20 - Team velocity: 5-sprint trend, bug rate trend, refactoring time allocation21 - Technical: Outdated dependencies, security vulnerabilities, scalability assessment22 - Source data from: CI/CD dashboards, incident management systems, code analysis tools, sprint metrics232. **Run tech debt analyzer Python tool** - Execute comprehensive analysis24 ```bash25 python scripts/tech_debt_analyzer.py system_data.json26 ```27 - Scores each category 0-100 (100=excellent, 0=critical)28 - Produces prioritized reduction plan with estimated effort29 - Identifies which debt is blocking velocity, reliability, or hiring303. **Interpret results and identify root causes** - Understand debt landscape31 - Critical debt (score <40): Must address immediately (blocking scaling/reliability)32 - High debt (40-60): Needs attention next quarter (affecting efficiency)33 - Medium debt (60-80): Tactical improvements (quality enhancements)34 - Emerging debt (80+): Well-managed, preventive focus35 - Root cause analysis: Why did debt accumulate? Speed over quality, architectural limitation, team growth?364. **Develop quarterly reduction strategy** - Create actionable paydown plan37 - Tier 1 (Critical): Allocate 10-15% engineering capacity, target 2-sprint completion38 - Tier 2 (High): Allocate 5-10% engineering capacity, target next quarter39 - Tier 3 (Medium): Allocate 2-5% engineering capacity, target next half year40 - Balance: Don't allocate >20% to debt without impacting feature delivery415. **Create executive business case** - Present with impact analysis42 - Current impact: How is debt affecting velocity, reliability, hiring, or product?43 - Financial impact: Cost of incidents, developer productivity loss, hiring difficulty?44 - Paydown investment: How many engineer-months and cost?45 - Expected benefits: Faster deployments, fewer bugs, easier hiring, better retention?46 - Timeline: How many quarters to address critical debt?47 - See [references/templates.md](references/templates.md) for executive presentation template486. **Get leadership approval and allocation** - Secure commitment to plan49 - Present to CTO, VP Engineering, and CFO50 - Get committed budget and engineer allocation51 - Set quarterly targets and review cadence5253**Expected Output:** Quantified technical debt landscape with severity scores, prioritized reduction roadmap, business case for investment, and leadership-approved engineering allocation for debt paydown. Engineering team has clear guidance on what to fix first.5455See [references/tools.md](references/tools.md) for detailed tech debt analyzer documentation, scoring methodology, and reduction planning.5657### Workflow 2: Plan Engineering Team Scaling5859**Time:** 3-4 hours (analysis and planning)6061**Steps:**621. **Assess current team state** - Establish baseline for scaling decisions63 - Headcount by discipline: Frontend, backend, QA, DevOps, data engineers, etc.64 - Seniority distribution: % junior, mid, senior, staff engineers65 - Current velocity and throughput (story points/sprint)66 - Attrition rate and retention trends (% turnover annually)67 - Skill gaps: Missing expertise, bottleneck persons, weak areas68 - Geographic distribution and time zone coverage69 - Current hiring velocity (people hired per month)702. **Define business-driven scaling needs** - Understand what growth requires71 - Revenue growth targets: How much larger is business in 12-24 months?72 - Feature roadmap: How many new products, features, or services?73 - Platform initiatives: Architecture changes, tech debt paydown, infrastructure modernization?74 - Capability expansion: New skills needed (AI/ML, security, data, mobile)?75 - Quality improvements: Need for QA, DevOps, site reliability engineers?763. **Run team scaling calculator** - Calculate optimal hiring plan77 ```bash78 python scripts/team_scaling_calculator.py team_data.json79 ```80 - Outputs: Recommended team size, hiring plan by quarter, budget projections81 - Models: Conservative (10% growth/quarter), Steady (20% growth/quarter), Aggressive (40% growth/quarter)82 - Factors: Historical hiring velocity, onboarding ramp time, market competition, budget constraints834. **Evaluate scenarios and pick growth strategy** - Make informed choice84 - Conservative (slow scale): Low hiring risk, easier onboarding, may constrain growth85 - Steady (moderate scale): Balanced growth and risk, sustainable long-term86 - Aggressive (fast scale): Enables rapid growth but high coordination/onboarding overhead87 - Trade-offs: Speed to market vs quality vs team stability88 - Review budget impact, cash runway, and hiring market feasibility895. **Design team organization structure** - Plan the team for growth90 - Squad/team count: 1 squad (10 people), 2 squads (20 people), etc.91 - Leadership model: Engineering manager per squad, tech lead structure92 - Team missions: Backend squad, frontend squad, infrastructure squad, etc.93 - Cross-functional dependencies: Shared platforms, data, or services?94 - Onboarding infrastructure: Mentoring, bootcamps, documentation needed?956. **Create hiring and budget plan** - Execute scaled growth96 - Quarterly hiring targets (Q1: 2 engineers, Q2: 3 engineers, Q3: 4 engineers)97 - Roles to recruit: Mix of junior, mid, senior by team need98 - Compensation bands and budget total99 - Sourcing strategy: Referrals, agencies, direct recruitment, universities?100 - Onboarding plan: Bootcamp, buddy system, ramp-up timeline101 - Retention strategy: Career development, promotion paths, compensation reviews1027. **Present to board and secure approval** - Get executive buy-in103 - Show connection between team growth and business impact104 - Budget approved: Total cost of planned hiring105 - Hiring authority: Authority to approve hires per role/quarter106 - Runway impact: Does hiring fit with cash constraints?107108**Expected Output:** Detailed engineering hiring plan with quarterly targets by role, team organization design, budget projections, and board-approved hiring authority. Organization can execute growth strategy with clear goals and constraints.109110See [references/tools.md](references/tools.md) for team scaling calculator documentation, scenario analysis examples, budget modeling, and risk assessment.111112### Workflow 3: Make Architecture Decisions Using ADR Process113114**Time:** 1-2 weeks from proposal to decision115116**Steps:**1171. **Identify architecture decision point** - When to formally decide118 - New system/service design: Microservice vs monolith vs serverless?119 - Technology selection: Database (PostgreSQL vs MongoDB), language, framework120 - Integration approach: API-first, event-driven, batch processing, real-time streaming?121 - Data strategy: Schema design, replication, backup, disaster recovery?122 - Migration initiative: Cloud migration, platform changes, major refactoring?1232. **Research and evaluate options** - Systematic evaluation of alternatives124 - List 2-3 viable options (always include status quo)125 - For each option: Pros/cons, effort to implement, long-term maintenance, cost, risk126 - Prototype or spike if decision is critical and uncertain127 - Gather input: Team technical discussion, stakeholder concerns, security/compliance review1283. **Create Architecture Decision Record (ADR)** - Document using template129 - Status: Proposed (being evaluated), Accepted (decided), Deprecated (no longer used), Superseded (replaced)130 - Context: What problem are we solving? Business drivers? Technical constraints?131 - Decision: Which option did we choose and why?132 - Consequences: Positive and negative trade-offs of chosen approach133 - Alternatives considered: Why we didn't choose other options134 - See [references/templates.md](references/templates.md) for ADR template1354. **Get stakeholder buy-in** - Review and approval process136 - Architecture review board: Senior engineers discuss, challenge assumptions, approve137 - Engineering team: Broader discussion, concerns, implementation questions138 - Security/compliance: Ensure meets standards, no vulnerabilities introduced139 - Executive review: If impacts budget, timeline, or strategy140 - Document approvals and who signed off1415. **Communicate decision widely** - Announce and build shared understanding142 - Share ADR with full engineering organization143 - Update architecture documentation (diagrams, decision log, runbooks)144 - Conduct tech talk or workshop explaining decision145 - Q&A session for concerns or questions1466. **Execute and monitor implementation** - Track decision outcome147 - Project team implements architecture per ADR148 - Validate: Is the system performing as expected? Trade-offs real?149 - Adjust: If assumptions were wrong, document lessons and potential revisions150 - Review periodically (quarterly or at 6 month mark)151 - Maintain ADR as living document152153**Expected Output:** Formalized architecture decision with clear rationale, stakeholder consensus, and implementation plan. Organization learns from decisions, documentation becomes reference for future similar decisions.154155See [references/frameworks.md](references/frameworks.md) for architecture governance patterns, design review checklists, and technology evaluation frameworks.156157### Workflow 4: Establish DORA Metrics and Engineering Excellence158159**Time:** 4-6 weeks for implementation, ongoing monitoring160161**Steps:**1621. **Understand DORA metrics framework** - The 4 key engineering performance indicators163 - **Deployment Frequency:** How often do we deploy to production? (Target: Daily or on-demand, Elite: >1/day, High: 1/week, Medium: 1/month)164 - **Lead Time for Changes:** From code commit to production deploy? (Target: <1 day, Elite: <1 day, High: <1 week, Medium: <1 month)165 - **Mean Time to Recovery (MTTR):** How fast do we recover from production incidents? (Target: <1 hour, Elite: <1 hour, High: <4 hours, Medium: <1 day)166 - **Change Failure Rate:** What % of production changes cause incidents? (Target: <15%, Elite: <15%, High: 15-30%, Medium: 30-45%)1672. **Baseline current state** - Measure where we are today168 - Deployment frequency: Review last 3-6 months of Git commits, releases, deployments169 - Lead time: Measure time from commit to production using Git/CI/CD pipeline170 - Recovery time: Review incident data (PagerDuty, on-call logs) for MTTR171 - Failure rate: Incidents caused by deployments vs total incidents172 - Tools: Git logs, CI/CD pipeline data, incident tracking, APM/monitoring1733. **Set ambitious targets** - Define where we want to be174 - Elite level: Daily deployments, <1 day lead time, <1 hour recovery, <15% failure rate175 - High level: Weekly+ deployments, <1 week lead time, <4 hour recovery, <30% failure rate176 - Current state + 20-30% quarterly improvement targets177 - Tailor to business criticality (SaaS = higher availability, B2B = more conservative)1784. **Identify improvement initiatives** - What changes will move metrics?179 - If lead time is long → Continuous integration bottlenecks, review process slow, complex builds180 - If deployment frequency is low → Manual processes, complex releases, fear of deploying (test/quality gaps)181 - If recovery time is slow → Lack of runbooks, slow diagnosis, manual rollback processes182 - If failure rate is high → Insufficient testing, staging gaps, lack of monitoring/alerts1835. **Implement improvements** - Execute concrete changes184 - CI/CD: Faster builds (parallelization, caching), automated testing gates, progressive deployment185 - Testing: Better test coverage (unit, integration, E2E), automated quality gates, staging environment parity186 - Process: Trunk-based development, feature flags for safe deployments, automated rollback capability187 - Monitoring: Better observability (logs, traces, metrics), alert tuning, incident playbooks188 - Culture: On-call training, blameless post-mortems, learning from incidents1896. **Measure and report progress** - Track metrics monthly190 - Dashboard: Real-time DORA metrics visible to team191 - Monthly review: Are metrics trending toward targets? Which initiatives are working?192 - Root cause analysis: If metric regressed, what happened? (Incident spike, team changes, new complexity)193 - Report to leadership: Show correlation between metrics and business outcomes (delivery speed, reliability, customer satisfaction)194 - Celebrate wins: Highlight improvements, acknowledge effort1957. **Maintain and evolve continuously** - Ongoing improvement cycle196 - Quarterly review: Adjust targets as we improve, new baseline setting197 - Major initiatives: Cloud migration, architecture change, new product may temporarily impact metrics198 - New practices: Incorporate learnings, improve processes199 - Benchmark: Compare against industry standards, peer companies, historical trends200 - Iterate: Continuous improvement mindset, test changes, measure impact201202**Expected Output:** Defined DORA metrics with baseline measurements, improvement initiatives underway, automated dashboards for visibility, and clear targets. Engineering team focused on operational excellence. Leadership sees correlation between engineering metrics and business outcomes.203204See [references/frameworks.md](references/frameworks.md) for detailed DORA implementation guide, improvement patterns, industry benchmarks, and red flag indicators.205206## Overview207208The CTO Advisor skill provides comprehensive frameworks, tools, and templates for technical leadership excellence. It combines technology strategy methodologies, team scaling frameworks, architecture governance patterns, and engineering metrics to support CTOs in building world-class engineering organizations.209210This skill addresses the full scope of CTO responsibilities: defining technology vision and roadmap, scaling engineering teams effectively, establishing architecture standards, managing vendor relationships, and driving engineering excellence through metrics and culture. All content is designed for immediate application in quarterly planning, architecture reviews, hiring initiatives, and engineering transformation programs.211212## Core Capabilities213214**Technology Strategy & Planning**215- 3-5 year technology vision development216- Quarterly roadmap planning and execution217- Innovation management frameworks218- Technical debt assessment and reduction219- Python-based tech debt analyzer tool220221**Team Scaling & Development**222- Engineering team scaling strategies223- Hiring velocity and pipeline planning224- Performance management frameworks225- Engineering culture building226- Python-based team scaling calculator227228**Architecture Governance**229- Architecture Decision Records (ADR) templates230- Technology standards and guidelines231- System design review processes232- Vendor evaluation frameworks233- Build vs buy analysis234235**Engineering Excellence**236- DORA metrics implementation237- Quality metrics tracking238- Team health indicators239- Incident management processes240- Post-mortem frameworks241242**Stakeholder Management**243- Board and executive reporting244- Cross-functional partnerships245- Strategic initiative planning246- Crisis management playbooks247- Communication templates248249## Quick Start250251### Technical Debt Assessment252253```bash254# Analyze technical debt across 5 categories with prioritized reduction plan255python scripts/tech_debt_analyzer.py system_data.json256257# Generate JSON output for executive dashboards258python scripts/tech_debt_analyzer.py system_data.json --output json -f debt_report.json259260# View help and input schema261python scripts/tech_debt_analyzer.py --help262```263264See [references/tools.md](references/tools.md) for detailed tool documentation, scoring guidelines, and reduction planning.265266### Team Scaling Planning267268```bash269# Calculate optimal hiring plan, team structure, and budget projections270python scripts/team_scaling_calculator.py team_data.json271272# Generate JSON output for board planning273python scripts/team_scaling_calculator.py team_data.json --output json -f scaling_plan.json274275# View help and input schema276python scripts/team_scaling_calculator.py --help277```278279See [references/tools.md](references/tools.md) for scenario examples, budget estimation, and risk assessment guidance.280281## Key Workflows282283### 1. Conduct Technical Debt Assessment284285**Time:** 2-4 hours for comprehensive analysis2862871. **Gather System Data** - Collect technical debt across all categories288 - Code quality metrics (test coverage, complexity, duplication)289 - Infrastructure issues (outdated dependencies, security vulnerabilities)290 - Architecture debt (tight coupling, missing abstractions)291 - Documentation gaps (missing or outdated docs)292 - Testing coverage (unit, integration, E2E test gaps)2932942. **Run Tech Debt Analyzer** - Generate prioritized reduction plan295 ```bash296 python scripts/tech_debt_analyzer.py system_data.json297 ```2982993. **Review Analysis** - Examine debt categorization and severity scores300 - Critical debt (blocks features or causes incidents)301 - High priority (impacts velocity or quality)302 - Medium priority (technical quality improvements)303 - Low priority (nice-to-have improvements)3043054. **Create Reduction Roadmap** - Plan quarterly debt paydown306 - Allocate 10-20% of engineering capacity to debt reduction307 - Prioritize by risk and business impact308 - Set measurable targets (test coverage, incident reduction)309310**Expected Output:** Prioritized technical debt inventory with quarterly reduction plan and capacity allocation recommendations.311312### 2. Plan Engineering Team Scaling313314**Time:** 3-5 hours for comprehensive planning3153161. **Assess Current State** - Analyze team structure and capacity317 - Current headcount by role and seniority318 - Team velocity and throughput metrics319 - Skills gaps and hiring needs320 - Budget constraints and runway3213222. **Run Team Scaling Calculator** - Generate hiring plan and budget projections323 ```bash324 python scripts/team_scaling_calculator.py team_data.json325 ```3263273. **Evaluate Recommendations** - Review optimal team structure328 - Hiring velocity and pipeline requirements329 - Team composition (IC vs. leadership ratios)330 - Budget impact and runway implications331 - Risk assessment (key person dependencies, burnout indicators)3323334. **Build Execution Plan** - Create quarterly hiring roadmap334 - Prioritize critical roles (engineering managers, senior ICs)335 - Establish hiring pipelines and sourcing strategies336 - Plan onboarding and ramp-up timelines337 - Set retention and culture preservation strategies338339**Expected Output:** Data-driven hiring plan with budget projections, team structure recommendations, and execution timeline.340341### 3. Make Architecture Decision (ADR Process)342343**Time:** 1-2 weeks from proposal to decision3443451. **Identify Decision Point** - Define architecture challenge or technology choice346 - Business context and requirements347 - Technical constraints and trade-offs348 - Stakeholder needs and concerns349 - Timeline and urgency3503512. **Research Options** - Evaluate alternatives systematically352 - List all viable options (including status quo)353 - Assess pros/cons for each option354 - Prototype or spike if needed355 - Gather team and stakeholder input3563573. **Create ADR** - Document decision using template from [references/templates.md](references/templates.md)358 - Status: Proposed/Accepted/Deprecated/Superseded359 - Context: Problem statement and business drivers360 - Decision: Chosen approach and rationale361 - Consequences: Positive and negative impacts3623634. **Review and Approve** - Get stakeholder buy-in364 - Architecture review board discussion365 - Engineering team feedback366 - Security and compliance review367 - Executive approval if budget/strategy impact3683695. **Communicate and Execute** - Announce decision and track implementation370 - Share ADR with engineering organization371 - Update architecture documentation372 - Track implementation progress373 - Review decision after 6-12 months374375**Expected Output:** Formalized ADR with clear rationale, stakeholder alignment, and implementation plan.376377### 4. Establish Engineering Metrics (DORA Implementation)378379**Time:** 2-4 weeks for initial setup, ongoing monitoring3803811. **Select Metrics Framework** - Choose appropriate metrics for org maturity382 - DORA metrics (deployment frequency, lead time, MTTR, change fail rate)383 - Quality metrics (test coverage, bug rates, technical debt)384 - Team health (satisfaction, retention, velocity)385 - Business impact (feature adoption, customer satisfaction)3863872. **Instrument Data Collection** - Set up automated tracking388 - CI/CD pipeline metrics (GitHub Actions, CircleCI)389 - Incident management data (PagerDuty, Opsgenie)390 - Code quality tools (SonarQube, CodeClimate)391 - Survey tools for team health (Culture Amp, Officevibe)3923933. **Build Dashboards** - Create executive and team-level views394 - Real-time DORA metrics dashboard395 - Quarterly trend analysis396 - Team-specific performance views397 - Benchmarking against industry standards3983994. **Establish Targets** - Set improvement goals400 - Elite performers: Deploy frequency >1/day, lead time <1 day, MTTR <1 hour, change fail rate <15%401 - High performers: Deploy frequency 1/week, lead time <1 week, MTTR <1 day, change fail rate <30%402 - Current state baseline and quarterly improvement targets4034045. **Review and Iterate** - Monthly metric reviews with leadership405 - Identify trends and anomalies406 - Celebrate wins and improvements407 - Address regression areas408 - Refine metrics based on learnings409410**Expected Output:** Automated DORA metrics dashboard with quarterly improvement targets and executive reporting cadence.411412## Python Tools413414### tech_debt_analyzer.py415416Analyzes technical debt across 5 categories with severity scoring and prioritized reduction recommendations.417418**Key Features:**419- Multi-category debt assessment (code quality, infrastructure, architecture, documentation, testing)420- Severity scoring (0-100 scale with critical/high/medium/low classification)421- Impact analysis (velocity, quality, incident risk)422- Prioritized reduction roadmap with effort estimates423- JSON and human-readable output formats424- Capacity planning recommendations (10-20% allocation guidance)425426**Common Usage:**427```bash428# Basic analysis429python scripts/tech_debt_analyzer.py system_data.json430431# Generate JSON output for executive dashboards432python scripts/tech_debt_analyzer.py system_data.json --output json -f debt_report.json433434# View input schema and examples435python scripts/tech_debt_analyzer.py --help436```437438**Use Cases:**439- Quarterly technical debt assessments for executive planning440- Budget justification for engineering quality initiatives441- Risk assessment before major product launches442- New CTO onboarding to understand inherited debt443444See [references/tools.md](references/tools.md) for input format specifications, scoring algorithms, and integration examples.445446### team_scaling_calculator.py447448Calculates optimal hiring plans, team structure recommendations, and budget projections for engineering organizations.449450**Key Features:**451- Hiring velocity modeling based on growth targets452- Team composition recommendations (IC vs. manager ratios by org size)453- Budget projections with salary bands by role and location454- Risk assessment (key person dependencies, burnout indicators)455- Scenario planning (conservative, moderate, aggressive growth)456- JSON and human-readable output formats457- Runway impact analysis458459**Common Usage:**460```bash461# Basic team scaling analysis462python scripts/team_scaling_calculator.py team_data.json463464# Generate JSON output for board planning465python scripts/team_scaling_calculator.py team_data.json --output json -f scaling_plan.json466467# View input schema and examples468python scripts/team_scaling_calculator.py --help469```470471**Use Cases:**472- Annual and quarterly hiring planning473- Board-level budget discussions474- Fundraising planning (runway and hiring velocity modeling)475- Organization design and restructuring initiatives476- New CTO transition planning (understanding team structure needs)477478See [references/tools.md](references/tools.md) for input format specifications, calculation methodologies, and scenario examples.479480## Reference Materials481482All detailed frameworks, templates, and tool documentation have been organized into focused reference files:483484### [Technical Leadership Frameworks](references/frameworks.md)485- Technology strategy and roadmap development486- Innovation management frameworks487- Technical debt assessment strategies488- Team scaling and structure patterns489- Performance management systems490- Architecture governance (ADRs)491- Technology evaluation frameworks492- Vendor relationship management493- DORA and quality metrics494- Crisis management playbooks495- Stakeholder reporting frameworks496- Strategic initiatives (cloud, AI/ML, platform)497498### [Communication Templates](references/templates.md)499- Weekly CTO schedule template500- Technology strategy presentation501- Team all-hands structure502- Board update email format503- ADR (Architecture Decision Record) template504- Incident post-mortem template505- Technology evaluation scorecard506- Engineering team OKR template507- Hiring scorecard template508- 1-on-1 meeting template509510### [Python Tools Guide](references/tools.md)511- Tech debt analyzer comprehensive documentation512- Team scaling calculator detailed guide513- Input format specifications and examples514- Output interpretation guidelines515- Integration workflow examples516- Best practices and troubleshooting517- Real-world scenario examples518- Data privacy and security notes519520## Success Indicators521522**Technical Excellence**523- System uptime >99.9%524- Deploy frequency >1 per day525- Technical debt <10% capacity allocation526- Zero critical security incidents527- Lead time for changes <1 day528529**Team Success**530- Team satisfaction score >8/10531- Voluntary attrition <10% annually532- Key positions filled >90%533- Diversity metrics improving534- Internal promotion rate >30%535536**Business Impact**537- Features delivered on-time >80%538- Engineering enables revenue growth539- Cost per transaction decreasing540- Innovation driving competitive advantage541- Customer-reported issues declining542543## Red Flags544545- Technical debt increasing quarter-over-quarter546- Attrition rate rising above 15%547- Sprint velocity declining consistently548- Production incidents increasing549- Team morale scores dropping550- Budget overruns (>10% variance)551- Vendor lock-in concerns growing552- Security vulnerabilities accumulating