CTO Advisor

What This Skill Does

• The CTO Advisor skill provides technical leadership frameworks for architecture, engineering teams, technology strategy, and technical decision-making.
• It helps CT.
• Os and engineering leaders align technology investments with business priorities and scale their engineering organizations effectively.
• It offers tools for assessing tech debt and modeling team growth.

When to Use

• Aligning technology with business goals.
• Scaling engineering teams effectively.
• Evaluating build vs.
• buy decisions.
• Managing technical debt strategically.
• Improving engineering culture and practices.
• Developing a technology vision and roadmap.

Key Features

• Provides frameworks for technology strategy and architecture.
• Offers guidance on engineering team leadership and scaling.
• Includes tools for tech debt analysis and team scaling calculations.
• Emphasizes blameless post-mortems and documentation.
• Focuses on architecture decision records (AD.
• Rs).
• Provides references for technology evaluation and engineering metrics.

Manual Installation

• Manual installation.
• View Full Skill Content.
• The complete markdown content that gets installedCTO Advisor.

Technical leadership frameworks for architecture, engineering teams, technology strategy, and technical decision-making.

Keywords

CTO, chief technology officer, tech debt, technical debt, architecture, engineering metrics, DORA, team scaling, technology evaluation, build vs buy, cloud migration, platform engineering, AI/ML strategy, system design, incident response, engineering culture

Quick Start

• python scripts/tech_debt_analyzer.py # Assess technical debt severity and remediation plan. python scripts/team_scaling_calculator.py # Model engineering team growth and cost

Core Responsibilities

• 1.

• Technology Strategy.

Align technology investments with business priorities.

Strategy components: Technology vision (3-year: where the platform is going) Architecture roadmap (what to build, refactor, or replace) Innovation budget (10-20% of engineering capacity for experimentation) Build vs buy decisions (default: buy unless it's your core IP) Technical debt strategy (management, not elimination)

See references/technology_evaluation_framework.md for the full evaluation framework.

2. Engineering Team Leadership

• Scale the engineering org's productivity — not individual output.

Scaling engineering: Hire for the next stage, not the current one Every 3x in team size requires a reorg Manager:IC ratio: 5-8 direct reports optimal Senior:junior ratio: at least 1:2 (invert and you'll drown in mentoring)

Culture: Blameless post-mortems (incidents are system failures, not people failures) Documentation as a first-class citizen Code review as mentoring, not gatekeeping On-call that's sustainable (not heroic)

See references/engineering_metrics.md for DORA metrics and the engineering health dashboard.

3. Architecture Governance

• Create the framework for making good decisions — not making every decision yourself.

Architecture Decision Records (AD. Rs): Every significant decision gets documented: context, options, decision, consequences Decisions are discoverable (not buried in Slack) Decisions can be superseded (not permanent)

See references/architecture_decision_records.md for ADR templates and the decision review process.

4. Vendor & Platform Management

• Every vendor is a dependency.
• Every dependency is a risk.

Evaluation criteria: Does it solve a real problem? Can we migrate away? Is the vendor stable? What's the total cost (license + integration + maintenance)?

5. Crisis Management

• Incident response, security breaches, major outages, data loss.

Your role in a crisis: Ensure the right people are on it, communication is flowing, and the business is informed. Post-crisis: blameless retrospective within 48 hours.

Workflows

Tech Debt Assessment Workflow

Step 1 — Run the analyzer python scripts/tech_debt_analyzer.py --output report.json

Step 2 — Interpret results The analyzer produces a severity-scored inventory. Review each item against: Severity (P0–P3): how much is it blocking velocity or creating risk? Cost-to-fix: engineering days estimated to remediate Blast radius: how many systems / teams are affected?

Step 3 — Build a prioritized remediation plan Sort by: (Severity × Blast Radius) / Cost-to-fix — highest score = fix first. Group items into: (a) immediate sprint, (b) next quarter, (c) tracked backlog.

Step 4 — Validate before presenting to stakeholders [ ] Every P0/P1 item has an owner and a target date [ ] Cost-to-fix estimates reviewed with the relevant tech lead [ ] Debt ratio calculated: maintenance work / total engineering capacity (target: < 25%) [ ] Remediation plan fits within capacity (don't promise 40 points of debt reduction in a 2-week sprint)

Example output — Tech Debt Inventory:

ADR Creation Workflow

Step 1 — Identify the decision Trigger an ADR when: the decision affects more than one team, is hard to reverse, or has cost/risk implications > 1 sprint of effort.

Step 2 — Draft the ADR Use the template from references/architecture_decision_records.md: Title: [Short noun phrase] Status: Proposed | Accepted | Superseded Context: What is the problem? What constraints exist? Options Considered:

• Option A: [description] — TCO: $X | Risk: Low/Med/High
• Option B: [description] — TCO: $X | Risk: Low/Med/High Decision: [Chosen option and rationale] Consequences: [What becomes easier? What becomes harder?]

Step 3 — Validation checkpoint (before finalizing) [ ] All options include a 3-year TCO estimate [ ] At least one "do nothing" or "buy" alternative is documented [ ] Affected team leads have reviewed and signed off [ ] Consequences section addresses reversibility and migration path [ ] ADR is committed to the repository (not left in a doc or Slack thread)

Step 4 — Communicate and close Share the accepted ADR in the engineering all-hands or architecture sync. Link it from the relevant service's README.

Build vs Buy Analysis Workflow

Step 1 — Define requirements (functional + non-functional) Step 2 — Identify candidate vendors or internal build scope Step 3 — Score each option:

Step 4 — Default rule: Buy unless it is core IP or no vendor meets ≥ 70% of requirements. Step 5 — Document the decision as an ADR (see ADR workflow above).

Key Questions a CTO Asks

"What's our biggest technical risk right now — not the most annoying, the most dangerous?" "If we 10x our traffic tomorrow, what breaks first?" "How much of our engineering time goes to maintenance vs new features?" "What would a new engineer say about our codebase after their first week?" "Which technical decision from 2 years ago is hurting us most today?" "Are we building this because it's the right solution, or because it's the interesting one?" "What's our bus factor on critical systems?"

CTO Metrics Dashboard