Preface

A confession to begin with, because it should change how you read everything that follows.

Much of the raw material behind this book was produced with the help of large language models. As I worked, my role came to feel less like that of an author and more like that of a film director: I developed the core ideas, ran and re-ran the research, curated the references, and then directed, edited, and judged draft after draft until the words said what three decades of building software organisations had taught me they should. I did not type every sentence. I shaped every one.

I put that up front for two reasons. The first is plain honesty. The second is that the admission is itself part of the argument. This book is about leading innovation through a stretch of history when the ground under software engineering will not hold still, and the most immediate tremor — the one already changing how our teams work this year — is the shift from telling machines how to do something to telling them what we want and judging the result. I have been living that shift while making the very thing you are holding.

Where this comes from

For the better part of a decade I worked at the seam between engineering and corporate innovation — as an Engineering Director and then as a Partner and Vice President of Engineering at BCG Digital Ventures, now BCG X. In that time I helped build more than twenty-five new ventures: some standalone businesses, some internal bets, many of them new digital products created from nothing under real commercial pressure. Leading the engineering for those efforts gave me a front-row view of what actually works and what only sounds good from a stage — and, more to the point, of how you build the people, processes, and technology that let an organisation keep inventing when conditions refuse to settle.

This book distils what I took from that. It is not a memoir, and it is not a survey of the literature. It is a working leader's account of how to lead innovation when "business as usual" is already broken.

Who it is for

I have written it for the people who carry the weight of delivery and the weight of change at the same time: engineering managers, directors, VPs of engineering, CTOs, and the senior engineers who lead without the title. If you are responsible for a team that has to keep shipping while the technology, the market, and the workforce all move under you, this is for you.

Every idea here earned its place by passing one test: would a software-engineering leader act or think differently because of it? The material this book draws on once sprawled across climate science, biotechnology, corporate finance, and government foresight. Most of that is gone. What remains is what changes a decision you will actually make — how you fund a bet, govern an autonomous team, review an agent's output, or read a weak signal before your competitors do.

What it is, and is not

This is not a recipe book. Recipes are for complicated problems: problems with a knowable structure, where following the steps reliably produces the cake. The problems in this book are complex — their parts interact, the ground shifts while you work, and the same move yields different results depending on when and where you make it. Complex problems have no recipes, only better and worse ways of thinking about them. So my aim is not to hand you a process. It is to sharpen how you think — to leave you with a small set of mental models, durable enough to use under pressure, for leading innovation in the world we actually inhabit rather than the stable one our methods quietly assume.

That world is being reshaped by five forces at once: political and regulatory whiplash, the AI-driven move from imperative to declarative work, ecological limits, the convergence of maturing technologies, and a rewired workforce. I call them changequakes, and the first chapter is about taking them seriously as a set. Artificial intelligence runs all through this book, but it does not rule it. The arrival of capable agents is the most pressing of the five and earns a part of its own; it is not the lens the other four must be read through. A book that bent every chapter toward AI would make the exact error the first chapter warns against — mistaking one tremor for the whole earthquake.

How to read it

The book moves in four parts. The first asks why the operating models most of us inherited fail in these conditions, and names the one that replaces them: perpetual beta. The second looks hard at the most immediate change — the shift to declarative, agentic work — because that is where the pressure is greatest today. The third is the heart of it: the leadership disciplines that make perpetual beta real — governing autonomy, treating culture as infrastructure, running an adaptive process, funding like a portfolio, seeing what is coming, and designing an organisation that can absorb change. The fourth turns all of it into a plan you can run, and is honest about the ways it tends to fail.

A last word on the experiment behind the book. The constraint that nearly kept these ideas unwritten was never quality; it was time. A working leader rarely has the uninterrupted months it takes to turn hard-won experience into something others can use, and so most of that experience is never written down at all. The tools changed that arithmetic for me. I am convinced their highest use is not replacement. It is letting us express and share what only experience can teach. Whether that conviction holds up, you can decide for yourself — you are holding the result.