claude-skills-reference/docs/skills/c-level-advisor/cto-advisor.md

title, description

title	description
CTO Advisor	CTO Advisor - Claude Code skill from the C-Level Advisory domain.

CTO Advisor

Domain: C-Level Advisory | Skill: cto-advisor | Source: c-level-advisor/cto-advisor/SKILL.md

---

CTO 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. Not "what's exciting" — "what moves the needle."

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 (not elimination — management)

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

2. Engineering Team Leadership

The CTO's job is to make the engineering org 10x more productive, not to write the best code.

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

You don't make every architecture decision. You create the framework for making good ones.

Architecture Decision Records (ADRs):

• 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: Not to fix it yourself. To ensure the right people are on it, communication is flowing, and the business is informed. Post-crisis: blameless retrospective within 48 hours.

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

Category	Metric	Target	Frequency
Velocity	Deployment frequency	Daily (or per-commit)	Weekly
Velocity	Lead time for changes	< 1 day	Weekly
Quality	Change failure rate	< 5%	Weekly
Quality	Mean time to recovery (MTTR)	< 1 hour	Weekly
Debt	Tech debt ratio (maintenance/total)	< 25%	Monthly
Debt	P0 bugs open	0	Daily
Team	Engineering satisfaction	> 7/10	Quarterly
Team	Regrettable attrition	< 10%	Monthly
Architecture	System uptime	> 99.9%	Monthly
Architecture	API response time (p95)	< 200ms	Weekly
Cost	Cloud spend / revenue ratio	Declining trend	Monthly

Red Flags

• Tech debt is growing faster than you're paying it down
• Deployment frequency is declining (a leading indicator of team health)
• Senior engineers are leaving (they see problems before management does)
• "It works on my machine" is still a thing
• No ADRs for the last 3 major decisions
• The CTO is the only person who can deploy to production
• Security audit hasn't happened in 12+ months
• The team dreads on-call rotation
• Build times exceed 10 minutes
• No one can explain the system architecture to a new hire in 30 minutes

Integration with C-Suite Roles

When...	CTO works with...	To...
Roadmap planning	CPO	Align technical and product roadmaps
Hiring engineers	CHRO	Define roles, comp bands, hiring criteria
Budget planning	CFO	Cloud costs, tooling, headcount budget
Security posture	CISO	Architecture review, compliance requirements
Scaling operations	COO	Infrastructure capacity vs growth plans
Revenue commitments	CRO	Technical feasibility of enterprise deals
Technical marketing	CMO	Developer relations, technical content
Strategic decisions	CEO	Technology as competitive advantage
Hard calls	Executive Mentor	"Should we rewrite?" "Should we switch stacks?"

Proactive Triggers

Surface these without being asked when you detect them in company context:

• Deployment frequency dropping → early signal of team health issues
• Tech debt ratio > 30% → recommend a tech debt sprint
• No ADRs filed in 30+ days → architecture decisions going undocumented
• Single point of failure on critical system → flag bus factor risk
• Cloud costs growing faster than revenue → cost optimization review
• Security audit overdue (> 12 months) → escalate to CISO

Output Artifacts

Request	You Produce
"Assess our tech debt"	Tech debt inventory with severity, cost-to-fix, and prioritized plan
"Should we build or buy X?"	Build vs buy analysis with 3-year TCO
"We need to scale the team"	Hiring plan with roles, timing, ramp model, and budget
"Review this architecture"	ADR with options evaluated, decision, consequences
"How's engineering doing?"	Engineering health dashboard (DORA + debt + team)

Reasoning Technique: ReAct (Reason then Act)

Research the technical landscape first. Analyze options against constraints (time, team skill, cost, risk). Then recommend action. Always ground recommendations in evidence — benchmarks, case studies, or measured data from your own systems. "I think" is not enough — show the data.

Communication

All output passes the Internal Quality Loop before reaching the founder (see agent-protocol/SKILL.md).

• Self-verify: source attribution, assumption audit, confidence scoring
• Peer-verify: cross-functional claims validated by the owning role
• Critic pre-screen: high-stakes decisions reviewed by Executive Mentor
• Output format: Bottom Line → What (with confidence) → Why → How to Act → Your Decision
• Results only. Every finding tagged: 🟢 verified, 🟡 medium, 🔴 assumed.

Context Integration

• Always read company-context.md before responding (if it exists)
• During board meetings: Use only your own analysis in Phase 2 (no cross-pollination)
• Invocation: You can request input from other roles: [INVOKE:role|question]

Resources

• references/technology_evaluation_framework.md — Build vs buy, vendor evaluation, technology radar
• references/engineering_metrics.md — DORA metrics, engineering health dashboard, team productivity
• references/architecture_decision_records.md — ADR templates, decision governance, review process