What It Takes

Most guidance for technical leaders is written for software companies. This book is written for the more awkward world of connected products, where electronics, firmware, cloud, field service and commercial consequence sit in the same system, and a technical decision made early can come back months later as a warranty bill, a service burden or a safety question.

Its argument is that leading technology well takes fluency at several levels at once: the role itself, the technical foundation, product to market, strategy and money, AI, and the person carrying the work. Most of the expensive failures I have seen began where one of those levels had been left to chance.

Who it is for

• Technical leaders who want a map of the full role: what it demands, where most people are strong, and where the gaps tend to be expensive.
• Founders and boards who need to hire, assess or support a CTO when they cannot judge technical depth directly.
• Investors and lenders who want to know what the technology behind a plan is really worth before money moves.

What is in it

The book is in six parts, each covering one of the levels.

1. The role. What the CTO job requires and what it does not, which of three quite different jobs a company actually needs, and how to tell whether a candidate can do it.
2. The technical foundation. Reliable embedded systems, where technical debt becomes expensive, metrics that hide a failing product, and what a CTO should be hearing from the rest of the business.
3. Product to market. What the market actually needs, how much product strategy a young company needs, what launch really costs, and the EU Cyber Resilience Act that now follows every connected product for its whole life.
4. Strategy and money. Diagnosing a company without a strategy, competing when a larger rival fights on price, forecasting honestly, and what a lender’s technology review looks for.
5. The AI shift. What earlier hype cycles teach about this one, why coding agents need experienced engineers, and why a system built by agents needs written rules before it needs code.
6. The leader. Ego and its cost, a pace you can keep, resilience as a practical skill, and what downsizing does to the people who stay.

Each chapter ends with a few things worth taking seriously, for boards, founders, CTOs and the people developing them.

Read a sample

The preface is below. Two complete chapters are free to read:

• Chapter 1. What it takes to be an outstanding CTO
• From Part 4. What a lender’s technology review actually looks at

When it is out

What It Takes is coming soon. Follow my writing and I will let you know when it is published.

Preface

This book began as a set of essays. I wrote them over several years to make sense of patterns I kept meeting: the same mistakes in different companies, the same arguments between engineering and the rest of the business, the same surprise when a decision taken early turned out to be expensive late. I published them on my website as I went.

Read together, the essays turned out to be making one argument rather than many. That argument is what this book sets out: leading technology well takes fluency at several levels at once, and most of the expensive failures begin where one of those levels has been left to chance. Turning essays into a book meant more than collecting them. Chapters have been merged, cut and rewritten, the repetition that suits a website has been taken out, and each chapter but the last now ends with a few things worth taking seriously.

A word about the stories. Most of my working life has been spent inside other people’s companies, often under confidentiality, and I have kept to that. Clients are not named. Where I describe a company, I have left out the details that would identify it, and where an example draws on more than one situation, or is illustrative, I say so. The lessons are real; the names are missing on purpose.

The same care applies to claims of fact. Where the book relies on law, standards or published research, the sources are listed at the back. Where it relies on my own experience, it says so, and I have tried to state each conclusion with the confidence it has earned and no more. Regulation in particular moves quickly, and nothing here replaces advice on a specific product.

Finally, a word about where I stand. I am not offering my own ability to build systems; that is not what this book is about. What I bring is having watched technology decisions play out across many kinds of business and several waves of technology, and the habit of questioning what everyone in the room has assumed. If the book does its job, it will leave you asking a few of those questions of your own organisation.

Catherine Ives-Yim CEng
Leeds, October 2026