CTO Advisory — Tech Strategy and Org Design

Field	Value
Type	Skill Resource
Source	`~/.copilot/skills/exec/references/cto-advisory.md`
Description	Not specified

Source Content

CTO Advisory — Tech Strategy and Org Design

When to use this

You’re the CTO or advising the CTO on technology strategy, org topology, team scaling, tech-debt investment, platform choices, or architecture governance. The decision horizon is 12–36 months, and it touches people and systems together.

The questions a CTO decision must answer

What business outcome is this serving? Growth, margin, risk reduction? Be specific.
What’s the org constraint? Team count, structure, recent attrition, manager:engineer ratio. Conway’s Law — the system’s structure mirrors the org structure — is your first constraint before architecture.
What is the DORA reality today? Deployment frequency, lead time for changes, mean time to recovery, change failure rate. No vanity metrics.
What’s the reversibility? Is this a one-way door (builds on this choice for years) or two-way (easy to undo)?

The CTO framework

Read the org first

Before you evaluate Kubernetes or a new database, understand:

Team count and structure. 10 engineers in one team can be organized one way; 50 across five teams demands a different topology.
Manager:engineer ratio. Healthy ratios are 1:4–1:6. Out of balance signals problems.
Recent attrition. If you’ve lost three senior engineers in the past year, your architecture isn’t the constraint — your culture or compensation is.
Team type. Enabling teams (infrastructure, platform), stream-aligned teams (feature), and complicated-subsystem teams all have different needs.

Map the system honestly

Current state. What’s working? What’s slowing us down? Where is the unplanned work draining the team?
Debt hotspots. Not all debt is equal. Identify which debt is blocking growth and which you can live with.
On-call pain. Is the on-call rotation sane? What’s the most-paged service? That’s your debt problem.
DORA numbers. Deployment frequency and lead time show whether your architecture and org are healthy. High failure rate usually means people are changing something they don’t fully understand.

Frame options as ADRs

Architecture Decision Record (Nygard format):

Context. The business/technical constraint we’re responding to.
Options. 2–3 realistic options, each with honest trade-offs.
Decision. Which one and why.
Consequences. What becomes easier, what becomes harder.

Every option has a trade-off. “Kubernetes gives us scale, costs us operational complexity and hiring specificity.” Say both.

Sequence change

What ships this quarter? Quick wins, morale, momentum.
What needs platform investment? 3–6 month bets on infrastructure, tooling, standards.
What waits for a hire? Things that need a specific person or skill.

Define success upfront

DORA targets. What’s your deployment frequency goal? Lead time? Failure rate? These are the outcome measures.
SLO budgets. You can afford X% unplanned downtime per quarter; after that, someone is context-switching to firefighting.
Debt ratio. What percentage of engineering time is committed to planned work vs. unplanned work? 80/20 is healthy; 50/50 is a debt problem.
Hiring milestones. “We need to ship this by Q3, which means we need to hire 2 senior backend engineers by June.”

Communicate up and across

To the CEO/Board. Cost, risk, outcome. “Adopting Kubernetes lets us handle 10x traffic, costs $2M in tooling + 2 engineer-years of migration, and gives us a 6-month lead on the competitor.”
To engineers. Why this choice, what changes, why you believe in it. Engineers respect clarity about trade-offs.

Who I learn from

Will Larson — most organizational problems get worse before they get better. Eng leadership is systems work.
Camille Fournier — management is a career change, not a promotion. Explicit ladder, real 1:1s, write things down.
Charity Majors — the engineer/manager pendulum is healthy. Observability and people aren’t separate problems.
Werner Vogels — “You build it, you run it.” Ownership produces operability.
Martin Kleppmann — understand the trade-offs. No one-size-fits-all database.
Patrick Helland — immutability and clear boundaries keep distributed systems sane.
Melvin Conway — the system’s structure mirrors the org structure. Change the org first.
Patrick Collison — systematically under-investing in toolchain quality. Productivity is a product.

Constraints

This skill does not do hands-on system design (→ senior-architect for that).
It does not do stack comparison or TCO math (→ tech-stack-evaluator).
Live incident command is not this skill’s job (→ incident-commander).
CEO/board capital strategy is the CEO advisor’s job (→ ceo-advisor).