Practical guide for CTOs and heads of engineering: the role itself, org design, hiring, technical strategy, money, due diligence, and the reporting an executive owes the rest of the company.
If I were taking a CTO role today, which decisions would I want made deliberately in the first quarter instead of by accident in the third year?
This playbook is about:
- the four different jobs that all get called "CTO";
- org shape, span of control, and when a team needs a manager;
- hiring that scales past the founders' network;
- ladders, compensation bands, and performance conversations that hold up;
- technical strategy, build versus buy, and debt as a budget line;
- cloud spend, vendors, and the numbers finance will ask about;
- security posture, due diligence, and surviving an investor's technical review;
- what to report to a CEO and a board, and how often.
- CTO Playbook
- Table of Contents
- Why this exists
- Companion playbooks
- The defaults I'd reach for first
- Which CTO the company actually needs
- The first 90 days
- Org design without org theatre
- Hiring at scale
- Ladders, levels, and compensation
- Performance, promotion, and exits
- Technical strategy and build versus buy
- Technical debt as a budget line
- AI in the engineering organization
- Money: cloud spend, budgets, and vendors
- Security, privacy, and compliance posture
- Technical due diligence and fundraising
- Metrics an executive should watch
- Talking to the CEO, the board, and everyone else
- Artifacts worth templating
- Things I would avoid
- Worth reading
- License
Most CTO advice is either war stories from one company or a link dump with no opinion attached.
Neither helps at the moment the job actually gets hard: when the thing being asked for is not a better system, but a decision about people, money, or risk, made with incomplete information and a deadline.
This playbook covers the part of the job that is not engineering:
- deciding what kind of technical executive this company needs right now;
- shaping an organization that keeps working after it doubles;
- spending money defensibly and explaining it to people who do not read code;
- carrying technical risk into rooms where nobody else can see it.
The Engineering Lead Playbook covers the craft one level down — architecture judgment, RFCs, review, mentoring. This one starts where that ends.
These repositories form one playbook suite:
- AI-Assisted Engineering Playbook — agent workflows, guardrails, and quality control for AI-heavy teams
- API Design Playbook — versioning, pagination, idempotency, error contracts, and webhooks
- Auth & Identity Playbook — sessions, tokens, OAuth, and identity boundaries across the stack
- Backend Architecture Playbook — APIs, boundaries, OpenAPI, persistence, and errors
- Best of JavaScript — curated JS/TS tooling and stack defaults
- Caching Playbook — HTTP, CDN, and application caches; consistency and invalidation
- Code Review Playbook — PR quality, ownership, and review culture
- CTO Playbook — org design, hiring, technical strategy, budgets, and due diligence
- DevOps Delivery Playbook — CI/CD, environments, rollout safety, and observability
- Engineering Lead Playbook — standards, RFCs, and technical leadership habits
- Frontend Architecture Playbook — React structure, performance, and consuming API contracts
- Git Collaboration Playbook — branching, stacked PRs, merge queues, and CI collaboration at scale
- Marketing and SEO Playbook — growth, SEO, experimentation, and marketing surfaces
- Messaging & Async Playbook — queues, events, outbox, idempotent consumers, and retries
- Monorepo Architecture Playbook — workspaces, package boundaries, and shared code at scale
- Node.js Runtime & Performance Playbook — event loop, streams, memory, and production Node performance
- Observability Playbook — logs, traces, metrics, SLOs, and production visibility
- React Cross-Platform Playbook — shared React UI and logic across web and native with TypeScript
- Software Design Playbook — separation of concerns, composition, and module boundaries
- State Management Playbook — client state architecture, MobX, and choosing a state layer
- Styling Architecture Playbook — type-safe styling, design tokens, and theming at scale
- Sysadmin Operations Playbook — servers, backups, DNS, TLS, identity, and the self-hosted ops stack
- Testing Strategy Playbook — unit, integration, contract, E2E, and CI-friendly test layers
If I were setting up a technical executive's operating model today, I would default to this:
- Role definition written down and agreed with the CEO before the title is used
- Org shape that follows the product's boundaries, not the current headcount accident
- Hiring with a fixed loop, a written bar, and a scorecard per interviewer
- Ladder published to the whole team, including what each level is expected to own
- Compensation in bands, reviewed on a fixed cadence, never negotiated ad hoc
- Build versus buy biased toward buy unless the thing is the product
- Technical debt carried as a standing percentage of capacity, not as a heroic quarter
- Security with a written floor, an owner, and an annual external test
- Metrics reported as system health, never as individual performance
- Board reporting on a fixed cadence with the same four charts every time
Consistency beats brilliance here. Most of the damage a technical executive does is caused by changing the answer every quarter.
"CTO" is four different jobs wearing the same title. Picking the wrong one is the most expensive mistake in this document.
- Founding builder — writes most of the code, owns every decision, works at a company of 1 to 10. Real job: get to a product that exists.
- Team lead — hires the first ten engineers, sets the first standards, still ships. Real job: make the company able to build without them in the room.
- Executive — runs managers, owns budget and headcount, sits in the leadership team. Real job: translate business strategy into an organization that can execute it.
- External-facing technologist — architecture at the highest level, standards bodies, key customers, acquisitions, sometimes no direct reports at all. Real job: technical credibility outward.
These do not automatically follow one another. A great founding builder is not owed the executive job, and forcing that transition has ended more founder relationships than any technical disagreement.
The uncomfortable version of this conversation is the healthy one. Have it with the CEO early, in writing, and revisit it at every stage change.
A useful split when the company can afford both:
- CTO — where technology is going, technical bets, external credibility, architecture direction.
- VP Engineering — how the organization runs: hiring, delivery, process, managers, predictability.
One person can hold both up to roughly 30 to 50 engineers. Past that, one of the two halves is being neglected, and it is almost always the one the person enjoys less.
If you are still the best engineer in the room at 60 people, that is not a compliment. It means nobody senior enough to replace you was hired.
The temptation is to arrive with a reorganization. Resist it for a quarter.
- one-on-one with every engineer if the team is under 30, every manager and a sample if larger;
- read the last six months of incidents, postmortems, and abandoned projects;
- ship something small yourself — a real change through the real pipeline tells you more about the org than any deck;
- sit in on a sprint planning, a code review, and a customer call;
- ask every person the same two questions: what is slowing you down, and what would you change if you could change one thing.
Patterns repeated by five unrelated people are facts. Patterns mentioned once are opinions.
Some things do not need 90 days of study:
- No on-call rotation, or a rotation of one person. Fix immediately; that is a resignation waiting for a bad week.
- No way to roll back a deploy. Fix immediately — see the DevOps Delivery Playbook.
- Secrets in the repository. Rotate, then fix the process that allowed it.
- No backups, or backups never restored. An untested backup is a rumor.
- A single person who is the only one who can deploy, restore, or explain billing. That is key-person risk, and it is the first thing an acquirer will find.
Everything else can wait until you understand why it is the way it is.
An org chart is a communication structure. Whatever shape it has, the software will eventually match it — so choose the shape you want the architecture to have.
That is Conway's law, and its history is a useful thing to have ready. Melvin Conway published it in 1967 in Datamation, after Harvard Business Review rejected the paper for lacking proof; it got its name from Fred Brooks citing it in The Mythical Man-Month. Conway's own framing was stronger than the version usually quoted: the constraint is not that organizations tend to produce matching designs, but that they are unable to produce any other kind, because the design has to be negotiated through whatever communication paths exist.
Read that way it stops being an observation and becomes a lever. If two teams cannot get a clean interface between their systems, examine the meeting structure before the architecture diagram.
- Small, durable teams that own a product area end to end, including its on-call. Ownership without operational responsibility produces systems nobody maintains.
- Long-lived teams over project-based reshuffles. Context is expensive to rebuild; a team that has owned a system for two years is worth several that have owned it for two months.
- Explicit interfaces between teams, in the same sense as software interfaces: a documented API, a clear contract, and a support expectation. The contract mechanics live in the API Design Playbook.
- A cap on how many teams any one person coordinates. Cross-team dependency count is a better complexity metric than headcount.
Reorganizations are expensive and mostly invisible to customers. Do them when the product boundaries genuinely moved, not when the quarter went badly.
- five to eight direct reports is the sustainable range for a hands-on manager;
- past eight, one-on-ones become status meetings and growth conversations stop happening;
- below four, the manager will start doing the team's work, which is worse than it sounds;
- promoting the strongest engineer by default costs you a strong engineer and often produces a weak manager — ask whether they want the job, not whether they have earned it.
Management is a career change, not a promotion. Make the reverse move available and non-shameful, or nobody will risk the first one.
Internal platform teams are worth their cost once roughly 30 to 50 engineers are duplicating the same infrastructure work — and by 2025 that pattern is close to universal: most organizations report some internal platform capability, and a majority have a dedicated team for it.
Two rules keep it from becoming a bottleneck:
- the platform is a product, and the other teams are its customers — adoption is voluntary and measured;
- if teams route around the platform, the platform is wrong, not the teams.
A platform nobody chose to adopt is a tax with a friendly name.
The founders' network gets the first ten. Nothing after that works without a process.
- A written bar per role, agreed before the first candidate, describing what this person must be able to do alone.
- A fixed loop: screen, technical work sample, system or design discussion, values and collaboration, hiring-manager close. Same stages, same order, every candidate.
- One assessed dimension per interviewer, with a written scorecard submitted before the debrief. Verbal-only debriefs converge on whoever speaks first.
- Work samples over trivia. A realistic scoped problem, time-boxed, ideally close to what the job involves. Whiteboard algorithm puzzles measure interview practice.
- A no is cheap; a bad yes is not. But "no hire" needs a stated reason, or the bar quietly becomes "people like us".
- A candidate experience you would accept yourself. Reply within days, never ghost, pay for anything that takes more than a couple of hours.
Speed is a feature. Good candidates hold multiple offers, and a loop that takes four weeks loses to one that takes one.
- reference checks matter more than interviews, and back-channel references matter more than the ones offered;
- give a real scenario from your actual business and listen to the questions they ask, not the answer they give;
- hire for the company you will be in 18 months, not the one you are in today — but not for the one you might be in five years;
- a mis-hired executive costs a year: their ramp, their damage, their exit, and their replacement's ramp.
- the bar drifts down under headcount pressure and nobody records that it happened;
- interviewers are never trained, calibrated, or told what they are assessing;
- onboarding ends at laptop setup, so month one produces nothing and month three produces doubt;
- the hiring manager is not the person the hire will report to;
- referral-only pipelines that reproduce the existing team and call it culture fit.
A new engineer should ship something real to production in their first week. If they cannot, the problem is your setup, not their ability.
An unwritten ladder is a ladder where promotions look political, because from the outside they are indistinguishable from politics.
- Scope — what this level owns: a task, a feature, a system, a domain, the org.
- Autonomy — how much direction is required and how much ambiguity is expected.
- Impact — who is affected: the team, the product, the company.
- Behavior — how they raise the people around them.
Two rules keep it honest: a promotion recognizes work already being done at the next level, and the individual-contributor track goes as high as the management track. Otherwise everyone with ambition becomes a manager and you lose your best engineers to a job they did not want.
Keep it short. A ladder nobody can hold in their head is a document, not a system.
- bands per level, reviewed on a fixed cadence against market data;
- the same band for the same level regardless of who negotiated hardest;
- promotion and compensation reviewed together, so pay stops drifting from responsibility;
- equity explained properly, in writing, including strike price, vesting, and what happens if the person leaves — most engineers have never had this explained and are entitled to understand what they hold.
Salary secrecy transfers value from the people who do not negotiate to the people who do. Whatever transparency level you choose, be able to defend every number against the band.
- feedback that appears first in a review is a management failure that happened weeks earlier;
- separate the growth conversation from the compensation conversation — nobody hears career advice while waiting for a number;
- calibrate across managers before anything is communicated, or levels will mean different things per team;
- write down what "meeting expectations" looks like at each level, and mean it: most people meeting expectations is a healthy organization, not a problem to fix.
Stack ranking optimizes for internal competition. You will get exactly that.
- say it plainly and early — the person almost always already senses it, and silence removes their chance to fix it;
- write down what needs to change, by when, and what happens otherwise;
- support it honestly for the agreed period; a plan designed as paperwork before a decision already made is a lie everyone can see;
- if it does not work, act. A team carrying a known non-performer stops believing the bar exists.
The unfair version is the slow one. Waiting nine months to have a conversation you knew you needed in month two costs them a year of their career, not just yours.
Strategy is not a technology list. It is a small number of bets, written down, with the reasoning attached — so that in a year you can tell whether you were wrong or just unlucky.
For anything that is not your differentiator: buy it, rent it, or use the managed service.
- your auth system is not your product — Auth & Identity Playbook;
- your queue, your database, and your CI are not your product;
- engineering time is the most expensive input you have, and rebuilding a commodity spends it on something a customer will never notice.
The cost of a vendor is visible on an invoice. The cost of the in-house version is spread across years of salaries, which is exactly why it feels cheaper and is not.
- the thing is genuinely core to the product and the differentiator;
- no vendor fits, and the gap is structural rather than cosmetic;
- the vendor's pricing curve breaks at the scale you can actually see arriving — not the scale in the pitch deck;
- lock-in on this specific dependency is an existential risk rather than an inconvenience.
Write the decision down as an ADR, including what would make you reverse it. The template is in the Engineering Lead Playbook.
Outsourcing works for bounded, specified, non-core work with a clear acceptance test. It fails for core product work, because the context that makes product decisions good is exactly what does not transfer.
If you do it:
- own the architecture and the code review in-house;
- require the same standards, CI, and review process as internal work — see the Code Review Playbook;
- plan the handover from day one, including who maintains it afterwards;
- never let an external team be the only group that understands a production system.
Debt is not moral failure. It is borrowed speed, and like any borrowing it is fine until nobody tracks the interest.
Ward Cunningham coined the metaphor in 1992 and spent years afterwards correcting how it got used. His debt was not shipping bad code on purpose — it was shipping code that reflects your current understanding of the problem, knowing the understanding will improve, and committing to come back and align the code with what you learned. Interest is what you pay while the code still encodes the old, wrong model.
The correction matters for how you argue upward. If debt means "we were sloppy", every repayment request is an apology, and apologies do not get funded. If it means "we have learned something the code does not know yet", it is an ordinary investment decision — which is exactly the framing the next section uses.
The version that works: a standing percentage of capacity — commonly 10 to 20 percent — permanently allocated, not a heroic quarter that gets cancelled the moment sales needs a feature.
- deliberate debt is a decision, recorded with a repayment plan;
- accidental debt is a learning signal — it means the system was not understood when it was written;
- debt in a system nobody touches is not urgent, whatever the linter says;
- debt on the critical path of the roadmap is the only kind worth an argument with the CEO.
Never as "the code is ugly". Always as delivery consequences:
- "This feature takes three weeks instead of one because of X, and every future feature in this area pays the same tax."
- "Change failure rate in this service is four times the rest of the platform."
- "Two of the last three incidents came from the same system."
Business people do not fund cleanliness. They fund predictability, and that is what debt work actually buys.
By 2025 this stopped being a question of whether and became a question of governance.
DORA's 2025 research puts around 90 percent of developers using AI tools at work, and finds that AI adoption correlates positively with delivery throughput — while also increasing instability. The framing worth carrying: AI amplifies whatever the organization already is. A team with strong tests, small batches, fast rollback, and clear ownership gets faster. A team without them gets faster at producing problems.
The leverage is not in the tool choice. It is in the platform quality, the workflow clarity, and the team boundaries that were already there.
- Which tools are approved, and what data is allowed to reach them — customer data and secrets are the line;
- Review does not get lighter. The author is accountable for generated code exactly as if they typed it;
- Small batches. The measured benefit concentrates in teams that ship small changes, and AI makes large diffs easy to produce;
- Test and rollback investment first. Throughput gains land on top of stability, or they land on the incident channel;
- Cost visibility. Per-seat and per-token spend belongs in the engineering budget with everything else;
- No headcount promises based on projections. Cutting hiring on an assumed multiplier, before measuring it in your own delivery data, is how a plan becomes a retraction.
The operational detail — agent workflows, guardrails, quality control — is in the AI-Assisted Engineering Playbook.
At some point someone from finance asks why infrastructure costs what it does, and a technical executive who cannot answer loses influence over the number.
- People — salaries, benefits, recruiting fees. Typically 70 to 85 percent of the total, which means every other line is a rounding error by comparison.
- Infrastructure — cloud, data, network, storage.
- Tooling — CI, observability, security, AI tools, per-seat licences.
- Contractors and vendors — agencies, specialists, audits.
Know which of these grows with headcount, which grows with usage, and which is flat. Those three curves are the whole conversation.
- Tag everything by team and service, or cost allocation is guesswork forever;
- Show teams their own spend. Nothing reduces cost like the team responsible seeing the number;
- Cost per unit of business value — per customer, per transaction, per tenant — is the metric that survives growth; absolute spend rising while unit cost falls is a healthy company;
- Non-production environments and forgotten storage are where the money quietly goes;
- Commit to reserved capacity only for the baseline you are certain of. A three-year commitment on optimistic growth is a bet, not a saving;
- Egress and cross-region traffic are the lines that surprise people; check them before the invoice does.
Optimize the top three line items. The rest is a hobby.
- align renewals with your fiscal calendar, not theirs;
- always know the switching cost before the renewal call, because they do;
- multi-year discounts are real, and so is being locked to a product that stops improving;
- get the exit terms in writing: data export format, notice period, and what happens to your data afterwards.
Security is an executive responsibility because the tradeoffs are business tradeoffs, and the consequences arrive at the executive level regardless of who wrote the code.
- a named owner — a person, not a committee;
- secrets in a secrets manager, never in a repository, with rotation that actually happens;
- least privilege on production, and access reviews on a schedule;
- dependency scanning and patching in CI, not in a quarterly cleanup — see the DevOps Delivery Playbook;
- an external penetration test at least annually, budgeted in advance;
- an incident response plan that has been rehearsed while nothing was on fire;
- personal data mapped: what you hold, where, for how long, and how it gets deleted.
The design-level detail — sessions, tokens, boundaries — is in the Auth & Identity Playbook.
SOC 2, ISO 27001, HIPAA, and their relatives are not security. They are evidence that controls exist and are followed — which is what an enterprise buyer needs before signing.
- start when the first enterprise deal needs it, not two years early and not the week it is asked for;
- audit readiness is mostly logging, access control, and change management you should have anyway;
- the expensive part is not the audit fee, it is the engineering time to produce evidence continuously — budget for both.
At a funding round or an acquisition, someone competent spends two weeks looking for reasons to lower the price. Everything they find, you could have found first.
- Architecture against the business plan — not "is this modern" but "does this survive three times the load and the roadmap in the deck";
- Delivery evidence — deployment frequency, change failure rate, test coverage, flaky test rate, how long a fix takes to reach production;
- Team and key-person risk — who is irreplaceable, and how long leadership has been in place;
- Security and compliance — open findings, incident history, certifications;
- IP and licensing — who owns the code, contractor agreements, and every open-source licence in the dependency tree;
- Data and AI exposure — what data you hold, what leaves the building, and what a model was trained on;
- Roadmap credibility — whether "in development" comes with what is done, what remains, and what it costs.
Recent transaction audits find open-source components in effectively every deal reviewed, licence conflicts in the overwhelming majority, and known unpatched vulnerabilities nearly as often. None of that is exotic. It is what an unmaintained dependency tree looks like when someone finally reads it.
Two habits make diligence boring, which is the goal:
- keep an architecture overview, a dependency and licence inventory, and an incident log current as a normal practice, not a fire drill;
- fix the key-person dependencies before someone else names them — the founding engineer who is the only person who understands billing is a finding, not a strength.
Never hide a known problem. Diligence teams find them, and a discovered omission reprices the whole deal in a way the original problem never would have.
DORA's four keys remain the most defensible starting point: deployment frequency, lead time for changes, change failure rate, and time to restore service. They answer one question — how safely and quickly does this organization turn a change into value.
If you want a frame that reaches the CFO, the DX Core 4 consolidation of DORA, SPACE, and DevEx measures speed, effectiveness, quality, and impact, deliberately held in tension so that speed cannot be bought with quality.
- voluntary attrition, and specifically regretted attrition;
- time to first meaningful contribution for new hires;
- internal promotion rate versus external senior hires;
- on-call load: pages per rotation, and how many arrived outside working hours;
- developer experience survey results, asked consistently and acted on visibly.
The on-call number is the most honest metric in this list. Nothing else predicts attrition as reliably.
- Trends, never absolutes. Direction across quarters is the signal; a single number is noise with a decimal point.
- Never for individuals. The moment a metric judges a person, people optimize the metric and you lose both the metric and the truth.
- Paired, always. Throughput next to change failure rate, velocity next to on-call load. Any single metric optimized alone gets gamed.
- If it never changes a decision, delete it. A dashboard nobody acts on is decoration.
The instrumentation behind all of this lives in the Observability Playbook.
- no surprises, in either direction — a bad number delivered early is a manageable problem; the same number delivered late is a credibility event;
- translate technical risk into business consequence: revenue, timeline, cost, or reputation;
- disagree in private, commit in public, and be explicit about which mode you are in;
- when you say something will take three months, say what you are assuming — most broken trust between a CEO and a CTO started as an estimate nobody attached conditions to.
Same structure every time, so the board reads deltas instead of relearning the format:
- what shipped against what was committed;
- delivery health: the four keys, trended;
- team: headcount, open roles, attrition, key risks;
- top three technical risks and what is being done about each;
- budget against plan;
- the one decision you need from them, if any.
One page plus an appendix. Boards read the page.
- engineering owns how and when; product owns what and why; both own the tradeoff conversation;
- give ranges with confidence levels rather than single dates, and say what would narrow the range;
- push back with alternatives, never with refusal — "not by then, but here is what fits by then" keeps you in the conversation;
- protect a fixed share of capacity for reliability and debt, agreed once at the leadership level rather than defended every sprint.
Most executive writing goes undone because it feels expensive. A template's job is to make writing cheaper than repeating yourself.
# Engineering — Q<n> <year>
Shipped: what landed, against what was committed
Delivery: deployment frequency, lead time, change failure rate, restore time — trended
Team: headcount, hires, departures, open roles, key-person risks
Risks: top three, each with an owner and a mitigation
Spend: budget against plan, and the largest variance explained
Ask: the one decision needed from leadership
# <capability>
Is this our differentiator? yes / no
Options: vendor A, vendor B, build — cost, time to value, exit cost
Recommendation: which, and why
Reversal trigger: what would make us change this decision
# <date> — <one-line customer-visible description>
Who was affected: which customers, for how long
What happened: two sentences, no jargon
What we did: how it was resolved
What prevents a repeat: the systemic fix, with an owner and a date
If filling the template takes longer than the decision took to make, shrink the template.
- taking the CTO title without agreeing which of the four jobs it means;
- reorganizing in the first month, before understanding why the current shape exists;
- staying the best engineer in the room instead of hiring one;
- building commodity infrastructure because it is more interesting than the product;
- promoting strong engineers into management without asking whether they want it;
- unwritten ladders and ad hoc compensation, then being surprised by attrition;
- promising delivery dates without stating the assumptions underneath them;
- treating security and compliance as a project rather than a standing cost;
- discovering key-person risk during due diligence instead of before it;
- reporting engineering metrics as individual performance;
- deferring the conversation about someone who is not working out;
- cutting hiring plans on an assumed AI productivity multiplier you have not measured in your own data.
- Awesome CTO — the curated link collection this playbook was built against
- The Startup CTO's Handbook — Zach Goldberg, book-length and free
- Your first 90 days as CTO or VP Engineering — Will Larson
- Measuring an engineering organization — Will Larson
- StaffEng — what the senior individual-contributor track actually looks like
- VP Engineering vs CTO — Fred Wilson
- The Engineer/Manager Pendulum — Charity Majors
- Engineering Ladders — a framework you can adapt rather than invent
- Engineering Management — Charlax's collection, deeper on the management half
- GitLab Handbook — the most complete public company handbook
- How HashiCorp Works — a shorter, more opinionated alternative
- Google re:Work — hiring, management, and team effectiveness research
- 2025 State of DevOps Report — DORA on AI-assisted development
- DX Core 4 — DORA, SPACE, and DevEx consolidated
- Comparing developer productivity frameworks — Swarmia, on which framework fits what
- Google SRE Book — SLOs, on-call, and incident practice
- A collection of postmortems — how real systems actually fail
- Technology Due Diligence Checklist — AKF Partners
- Maker's Schedule, Manager's Schedule — Paul Graham
MIT is a sensible default for a repository like this, but choose the license that fits how you want others to reuse the material.