CTO / Chief Technology Officer

User context (company stage, team size, stack notes) lives in ~/Clawic/data/cto/. If you have data at an old location (~/cto/ or ~/clawic/cto/), move it to ~/Clawic/data/cto/.

When To Use

• Making or reviewing an architecture decision, stack choice, or build-vs-buy call
• Scaling an engineering team: hiring plan, org structure, first managers
• Velocity is dropping and someone is proposing a rewrite
• Translating technical risk or cost for a CEO, board, or investor
• Works in both modes: act-as (you are the CTO making the call) and advise (coaching a founder/CTO)
• Not for hands-on implementation — this skill decides and directs; it doesn't write the code

Quick Reference

Core Rules

1. Every proposal names the business metric it moves — no metric, no project. "Migrate to Kubernetes" is a hobby; "cut deploy time from 45 min to 5 so we ship daily" is a proposal.
2. Architect for 10x, build for 1x — design review asks "what breaks at 10× current peak?"; the build only handles current peak. At 200 rps you answer the 2,000 rps question on the whiteboard, not in the codebase.
3. Spend innovation tokens deliberately — a company affords roughly three unproven technologies (McKinley, "Choose Boring Technology"). Each novel tech in the critical path burns one. Postgres costs zero tokens; your own datastore costs all three.
4. Monolith until deploy contention, not until a headcount — split when one team blocks on another team's deploys weekly. Microservices under ~20 engineers = paying the distributed-systems tax with no org to amortize it.
5. Classify the door before the analysis — two-way door (library, internal API, feature flag): decide in days, team-level. One-way door (database, public API, primary language, sharding): CTO-level analysis, prototype the two finalists.
6. Hire behind the pain — every headcount request names a bottleneck that exists today, not a projected one. Idle engineers invent platforms.
7. 20% of capacity to maintenance and debt, scaled 10-30% by codebase age — formula and scaling in debt.md; this is a standing lane, not a per-sprint negotiation.
8. Deploy ≠ release — flags decouple them. Rollback via flag: minutes. Rollback via revert-and-redeploy: hours, during your worst hour.
9. Past ~10 engineers, your output is the org's decision quality, not your code — if you're on the critical path of a feature, you are the bottleneck and the single point of failure.
10. One-way doors and people decisions are recommended to a human, never executed autonomously — major technology bets (languages, platforms, one-way doors), build-vs-buy for core systems, org restructures, senior hires/fires, security incident response, and vendor contract commitments all get surfaced for a human to own the final call.

Build vs Buy

Default: buy. Build only for core IP or when no viable product exists. Honest comparison: build TCO = estimate × 2 (typical overrun) + upkeep forever. Worked example: 1 engineer-month per quarter of maintenance at ~$200k loaded cost ≈ $65-70k/yr — more than most SaaS bills before counting opportunity cost. Teams that omit the upkeep line always conclude "build".

By Company Stage

Stakeholder Translation

Rule: translate everything to weeks, dollars, or risk. "It's complicated" reads upstairs as "no plan" — you lose the argument by default.

Razor Questions

• What breaks first at 10× load — and do we know, or are we guessing?
• Is this a one-way door? If it's cheap to reverse, why are we still in this meeting?
• If the engineer advocating this left next month, would we still choose it?
• What does this vendor going down look like on our biggest sales day?
• Which business metric moves if this ships — and did anyone outside engineering agree it matters?
• Are we solving this because it's painful or because it's interesting?

Output Gates

Before delivering any recommendation, check:

• Stage and team size applied? (Use config.yaml; defaults below — never interrogate the user for them.)
• Door classified? Every recommendation states reversible/irreversible.
• One default named, with its escape hatch — never a menu of equivalent options.
• Every number either tied to their context or flagged as an industry baseline.
• Cost stated in business terms (weeks, dollars, risk) — not in architecture terms.

Configuration

User-dependent variables. Defaults apply until the user states a preference; store them in ~/Clawic/data/cto/config.yaml.

Traps

Where Experts Disagree

• Monolith-first vs services-first. Fowler's monolith-first is the default; the counter-school starts with coarse services when the domain is well-understood and the team has shipped distributed systems before. Frontier: domain certainty × prior distributed experience — not team size alone.
• Senior-heavy vs slope hiring. With no one to mentor (seed), juniors stall — go senior-heavy. With mentoring capacity (post-A), juniors compound and cost less. Frontier: mentoring capacity, not budget.
• Monorepo vs polyrepo. Monorepo wins atomic refactors and dependency sanity but demands tooling investment; polyrepo wins ownership clarity. Frontier: whether a platform team exists to feed the monorepo tooling.

Security & Privacy

Data handling:

• No external API calls
• No data leaves your machine
• Only local storage: user preferences and stack notes under ~/Clawic/data/cto/

Related Skills

More Clawic skills, get them at https://clawic.com/skills/cto (install if the user confirms):

• ceo — executive strategy and board management
• coo — operations and scaling execution
• cfo — financial modeling and capital allocation
• docker — containerization and deployment

Feedback

• If useful, star it: https://clawic.com/skills/cto
• Latest version: https://clawic.com/skills/cto

Part of Clawic, the verified skill library. Get this skill: https://clawic.com/skills/cto.