A field guide for the technical leaders nobody warned about the transition. Twenty-five years of building, scaling, and selling technology companies, distilled into the practical playbook I wish someone had handed me about a decade ago.
The title carries a weight no job description can quite capture. Three letters that turn a technical expert into something else entirely: part architect, part therapist, part prophet, part firefighter. If you've recently stepped into the role, or you've been thrust into technical leadership regardless of what your title actually says, you already know the vertigo.
Most CTO advice is written for people running engineering organisations of hundreds. This book is written for the much more common case: the first or second technical leader at a small or mid-size company, where you can't hide behind specialised teams or process, where the CEO's 10pm phone call about a furious customer lands directly on you, and where the board's question about engineering velocity needs an answer that satisfies both their business concerns and your team's technical reality at the same time.
"The path from senior engineer to CTO is not a promotion - it's a career change."
Structured around the situations you'll genuinely face in the first eighteen months, with patterns and anti-patterns drawn from real engagements at real companies under real constraints.
How to lead developers who are deeper in their domain than you'll ever be, whilst keeping the technical credibility that earned you the job.
A working framework for technical decisions when reversal cost is high, the data is incomplete, and waiting for clarity isn't an option you can afford.
Your real job when production is melting down, sales has promised the impossible, and the board wants answers. The buffer that lets brilliant engineers do brilliant engineering.
The delicate art of managing the board, the executive team, and the engineers in the same meeting without losing anyone's trust.
Holding a team together through a pivot you privately disagree with, rebuilding trust after a deployment that genuinely wasn't your team's fault, and the conversations nobody teaches you to have.
Balancing technical excellence with business pragmatism without losing your engineering soul. Knowing when good enough is the right answer and when it absolutely isn't.
"Your job isn't to join the panic but to absorb the pressure, translate the chaos into clarity, and create the space for your team to actually solve problems. You become the buffer that allows brilliant engineers to do brilliant engineering."
You stepped into the role recently, the title still feels slightly ill-fitting, and you'd like a field guide written by someone who's already made the costly mistakes.
You run engineering at a scale that doesn't yet justify a separate VPE and CTO. The book is written for exactly this overlap.
You're trying to understand why the engineering team that used to move fast now feels like it's wading through treacle. The leverage you need is rarely more code.
I'll be sharing some of the strongest material from the book on Notes as it gets close to publication. Pattern pieces, anti-patterns, and the field-tested takes that don't need the rest of the book to stand on their own.
Browse Notes