Published about 2 hours ago 41 min read

👨‍💻 The CTO Playbook 📘: From Best Builder to Best Bet - Part 1 ♟️

MayFest2026

A deep, opinionated, practical guide for the engineer-leader who has just been handed (or is about to be handed) the entire engineering organization. The mental models, decision frameworks, hiring tactics, board interactions, and anti-patterns that separate the CTO whose company outlearns the market from the one whose company stalls. Grounded in 2026 reality — AI-leveraged engineers, smaller teams per dollar of revenue, distributed-async by default, post-ZIRP cost discipline, and a regulatory surface that didn't exist five years ago.

If you read only one section first, read §2 Mindset, §4 The CTO/CEO Partnership, §7 Org Design, and §16 The Operating Cadence. Everything else is the implementation of those four.

Companion to 🧑‍💻 The Tech Lead Playbook: From Best IC to Multiplier 🚀 (the level below — read it first if you skipped the TL years), 🚀 The SaaS Template Playbook 📖 (how to build), 🤖 The AI SaaS Playbook (Practical Edition)📘 (AI overlay), 🦸 The Solo-Founder Playbook: Zero Hero 🚀 (the founder context), and 🏗️ Building High-Quality AI Agents 🤖 — A Comprehensive, Actionable Field Guide 📚 (agentic systems). This one is for the technical leader of an engineering organization of 10–250 engineers at a startup, a scale-up, or a fast division inside a larger company.

📋 Table of Contents

⚡ Read This First
🧠 The CTO Mindset
🎭 The Five CTO Archetypes
🤝 The CTO/CEO Partnership
🚪 The First 90 Days
🧭 Setting Technical Strategy
🏗️ Org Design
👑 The Leadership Team
🧑‍🔬 Hiring at Scale
📈 Performance, Comp & Calibration
🏛️ Architecture at Org Scale
🤖 The AI Strategy (2026)
🛡️ Security, Compliance & Risk
💰 Budget, Cost & Vendor Management
🏢 Stakeholders: Product, GTM, Legal, Finance, People
⏱️ The Operating Cadence
🔥 Incidents & Crisis at Exec Level
🏦 The Board & Investors
💬 Communication at the CTO Level
🧬 M&A, Acquihires & Integration
⚠️ The CTO Anti-Pattern Catalog
🗺️ The Phased Roadmap (Day 1 → Year 5)
🚪 When to Leave, When to Stay
📋 Cheat Sheet & Resources

1. ⚡ Read This First

Seven truths that will save you the first 18 months of mistakes every new CTO makes:

Your job is not engineering. Your job is the engineering organization. The distinction sounds pedantic until you feel it: every hour you spend in a PR is an hour not spent on the architecture review that will shape three quarters, the comp calibration that will keep your best engineer, or the CEO 1:1 that will decide your next $5M of spend. You're paid for judgment, not throughput. The tech-lead reflex ("I'll just write this part") is the #1 reason promoted-from-within CTOs underperform in the first year.
You report to a person who doesn't fully understand you. Your CEO is fluent in customers, capital, and narrative. They are not fluent in distributed systems, hiring loops, or why "we just need to refactor X" takes a quarter. Your most important translation skill is rendering technical reality into business consequence — and back. If you can't, the CEO will fill the vacuum with their own (often wrong) intuition, and you'll end up shipping their guesses.
Org design is your highest-leverage tool. Code can be rewritten in a week. Org structure takes 6 months to change and 18 months to feel the impact. Conway's Law isn't a saying; it's gravity. The shape of your org becomes the shape of your product. Most CTOs touch this once a year when they should touch it every quarter.
You are now a hiring company, not a building company. Your output is the team that ships, not the thing that ships. By the time you have 30 engineers, who you hire and how you level them matters more than any single technical decision you'll make. Most CTOs who fail at scale fail at the hiring funnel — too slow, too soft, too narrow.
The boring stuff compounds. Quarterly business reviews. Weekly written updates. Comp calibration twice a year. Security review on every new vendor. Tech debt registry. A CTO who runs the operating rhythm without flair will out-deliver the visionary one in 24 months. Predictable is the strategy.
You will be invisible to the team for stretches, and that is correct. The board update you're polishing, the comp band you're defending with the CEO, the M&A diligence call, the unhappy customer the VPE pulled you into — these are all real work the team will never see. Resist the temptation to manufacture visibility (over-posting, over-meeting, over-explaining). Trust that your team feels the outcomes of your work even when they don't see the work.
Writing is the operating system of your job. Strategy memos, architecture briefs, board updates, hiring rubrics, decision records, post-mortems, all-hands narratives. If your writing is mediocre, every other lever you have is dampened. The CTOs who scale fastest are the ones whose writing is so clear that the team can act on it without needing a meeting. Ship that skill before you ship anything else.

The rest is implementation of these seven.

Who this is for

You were just made CTO (founding or hired) of a company with ~10–250 engineers.
You're a VPE who functionally runs engineering and want a deeper frame.
You're a senior director or staff engineer being pulled into the CTO seat.
You're a founding engineer at a Series A/B startup whose CEO has started introducing you as CTO and you want to know what that actually means.

Who this is not for

You run engineering at a 1000+ person org with 4 layers of management below you. That's a chief-engineering-officer-of-a-public-company playbook — different game (M&A weekly, regulators in the room, public communications). Pieces here apply, but at that scale your operating model is custom.
You want to be a "thought leader CTO" who tweets and never ships. This playbook is for the CTO who still owns delivery, technical strategy, hiring, and the 3am call.
You're a solo founder. Read solo_founder_playbook.md first. The CTO playbook becomes relevant around your fifth hire.

A note on context

The default voice assumes a product/SaaS company at Series A through C, ~30–80 engineers, 2026 reality (AI-augmented coding, distributed/hybrid, weekly shipping, growing compliance surface). Big-co divisional CTOs should read everything but expect 3× the political and process surface area; deep-tech, hardware, biotech, and regulated-industry CTOs should adapt the cadence and risk frames but the people and strategy sections still hold.

2. 🧠 The CTO Mindset

The mindset shift from tech lead to CTO is harder than the shift from senior to lead. As a TL, your team was your output. As a CTO, the org is your output — and the org includes people you've never met, decisions you'll never see, and second-order effects that won't show up for two quarters.

2.1 Identity reframe: from "best builder" to "best bet"

You used to be measured by what you (or your team) shipped. Now you are measured by what the engineering organization is capable of, six months from now, given the bets you make today. That measurement window stretches further than feels natural — quarters, sometimes years. This breaks five TL/IC instincts you must consciously rewire:

Old TL/IC instinct	New CTO instinct
"I'll review this design doc closely"	"Who owns the bar for design docs across the org? Are they doing the job?"
"Let me jump in on this incident"	"Is the incident commander doing it well? What does the postmortem need to surface?"
"I'll write this hiring rubric"	"Who owns hiring quality? When did I last calibrate them?"
"I'll fix this team's process"	"What about the system produced this team's bad process? Fix that."
"I'll meet this candidate as a courtesy"	"Why am I in this loop? Either I'm the closer or I'm wasting their time."

Practical: write a one-line role description and pin it to your monitor. "I am the CTO of Company X. My job is the technical capacity of this company over the next 18 months — strategy, organization, talent, architecture, risk." If you can't articulate this, your leadership team can't either, and they will silently drift into running their own definitions of your job.

2.2 The five hats — and how they fight

You wear five hats simultaneously and they actively interfere:

Hat	Mode	Time horizon	Output
Strategist	Abstract, business-aware, narrative	Quarters–years	Strategy memos, roadmap framing, build/buy calls
Architect	Deep, system-level, opinionated	Weeks–quarters	Architecture reviews, ADRs, platform direction
Operator	Tactical, fast, decisive	Days	Unblocks, escalations, comp decisions, vendor calls
Recruiter	Salesman + judge, high-empathy	Continuous	Hiring loops, leadership hires, retention conversations
Steward	Patient, calm, present	Continuous	1:1s with leaders, all-hands, postmortem culture

Each demands a different brain state. A 90-minute strategy memo and a heated comp calibration call cannot share the same hour. Batch by hat, not by topic. See §16 for the cadence.

The most common failure mode: defaulting to Architect or Operator mode whenever the Strategist hat feels uncomfortable. Strategy work is ambiguous, lonely, and rarely produces same-day dopamine. So you escape into a design review. Six quarters later you wonder why your company has great systems and a vague mission. Calendar discipline beats willpower.

2.3 The four voices

Every CTO has four internal voices. They lie in different ways. Notice them.

The Hero Voice — "I'll just fix it myself, I'm still the best engineer here." Lies upward — turns a CTO into the org's most expensive bottleneck. Especially common in promoted-from-within and founding CTOs who built v1.
The Imposter Voice — "They hired/promoted me by mistake. The other CTOs at this stage know more." Lies downward — talks you out of necessary calls (the painful reorg, the leadership hire, the strategy bet) and produces a CTO who manages by consensus and ships nothing.
The Empire Voice — "More headcount. More platforms. More direct reports. More scope." Lies sideways — confuses the size of your kingdom with your value. This is how engineering orgs balloon to 200 people delivering what 80 should.
The Steward Voice — "What does this company need to be technically capable of in 18 months? What does this leader need to grow? What signal am I missing?" Lies the least. Cultivate this one.

When the Hero, Imposter, or Empire voice is driving a decision, write the decision down and revisit in 24 hours. Most regretted CTO decisions happen in the 24 hours after a board meeting, a Sev-0, or a difficult resignation.

2.4 The leverage hierarchy

Rank your time by leverage. Always work top-down:

CEO partnership and strategy. 1 hour here = 1000 hours of org work pointed correctly. Highest leverage. Always.
Org design and leadership hiring. Who reports to you, what they own, how the org is shaped. 100× compounding.
Talent calibration & retention. Who's growing, who's at risk, who's quietly the best engineer no one talks about. Catch them before the resignation.
Technical strategy & architecture. The 3–5 bets that define the next 12 months. Fewer is better.
Operating system. Cadence, metrics, written rituals. Boring, compounding, irreplaceable.
External-facing work. Board, investors, customers, recruiting, conferences. Strategic, slow-burn.
Incident & escalation work. Necessary but reactive. Don't let it consume your week.
Reviewing. PRs, design docs, hiring panels. Useful in moderation. Stop being on the critical path for any of it.
Building. Your own code. Lowest-leverage of the nine. Do only what literally only you can do — usually nothing.

When you feel busy but useless, you've inverted the stack. Reset by asking: "In the last 5 working hours, how much did I spend on items 1–4?" If the answer is "<2," that's the problem.

2.5 Reversible vs irreversible decisions

Bezos's two-way / one-way doors framing matters even more for a CTO than for a TL — the irreversibility costs are bigger. Examples calibrated to the CTO seat:

Two-way doors (reversible): which CI provider, which monitoring vendor for now, sprint format, performance review template, whether to run a hackathon. Decide fast, reverse if wrong, do not run a six-week strategy process for these.
One-way doors (hard or expensive to reverse): hiring or firing a VPE, choice of cloud provider, public API shape, primary database, identity provider, leveling system, comp bands, equity refresh policy, the company's stance on remote, M&A. Slow down. Write it up. Get input. Get expert review. Sleep on it. Document why.

A specific failure mode of new CTOs: under-deliberating one-way doors because they're scared of the call, then over-deliberating two-way doors to feel productive. Audit yourself: of your last 10 important decisions, how many were one-way? If <2, you're avoiding the structural calls. If >5, you're stuck in big calls and starving the rhythm.

2.6 The compounding loop (CTO edition)

Your company's only sustainable advantage is compounding. You can't out-headcount the bigger competitor. You compound:

Hiring brand & pipeline. Every great hire who recommends a friend, every clean rejection that respects a candidate, every alumnus who praises you — compounds. A bad year of recruiting takes three good years to recover from.
Written knowledge. Every ADR, every postmortem, every direction doc reduces the cost of the next decision and the cost of every onboarding. A 5-year-old well-organized repo of decisions is worth more than a current consultant.
Architectural integrity. Every clean boundary today saves a quarter of refactor in two years. Every shortcut compounds the other way; the company you cofounded with one shortcut now has 40 derived from it.
Trust with the CEO and exec team. Every accurate forecast, every "told you so we hit it," every pre-emptive bad-news heads-up. CTOs lose their seat at the table by surprising their CEO, not by missing dates.
Customer & domain knowledge. Every customer call, every NPS read, every win/loss review makes the next strategy bet sharper. A CTO who never talks to customers is making decisions in the dark.
Operational simplicity. Every dead meeting killed, every approval workflow trimmed, every vendor consolidated. Compounds for years.

Anything that doesn't compound is rented: tribal knowledge in one engineer's head, undocumented vendor contracts, "that's how we've always hired." Convert rented to owned, weekly. The CTO who treats compounding as an explicit OKR ships through downturns; the one who runs on heroics doesn't.

2.7 The honest reality

Things you'll feel that the LinkedIn version of CTO never mentions:

You will be wrong in public, often. Forecasts will miss. Bets won't pan out. A senior leader hire will quit at month 4. The team will see it. Recovering with grace and learning is part of the job; pretending you weren't wrong is the fastest way to lose the team.
Loneliness. Your reports vent to you. Your CEO vents to you. You have nowhere to vent. Find a peer-CTO group (small, trusted, NDA-quiet) early. Pay for a coach if your company doesn't. Non-negotiable.
The dopamine drop. As a TL you shipped weekly. As a CTO, your "ships" are quarterly at best. The reward signal is different: a calm team, a predictable forecast, a leader you grew, a board that trusts you. Learn to read those as wins, or you'll burn out chasing IC dopamine in a job that doesn't provide it.
The "should I just go back to building?" temptation. Around month 9, when org politics get heavy and a leader you trusted leaves, you'll romanticize being a staff engineer or going back to founding from scratch. Sit with it. The CTO skill compounds; the temptation passes; if it doesn't pass after two quarters, that's data, not a flaw.
You'll be the bad guy sometimes. The headcount cut. The performance call. The shutdown of someone's pet project. The denied raise. The unpopular reorg. Doing the right thing is occasionally unpopular. Lonely + correct beats popular + wrong for the company you're stewarding. But take it seriously — popular + wrong is rarely the whole story; popular often correlates with morale, retention, and execution. Don't romanticize being the heel.
The team rarely thanks you for what you don't do. The reorg you didn't run. The vendor migration you said no to. The hire you didn't make. The exec request you killed politely. These are most of your real work and they are nearly invisible.

3. 🎭 The Five CTO Archetypes

There is no single "CTO." There are five distinct roles people call CTO, and they reward radically different behaviors. The single most expensive mistake a CEO and a CTO can make together is hiring or growing into the wrong archetype. Know which one you are; know which one your company actually needs.

3.1 The archetype grid

Archetype	Stage	Engineers	Primary work	Career risk
Founding CTO	0 → Series A	1–15	Build v1, hire first 10, set the stack and culture	Stuck in IC; can't scale past 20 engs
Hands-on Lead CTO	Series A → B	10–40	First leadership hires, first real platform calls, first compliance push	Burning out; not delegating; not leveling up
Org-Building CTO	Series B → D	40–150	Leadership team, comp bands, multi-team strategy, hiring brand	Becomes a manager-of-managers and loses tech credibility
Strategic CTO	Late stage / scale	150–500+	Strategy, M&A, talent ecosystem, board, big bets	Coasts; out-of-touch with code; dependent on lieutenants
Divisional CTO	Big-co	100–1000s	One product line inside a larger company; political	Rendered redundant by reorg; squeezed between exec layers

A sixth, increasingly common now: the Fractional CTO — works across 2–4 early-stage companies, advises on architecture, hiring, vendor selection, and security posture. Different game, not in scope for this playbook.

3.2 Founding CTO: the hardest archetype

You built v1. You hired engineers 1 through 8. You wrote half the production code that's now keeping the lights on. You are the technical co-founder.

Your hardest transition is that the skills that built the company are not the skills that scale it. Specifically:

The deep IC focus that produced v1 must be relinquished by ~10 engineers, or you become the company's bottleneck.
The "anyone can do anyone's work" early culture must give way to formal ownership by ~15 engineers, or chaos sets in.
The "I'll handle hiring myself" reflex must die by ~20 engineers, or hiring quality cratters.
Your stack choices — beautiful for a founder pair — may not fit a 50-person org.

Founding CTOs fail in two ways. Type 1: refuse to scale, stay deep IC, and around the Series B mark a "VP Engineering" gets hired over them and they end up sidelined as "Chief Architect" in name only. Type 2: try to scale, but never honestly admit that org-building isn't their natural skill, and they hire a poor leadership team.

If you're a founding CTO reading this:

Be ruthlessly honest with your CEO about what kind of CTO you want to be. Some founders are happiest as the deep technical conscience of the company (an inside-the-company "Chief Architect") and that's a valid, valuable choice — but say it explicitly so the CEO can hire a VPE alongside.
Schedule a peer-CTO conversation every month with a CTO 1–2 stages ahead of you. The pattern recognition you can't get from books.
Draw a line in your calendar for IC time and protect it brutally — but make that line shrink quarter over quarter until ~10% by your second year as CTO of a 30+ person team. Founding CTOs who flatline at 50% IC are headed for a hard landing.

3.3 Hired CTO: the trust gauntlet

Joining as CTO from the outside, with the team already shaped by someone else, is the highest-difficulty version of the CTO entry. Day 1, the team is watching for:

Are they going to rip out our stack?
Are they going to fire my favorite leader?
Do they actually understand what we built and why?
Do they get along with the CEO, or will we lose them in 6 months?

The hired CTO who survives the first 90 days follows three rules:

Listen before changing. Even more strictly than a TL — see §5. Public changes in week 2 buy 3–6 weeks of resentment per change.
Identify the one person whose technical credibility holds the team together. Often a staff or principal IC, sometimes a director. Win them in week 2. Lose them and you're starting from -10.
Learn the company's customer before judging the engineering org. Most "what is this team thinking?" reactions dissolve once you understand the customer, the historical constraints, and the prior trade-offs. Engineering looks dumb until you know the context.

3.4 The CEO/CTO compatibility matrix

The fit between you and the CEO matters more than your individual capability. The dimensions to assess (yourself and them):

Dimension	CEO	You
Comm style	High-bandwidth verbal vs written-async	?
Risk appetite	Bet-the-company vs predictable	?
Tech depth	Coded recently vs never coded	?
Domain depth	Deep customer vs deep technology	?
Time horizon	12-week sprints vs 5-year vision	?
Conflict style	Direct fight-it-out vs avoid-and-resolve-async	?
Trust starting point	Defaulted high vs earned over time	?

Two adjacent points on most of these is healthy. Three or more polar opposites is a friction tax that most CTO/CEO pairs don't survive past 18 months. Talk about this explicitly with your CEO in your first 30 days. Don't be polite. Be specific.

3.5 What the CEO actually wants from a CTO (and what you'll hear instead)

The unstated job description, decoded:

What CEO says	What CEO actually wants
"I want a strong technical leader."	"I want someone I can stop worrying about. Someone who handles engineering so I can spend my brain on customers, capital, narrative."
"We need to ship faster."	"I want predictability. I want to commit dates to customers, investors, and the board, and have those dates be true."
"We have tech debt."	"Customers complain that things are slow/buggy/late, and I don't know if it's hard problems or bad execution."
"We need a vision for AI."	"Investors keep asking, customers keep asking, and I don't know what to say. Help me say it credibly."
"Your team has a culture problem."	"I'm hearing third-hand that morale is off. I trust you to find out and fix it; please don't make me."
"Hiring is too slow."	"Headcount plan says +12. We're at +3. The board notices."

Read what the CEO is actually trying to solve. Almost none of it is technical. Most CTO failures start with the CTO solving the literal problem the CEO stated, and missing the underlying anxiety.

3.6 Common archetype mismatches

Founding CTO trying to be a Strategic CTO at Series A. Too soon. You'll be 6 months out from the code and the team will lose trust.
Hired Strategic CTO at Series A. Too senior. They'll wait for the leadership team to materialize while the team needs someone in the trenches.
Hands-on Lead CTO at Series C. Too junior. They're great at unblocking three teams but can't run a 100-person org or sit on a board call.
Org-Building CTO at a 10-person company. Their playbook doesn't fit. They'll over-process a small team to death.

Talk about the archetype in your CEO 1:1 every quarter. The right one shifts as the company grows; you either grow with it or you hand over.

4. 🤝 The CTO/CEO Partnership

If §2 is the most important section for you, this is the most important section for the company. Most CTO failures are not engineering failures. They are CTO/CEO partnership failures. A great pair makes a mediocre strategy work; a broken pair turns a great strategy into mush.

4.1 The first principle: one voice, two heads

Externally — to the team, to investors, to customers, to candidates — you and the CEO speak with one voice. Internally, in private, you fight it out as hard as needed. The reverse — internal silence, external disagreement — is corrosive.

A practical rule: the CEO never finds out about an engineering risk from anyone but you. If your VPE messages the CEO with a Sev-0 first, you have failed. Your job is to be the CEO's first call on everything technical.

4.2 The weekly 1:1 — protect it like infrastructure

You should have a 60-minute, never-cancel weekly 1:1 with your CEO. Not 30 minutes. Not "biweekly when we're busy." Sixty, weekly, recurring, untouchable except for genuine emergencies.

Default agenda (split as needed):

5 min — temperature. What's on each other's mind, unstructured.
15 min — engineering forecast. What's going to ship this week, this month, this quarter. Status of the 3–5 bets. Risks the CEO needs to know about before the board hears about them.
15 min — talent. Hires in flight, leaders who are wobbling, comp/promo decisions, anyone you might lose, anyone the CEO might lose. (Yes, you should know about non-engineering hires too.)
15 min — strategy & decisions. The 1–2 calls where you need the CEO's view, or you need their air cover for a call you've already made.
5 min — feedback both ways. Even small. Especially small. Annual feedback that surprises either of you = a year of weekly 1:1s mis-spent.
5 min — what's next. Confirm what you each owe the other before next week.

If the meeting routinely ends in <30 minutes, you're under-using it. If it routinely runs past 60 with chaos, your prep is too thin.

4.3 Bringing bad news

The single skill that determines whether you keep the CEO's trust over years.

The format that works:

HEADS UP — <one-sentence summary>

What happened: <2–4 sentences, no spin>
Customer/business impact: <specific>
What I'm doing: <action and owner>
What I need from you: <specific ask, or "nothing right now">
Next update: <day/time>

Five rules:

Bring it early. Better to retract "we may miss the date" than to surprise with "we missed."
Bring options, not just problems. "We can A (slip 2 weeks, ship full), B (cut feature X, ship on time), or C (add 1 contractor, ship on time, $30K)."
Own it. Even if it's a leader's miss two layers down, in this room it's yours. The CEO doesn't care about your org chart in a crisis.
No drama. Calm tone. Precise language. If you panic, the CEO panics, and now there are two panicking people.
Follow up. When you said next update was Friday at 4pm, send it Friday at 3:55pm. Trust is built in keeping these tiny appointments.

4.4 Managing up: what the CEO needs from you weekly

A CEO with five direct reports is overloaded. Make their life easier with three artifacts:

A 5-minute Monday written update. What shipped, what's at risk, what you need. (Format in §19.)
A 1-page weekly engineering scorecard. Same numbers every week. Velocity, on-call load, hiring pipeline, security posture, top 3 risks. The consistency is the value — they internalize the pattern.
Your draft of any board engineering content ≥10 days before the board meeting, so the CEO can edit before you join.

The CEO who never has to chase you for status is the CEO who defends you in the boardroom.

4.5 The CEO 1:1 anti-patterns

The Status Theater 1:1. You report status the CEO already saw in Slack. Wasted hour.
The Therapy 1:1. You vent about your team for 50 minutes. The CEO is not your therapist, and now they know your team is in trouble. Get a peer or a coach.
The Demo 1:1. You walk through a feature instead of discussing strategy. Demos belong in product reviews; the CEO 1:1 is for decisions and risks.
The "everything is fine" 1:1. Suspicious. Either you're not seeing problems, or you're hiding them. Both are dangerous.
The "every other week we cancel" 1:1. You're not in the loop. You'll find out about decisions after they're made.

4.6 When the CEO is the problem

A genuinely difficult section. Sometimes the CEO is the bottleneck — slow to decide, changes direction monthly, undercuts your authority with the team, makes promises to customers that engineering cannot keep, won't fund what's needed.

Tactics, in order:

Name it explicitly in 1:1. Specifically, with examples. "In the last 6 weeks, the roadmap has changed 4 times based on different customer calls. The team is losing focus. I need a steadier roadmap or I can't commit dates."
Ask what's driving it. Often the CEO is responding to investor pressure, runway anxiety, or a customer they can't lose. Once you know the why, you can design a process that works.
Propose a structure. A weekly customer-feedback intake meeting. A monthly roadmap-change ritual. A "no commitments to customers without engineering signoff" rule. Make their incoming-anxiety route through a process, not through your team.
If 1–3 fail, talk to a board member. Once. Carefully. As a what should I do conversation, not a fire the CEO conversation. Most board members will quietly nudge.
If 1–4 fail, decide whether to leave. A bad CEO/CTO fit is a 3-year career stall at minimum. Better to leave at month 12 with goodwill than at month 30 burned out. See §23.

This sequence rarely runs all the way. Most CEO/CTO friction resolves at step 1 if the CTO has the courage to name it.

5. 🚪 The First 90 Days

Treat this like a structured plan, not vibes. The first 90 days set the pattern for the next two to three years. Everything you do in week 2 sends a signal you'll spend a quarter walking back if it was wrong.

5.1 Days 1–14: Listen, don't change

The most damaging mistake a new CTO (especially a hired one) makes is changing things in week 1 to look decisive. You don't have the context. Six weeks in, you'll undo half of it.

Goals for the first two weeks:

Meet every direct report and every senior IC in 45-min 1:1s. Stock questions in §5.5.
Read everything written in the last 6 months. Strategy memos, postmortems, design docs, board decks, the company's last all-hands recording. Aim for the bottom of the pile by day 10.
Sit (silently) on every recurring meeting: exec staff, eng leadership, sprint demos, all-hands, customer calls. You're auditing the rhythm.
Talk to 5+ customers. Yes, you. Not your CSMs. Customers will tell you things engineering won't.
Talk to your peer execs: CEO obviously, CPO/Head of Product, Head of Sales, Head of CS, CFO, CHRO/Head of People, GC/Head of Legal. Each is a distinct relationship. (See §15.)
Shadow on-call for one full cycle (or have a senior leader walk you through the last 3 months of incidents).
Read all postmortems going back 6 months. The cluster of root causes tells you what the org is bad at.
Do not announce a strategy. Do not reorganize. Do not fire anyone. Do not mandate a new tool.

Output by day 14: a private state-of-the-org note. Sections: leadership team (strengths/risks/bench), tech (what works, what's risky, what's rotten), delivery (cadence, predictability, debt, on-call burden), talent (who you'd be panicked to lose, who's a non-fit, where the bench is thin), GTM/customer reality, CEO and exec-team dynamics, your own gaps, open questions. This doc is private — for you and a coach if you have one. Update monthly for the first year.

5.2 Days 15–45: Diagnose & quick wins

By day 14 you've earned permission to act, but only narrowly.

Pick 2–3 unambiguous, visible improvements that don't require buy-in. Examples: kill a meeting nobody wanted, fund the missing observability project the team's been asking for, fix the alert that pages the team at 3am, sign off the headcount the VPE has been waiting on.
Run a written engineering survey — anonymous, ~10 questions. "What's broken? What's working? What would you change if you were CTO for a day? What do you wish I'd ask?" Treat the results as input, not verdict.
Identify your 1–3 inherited bets that are most clearly right and most clearly wrong. Quietly accelerate the right ones; quietly de-prioritize the wrong ones (don't kill yet — that comes later).
Draft a 90-day operating cadence. Even before the team accepts it formally, you operate by it. Show by example. (See §16.)
Start writing the weekly written update (see §19), even if no one asks. Especially if no one asks. By week 4 it's a habit; by week 12 it's a load-bearing artifact.

Quick wins build social capital you'll spend in the harder calls of days 46–90.

5.3 Days 46–90: Set direction & make the first hard call

Now the harder work begins.

Publish a 1-year technical strategy. 3–5 pages. (Format in §6.) Get input first; commit second. The team has spent the last 6 weeks watching whether you'd come in and impose, or come in and listen. The strategy doc is where they see if it was worth the wait.
Make 1 visibly hard call. New CTOs who avoid hard calls in the first 90 days lose moral authority for the rest of their tenure. Examples: kill a project two leaders have been protecting, change the on-call structure, bring in a director-level hire over an internal favorite, pause the rewrite, run a small RIF to fix a hiring mistake you inherited, replace a vendor everyone agrees is bad but no one had the political capital to swap. Pick one and do it well. The team is watching; the calibration matters more than the specific call.
Establish your operating cadence formally. §16. Weekly leadership team, weekly written update, weekly 1:1s, biweekly architecture review, monthly metrics review, quarterly business review.
Calibrate with the CEO. Day-90 retro 1:1: "Here's what I see, here's what I'm doing, here's what I need from you, here's what I think you need from me that you're not getting." Schedule it on day 60. Don't skip it because everything feels fine — that's exactly when it's most worth doing.

Output by day 90: a written strategy, a known cadence, 2–3 visible improvements, 1 hard call landed, your CEO aligned on what success looks like for the next 6 months, a private state-of-the-org note that's now richer than it was on day 14. Don't try to ship more than this. Ambitious 90-day plans are how new CTOs burn out their team in their first quarter.

5.4 Day 90 → Day 180

The middle 90 days are where most new CTOs stall. The "honeymoon" is over, the easy wins are spent, the harder problems remain. Three priorities:

Hire your one critical missing leader. Almost every new CTO finds a gap on the leadership team within 60 days. Run that hire as your highest priority for days 90–180. (See §8.4.)
Land the strategy with the team. It's not enough to publish; you have to land it. All-hands, leadership offsite, written FAQ, repeated talking points, 1:1 reinforcement. By day 180 every IC should be able to recite the 3 bets in plain English.
Run your first quarterly business review. End of Q1 in seat. The format you use here will define how the org communicates upward for years. Get it right. (See §16.4.)

5.5 Stock questions for first-week 1:1s

When you sit down with a leader or senior engineer in your first two weeks, ask:

"What's the most important thing I should understand about this company that I won't learn from the docs?"
"What's working that I should protect?"
"What's broken that you'd fix if you were me?"
"Who on this team is great that nobody outside this team knows?"
"Who would you panic about if they quit?"
"What's a decision you're hoping a new CTO will make?"
"What's a decision you're afraid a new CTO will make?"
"What did the last person in my seat do well?"
"What did the last person in my seat do badly?"
"If I could only do one thing in my first quarter, what would you want it to be?"
"What questions am I not asking that I should be?"

Take notes during, not after. Compile into your state-of-the-org doc. The patterns across 15 conversations are diagnostic gold.

6. 🧭 Setting Technical Strategy

The job most new CTOs dodge for too long. "We don't really have a technical strategy, we just ship the roadmap." Saying that should make you uncomfortable. A company without a technical strategy makes every decision from scratch, optimizes locally, drifts toward path-dependent legacy, and burns out engineers who can't see what they're working toward.

6.1 Strategy ≠ roadmap ≠ direction

Three artifacts, often confused:

Roadmap is what we'll ship and when — owned with Product. 6–12 month horizon. Granular at the next 2 quarters, fuzzy beyond.
Direction is what each team is for and how it operates — owned by tech leads and EMs. Quarterly horizon.
Strategy is what the company will technically be capable of in 18 months and what we'll bet on (and bet against) to get there — owned by you, the CTO. 12–24 month horizon.

When the CEO says "we need a technical strategy," they almost always mean strategy in this third sense, even if they say roadmap. Don't confuse the artifact.

6.2 What strategy actually answers

A technical strategy is a 3–6 page memo that answers six questions, in writing, with conviction:

What is the company trying to win? One paragraph in plain business language. "We want to be the system of record for X by 2028."
What technical capabilities do we need to win? 3–7 capabilities, in plain English. "Sub-second query at 100M rows per tenant. Compliance-ready audit trail. AI-native workflow on top of our data."
Where are we today vs where we need to be? Honest gap analysis, capability by capability.
What are the 3–5 bets we're making? Specific. Each bet has a thesis (why we believe it), a cost (people, time, money), an alternative (what we considered and rejected), and a kill criterion (when we'd stop).
What are we explicitly not betting on? The 5–10 things that look reasonable but we're saying no to. This is the most powerful section in the document.
How will we know it's working? 3–6 metrics. Lagging (revenue, retention) and leading (deploy frequency, time-to-onboard new engineer, P95 latency). Reviewed quarterly.

Length: 3–6 pages. Anything longer is a strategy book and won't be read. Anything shorter is a slogan.

6.3 The "fewer, bigger, better" rule

The single most common strategy failure: too many bets. A 5-person team can carry 1 strategic bet plus the roadmap. A 30-person team can carry 3. A 100-person team can carry 5. More bets do not equal more progress; they equal less progress everywhere.

When you see a CTO with a 12-bet strategy, you're seeing a CTO who couldn't say no to anyone. The team will execute none of them well.

6.4 The "not doing" list as a weapon

Every quarter, publish 5–10 things the company is not doing technically. Examples (sanitized from real strategies):

"We are not building an in-house ML platform. We use vendor X. Reconsider Q4 2027."
"We are not migrating to microservices. Our majestic monolith ships faster. Reconsider when team >120."
"We are not adopting Kubernetes for our app workloads. Cloud Run / Fly / equivalent is sufficient."
"We are not building a mobile app this year. Mobile web is good enough. Reconsider when retention plateau is mobile-driven."
"We are not writing our own auth. We use vendor Y. We will not reconsider; this is decided."
"We are not pursuing on-premise deployment, even if a customer asks. We're SaaS-only through 2027."

Each "not" sentence saves you 3 conversations a quarter. The list is the most under-used artifact in CTO leadership.

6.5 How to write the strategy doc

The process matters as much as the artifact:

Write a v0.1 alone, in a long weekend. 3 pages. Be opinionated. Mark every section "DRAFT."
Share with 3 trusted reviewers. Ideally: your CEO, your strongest VPE/director, your sharpest principal engineer. Get raw feedback. Listen, don't defend.
Talk to customers and adjacent execs. What does GTM need from engineering in 18 months? What's the CFO's runway picture? What's the CPO's product thesis? Their inputs reshape your bets.
Rewrite as v0.2. Share more widely — your full leadership team. Run a 90-min review of the not-doing list (the most contentious section).
Rewrite as v1.0. Publish to the engineering org. Present at all-hands.
Anything you didn't change despite objection — explain why in writing in the doc. ("Considered alt: X. Decided against because Y.")
Revisit every quarter. Rewrite every year. The doc is a living artifact, dated, versioned in the repo.

Buy-in comes from being heard, not from getting your way. Most engineers will accept a strategy they disagree with if they see their concern addressed in writing.

6.6 Tying strategy to capability building

A strategy without a capability map is a wish list. For each bet, you must know:

Which team(s) will execute it? And how is their current load?
Who is the technical owner? A named principal or staff. Not a team. A person.
What capability gap will it leave or open? ("This bet means we can no longer also do X.")
What hiring or training does it require? Often the bottleneck.
What infra/platform investment does it require? Often hidden.
What will it cost in dollars (vendor + headcount + opportunity)?

If you can't answer these for each bet, the strategy is a vision statement, not a strategy. Vision statements lose the team's trust faster than no strategy at all.

6.7 The 3 horizons (CTO scale)

A useful frame to keep strategy healthy at company scale:

Horizon 1 (now → 1 quarter): keep the lights on, ship the committed roadmap, ship the quarter's reliability/security/quality investments. ~70% of capacity.
Horizon 2 (1–4 quarters): the 3–5 bets — the real strategy. ~20–25% of capacity. This is where most companies starve themselves.
Horizon 3 (4+ quarters): exploration, prototypes, foundational learning. ~5–10% of capacity. Don't promise outcomes; promise reports.

Most companies accidentally allocate 95% to H1 and complain that engineering "never invests in the future." Some flip and starve H1, missing every quarter and breaking the trust that funds H2. The CTO's job is to defend the split publicly and audit it monthly.

6.8 Strategy in a downturn / runway crunch

A current reality. Many CTOs are running engineering in cost-conscious mode. A strategy under runway pressure:

The H1/H2/H3 split shifts to ~85/10/5. This is okay; survive first.
Cut bets, not bet quality. 3 well-resourced bets > 5 starved bets > 1 bet (because then a single failure is fatal).
Vendor consolidation, not stack upheaval. Trim 3 vendors this quarter; don't migrate clouds.
Hiring freeze ≠ hiring stop. Backfill churn. Hire 1–2 critical leaders. Defend that with the CEO/CFO.
Don't let the team feel like they're just defending. Even in a freeze, a small "lighthouse" project that lets engineers do something they're proud of preserves morale and retention.

The CTO who navigates a downturn well is set up to scale fast on the upturn. The one who panics-cuts wastes a year.

6.9 How strategy connects to product strategy

A specific dysfunction worth naming: in many companies, the CPO/Head of Product owns "what we ship" and the CTO owns "how we ship it," and there is no shared owner of "what the company will be technically capable of." That gap kills companies.

Fix: a written product/tech strategy (one document, two co-authors). The CPO writes the customer/market half; you write the capability/technical half. The CEO ratifies. One artifact. Same numbers. Same bets. Co-presented at the board. Co-presented at the all-hands.

If your CPO won't co-write, that's a relationship problem to fix in §15.1.

7. 🏗️ Org Design

Conway's Law: the systems any organization designs reflect its communication structure. It's not a rule of thumb. It's gravity. The shape of your engineering org becomes the shape of your software, your bugs, your dependencies, your hiring needs, your bottlenecks. Org design is the highest-leverage tool you have.

7.1 The four team types (Team Topologies, simplified)

The Skelton/Pais frame, applied:

Team type	Mission	Owns	Examples
Stream-aligned	Ship customer value end-to-end	A product area or vertical	"Billing team", "Onboarding team", "Reporting team"
Platform	Reduce cognitive load for stream teams	Internal services others build on	"DevEx", "Data platform", "Infra/Cloud"
Enabling	Help other teams adopt new capabilities	Time-bounded skill transfer	"AI enablement squad", "Security champions"
Complicated subsystem	Deep technical specialty	A subsystem most engineers don't touch	"Search team", "Pricing engine", "Video pipeline"

Most healthy product orgs are mostly stream-aligned (60–70%), with one or two platform teams, occasional enabling squads, and a handful of complicated subsystems. A common dysfunction: 50% platform teams in a 30-engineer company. The platform layer eats the team and the customer features starve.

7.2 The team sizing rules

Below 5 engineers per team is fine for early stage but starts to feel fragile at 25+ engineers (single-person dependency on every team).
5–8 is the sweet spot. Tight enough to share context, big enough to absorb a vacation.
9+ engineers is a smell. Communication overhead grows quadratically. Either split or admit you have two teams pretending to be one.
>2 teams reporting to one EM is a smell (unless they're explicitly small or seasonal).

When a team grows past 9, the question isn't whether to split but along what axis. The split must follow a customer-meaningful boundary, not an internal-political one. (See §7.6.)

7.3 The growth thresholds — when org structure must change

Memorize these. They will all hit you.

Engineers	What changes
5	First "team" — one CTO/lead, all ICs
10	First leadership hire (TL or EM); first written strategy needed
20	Multiple teams; need a director-or-equivalent layer; comp bands; first formal ladder
40	Need VPE or equivalent; CTO can no longer 1:1 every IC; first dedicated platform investment
80	Sub-orgs (groups); first time CTO has 2nd-level reports; recruiting team is full-time; security and compliance need a real owner
150	Multiple groups; principal/staff IC track must be real; engineering ops/PMO function emerges; CTO becomes mostly strategy + hiring + exec
300+	Divisions; dotted-line matrix; M&A integrations; CTO is primarily an executive

Most CTOs are 1–2 thresholds late on every transition, because the previous org "still works" right up until it suddenly doesn't (usually mid-quarter, mid-customer-launch). Anticipate. Hire ahead. Restructure ahead.

7.4 Platform vs product — the perennial fight

The single most common org-design dysfunction is the platform/product imbalance.

Platform too thin:

Every product team rebuilds the same auth/observability/deploy infra.
Tech debt compounds horizontally — 7 teams making 7 incompatible decisions.
Senior ICs spend 30% of their time fighting infra.

Platform too thick:

Customer features starve while platform teams build internal abstractions nobody asked for.
Stream teams resent the "ivory tower" platform.
Product velocity drops; CEO blames engineering.

The right ratio at most stages:

Engineers	Platform %	Product %	Notes
5–15	0%	100%	Don't build a platform; use vendors
15–40	10–20%	80–90%	First DevEx/infra team of 2–3
40–100	20–25%	75–80%	Distinct platform group
100–300	25–35%	65–75%	Mature platform layer

If your platform is >30% of headcount and product velocity is declining, you have an over-built platform. If platform is <10% at >50 engineers, you have a debt bomb.

7.5 Centralized vs federated specialties

Where do specialists (security, data, ML, infra, QA) live?

Three patterns:

Federated (champions in every team). Cheap, but quality varies wildly.
Centralized (a dedicated team). High quality, but creates queues and "us vs them."
Hub-and-spoke. A small central team sets standards and tools; embedded specialists live in product teams. Most expensive but highest quality.

The right pattern depends on the maturity and risk profile of the specialty:

Specialty	<40 engs	40–100	100+
Security	1 part-time owner	Centralized team of 2–3	Hub-and-spoke
Data / Analytics eng	Federated	Centralized of 2–3	Hub-and-spoke
ML / AI	Federated	Centralized	Hub-and-spoke
QA / Test eng	Federated	Federated + tooling team	Federated, central tooling
Site reliability	Shared on-call rotation	Small dedicated SRE team	Embedded SRE

The transition from federated → centralized is one of the most painful org changes you'll run; the team doing the work in their spare time will resent the new specialists; the new specialists will be confused why nothing works the way it should. Plan a 6-month transition with a written charter.

7.6 Reorgs — the most expensive lever

A reorg is a bullet you fire roughly once a year, sometimes twice in heavy growth, never more. It costs the team 4–8 weeks of disruption and 1–2 quarters of velocity decay even when done well.

Run a reorg when:

Multiple teams routinely block each other on the same code paths.
You can name a customer-meaningful capability that has no clear team owner.
A team has grown past 9 and is functionally two teams.
A leader has 2× their healthy span (10+ direct reports).
A merger/acquisition forces it.
Strategy has fundamentally shifted (rare; once a year at most).

Do not run a reorg when:

A specific person is underperforming. Fix the person, not the org.
A team has personality conflicts. Reorg won't fix interpersonal issues.
You're new and want to put your stamp. This is the most common bad reason.
The board is pressuring you to "look decisive."

The reorg playbook (one page):

1. Write the rationale (1 page) — what's broken, why this fixes it, what we expect.
2. Pre-socialize with affected leaders 1:1 (no surprises in public).
3. Announce in person/all-hands, then in writing same day.
4. Effective date 2 weeks out — gives reporting changes time to settle.
5. Each affected leader writes their team's new charter within 14 days.
6. 30-day check-in: how is it actually working?
7. 90-day retro: what we got right, what we got wrong, what we'll adjust.

The reorg that's announced on a Friday afternoon, effective Monday, with no written rationale and no follow-up — corrosive to trust for years. Do it well or don't do it.

7.7 Spans of control

A standard frame:

Manager type	Healthy span	Stretch span	Broken span
EM of a single team	5–7 directs	8	9+
Director (mgr of mgrs)	4–6 EMs	7	8+
VPE	4–7 directors	8	9+
CTO at <50 engs	All-of-engineering, but with leads	—	More than 8 directs
CTO at 50–200	5–8 directs (VPE, directors, principals)	9	10+

When a manager's span exceeds healthy, quality of management collapses gradually: 1:1s get skipped, performance issues miss, hiring loops degrade. By the time it's visibly broken, you've already lost a quarter.

Audit spans every quarter. Hire or restructure ahead of breakage.

7.8 The IC career track

If you don't have a real principal/staff IC track at >50 engineers, your best engineers will leave or you'll force them into management they don't want. The IC track must be:

Real in title and compensation. Principal IC = director-equivalent comp. Distinguished/Fellow IC = VPE-equivalent.
Backed by promotion criteria. A written ladder. (See §10.)
Visible. Principal ICs presenting at all-hands, leading architecture reviews, mentoring named protégés.
Defended. When a senior IC tries to "move into management for the comp," you sit them down and explain that the IC track has parity, and don't let them.

Companies with a strong IC track retain senior talent for years. Companies without lose senior ICs to bigger companies that have one — every 18–24 months, on a cycle.

8. 👑 The Leadership Team

You are only as good as the leaders directly below you. Most CTO failures are 60% leadership-team failures. The hardest, highest-ROI work you'll do is hiring, growing, and (occasionally) replacing your direct reports.

8.1 The shape of a CTO's leadership team

By stage:

Engineers	Direct reports	Key roles
10–25	2–4	1–2 EMs/Tech Leads, maybe a security or data lead
25–60	4–6	VPE or 3–5 EMs, head of platform/infra, head of security/IT, principal IC(s)
60–150	5–7	VPE, directors of major orgs (platform, product groups), head of security, head of DevEx, principal/distinguished ICs
150–300+	6–9	VPE, multiple group directors, CISO, head of data, head of ML, chief architect, ops/PMO lead

The single most common configuration mistake: skipping the VPE hire. A CTO who keeps direct-reporting 8 EMs at 70 engineers is drowning in operational detail and starving strategy. Hire the VPE.

8.2 CTO + VPE: how the split works

The most important pairing in your leadership team. A bad CTO/VPE split breaks faster than a bad CEO/CTO split.

The default split that works:

Domain	CTO	VPE
Technical strategy	✅ Owns	Inputs
Architecture standards	✅ Final call	Operationalizes
External tech narrative (board, customers, hiring)	✅ Owns	Supports
Hiring strategy	Sets bar	✅ Owns funnel
Performance & comp calibration	Approves	✅ Owns
Delivery / roadmap execution	Inputs	✅ Owns
Engineering operations & cadence	Approves	✅ Owns
Vendor & cost management	Approves big	✅ Owns daily
Security and compliance posture	✅ Accountable	Operationalizes
Major incidents	Available; takes external	✅ Internal commander

Both names on the strategy. One name on the execution. You're playing chair-and-COO at the engineering level.

The CTO/VPE conversations to have in the first month after hiring or promoting them:

Who decides architecture when we disagree? (Default: you, but defer when you're not deep in the area.)
Who fires? (Default: VPE, with you informed.)
Who promotes? (Default: VPE owns the process, you ratify the principal+ levels.)
Who's the exec face for engineering at company all-hands? (Default: alternate.)
When the CEO comes to one of us, when do we loop in the other? (Default: always, within 24h.)
How do we handle disagreement publicly? (Default: never disagree publicly. Fight in private; align in public.)
What does each of us not do that the other expects us to? (The most-skipped question; the most useful.)

Write the answers down. Re-read every quarter. Misaligned CTO/VPE pairs are the #1 cause of leadership-team thrash in scale-ups.

8.3 Building bench

Your leadership team should have 2 successors named for every key role, including yours. Not formally announced — privately known, intentionally developed. By the time you need a backfill, the bench is 6 months too late to build.

Tactics:

Each leader runs a stretch project a level above their current scope every year.
Skip-level 1:1s with senior ICs every 6 weeks: who's emerging?
A formal "bench review" with your VPE and head of People every quarter.
Defended learning time — rotations, conferences, internal mobility.

8.4 Hiring leaders (the hardest hires you'll make)

A bad leadership hire damages an org for 18+ months — they hire below their own bar, their team underperforms, the team's best people leave, and you spend a quarter cleaning up before you can rehire. No hire is more expensive to get wrong.

The leadership hire loop, default:

Recruiter screen — fit, comp, motivation.
CTO 1:1 (60 min) — values, technical depth, leadership philosophy. You, not a delegate.
CEO 1:1 (45 min) — fit with exec team, business sense.
Peer exec panel (CPO, CFO, head of People; ~30 min each).
Leadership case study (90 min) — present a written case to a panel, e.g. "This is our team, this is our roadmap, what would you do in your first 90 days?"
Backchannel references (you, personally, ≥3 calls) — not just the references they provided. Find someone they managed and someone who managed them.
Final closer call with you. Walk through their offer; ask what would make them most successful here.

Critical: don't skip backchannel references on leadership hires. Half the regretted leadership hires showed up in references that the candidate didn't hand you — but that you could have found with three calls.

What you're hiring for, in order:

Judgment. Can they make hard calls with incomplete information? Demonstrated, not claimed.
Hiring & growing people. Their best report from their last role — where are they now?
Fit with you specifically. Will the partnership work? You'll be in 1:1s every week.
Technical depth. Enough to keep credibility; not necessarily deep in your stack.
Cultural addition (not "fit" — you want someone who adds, not blends).

8.5 Letting a leader go

The most painful CTO conversation. By the time you know you need to do it, you've already waited too long. Average CTO regret on leader transitions: 4–6 months too late.

Signs it's time:

Their team is consistently underperforming, and it's pattern not phase.
Their best people are quitting or transferring out.
Cross-functional partners (PM, sales, CS) avoid them.
They surprise you with bad news (or worse: surprise the CEO).
You're spending >25% of your CTO time on their team's problems.
They've been told the gap clearly and it hasn't moved in 6 months.

The transition, played well:

You write the case with examples, dates, prior feedback. Loop your VPE/People partner.
One conversation, in person if possible. No email, no Slack.
Generous package. They were a leader. Treat them as one on the way out, even if frustration says otherwise.
Communicate to the team within 24 hours. Short, dignified, no spin. Don't over-explain; don't pretend.
Cover their team for 1–2 weeks personally if no obvious successor. Then run a deliberate transition.
Reflect honestly. What did you miss? What signals were there 6 months earlier? Most leadership-fire decisions reveal a hiring gap. Update your hiring loop.

The team will respect a fair, well-handled leader transition. They will lose respect quickly for a transition that's mishandled — public surprise, unclear comms, no follow-up. Most CTOs underweight the visibility of how they handle these calls.

8.6 The "principal IC" as a leadership-team member

In any org >50 engineers, your principal/distinguished ICs are leadership team members in everything except headcount. Treat them that way:

They attend leadership meetings (the technical strategy ones, not the people ones).
They have a seat in architecture review and the not-doing list discussion.
Their performance and comp is calibrated by you and the VPE, not by an EM two levels down.
They're paired with managers on cross-cutting initiatives (not subordinated to them).

A principal IC who feels like "just another senior" is a principal IC who'll leave in 12 months. A principal IC who feels like a peer of your directors will stay for years and do the technical work nobody else can.

(...to be continued...) Read Part 2 here https://viblo.asia/p/the-cto-playbook-from-best-builder-to-best-bet-part-2-pPLkN3wDJRZ

This playbook is a living document. The 2026 reality (AI-augmented engineering, distributed-async, post-ZIRP cost discipline, the rising bar on technical writing, regulatory complexity, model-vendor dynamics) keeps shifting. Update yours. Argue with mine. Ship the company that makes the next CTO playbook unnecessary.

If you found this helpful, let me know by leaving a 👍 or a comment!, or if you think this post could help someone, feel free to share it! Thank you very much! 😃

Android iOS JavaScript ReactJS