1. Changequakes

Sometime in the early 2020s, a great many carefully made plans stopped working at once.

A pandemic emptied the offices and rewrote, almost overnight, what "the team" even meant. Supply chains everyone had quietly treated as solved buckled, and a semiconductor shortage centred on Taiwan reached into product roadmaps that had nothing to do with hardware. Interest rates lurched, and with them the funding logic of how engineering work gets staffed and sequenced. Then, in late 2022, a single release — ChatGPT — changed what hundreds of millions of people expected software to do, and set off a race that is still rewriting our profession as you read this.¹

None of it arrived politely, one thing at a time. The shocks overlapped, collided, and fed each other. The World Economic Forum reached for a new word in its 2023 Global Risks Report — polycrisis — for a tangle of risks whose combined impact, in its phrase, exceeds the sum of each part; most of the experts it surveyed expected the years ahead to bring compounding rather than subsiding turbulence.² An engineering leader needed no special vocabulary for it. The quarterly plan survived contact with almost none of it, and the most expensive instinct in the building turned out to be the urge to wait for things to get back to normal.

This book starts from one claim about that experience: it was not an unlucky run of weather. It is the climate now. And leading innovation in this climate begins with seeing its disruptions for what they are — not isolated events to ride out, but a particular kind of disruption that demands a particular kind of response. I call them changequakes.

What a changequake is

A changequake is a disruption that is foundational — it shakes the bedrock assumptions a business, a team, or a technology rests on — and that arises from the interaction of several forces at once rather than from a single cause. That second half is what separates it from the disruptions we are all trained to manage. A competitor's better product is a disruption. A new framework is a disruption. A changequake is what happens when shifts in technology, economics, regulation, and human behaviour arrive together and amplify one another until the ground itself moves.

Geological earthquakes come from pressure accumulating along a fault line until it releases all at once; changequakes come from stresses building in complex systems until they reach a breaking point.³ But a changequake is not over in moments. Its aftershocks run for years, and it tends to set off further quakes in a cascade. The 2020 pandemic was not one event; it was a health emergency that became an economic shock that became a supply-chain failure that became the largest forced experiment in remote work in history. Each tremor triggered the next.

For those of us who run engineering organisations, this is not abstract. The same coupling that lets a virus reach into your deployment pipeline is the coupling that lets a model release in one lab reset your team's expectations a quarter later. We have spent two decades making our systems more connected, more automated, and more dependent on a shared substrate of cloud, tooling, and talent. That is precisely the condition under which small triggers produce outsized, cascading effects.

Five characteristics — a working diagnostic

It helps to recognise a changequake while you are standing in one, because it calls for a different response than a passing disruption does. Five characteristics, taken together, are the tell.

• It is multi-domain. At least two of technology, economics, society, and regulation are in upheaval at the same time, interacting. A pure technology shift is just that; a changequake drags policy, talent, and markets along with it.
• Its timing is unpredictable, but its fault line is not. You usually cannot say when the slip will come, but you can often say where the pressure is building. Through the 2010s no one could date the arrival of capable generative AI, yet the fault line — compounding compute, accumulating data, improving models — was visible to anyone willing to look.
• It is non-linear. A small trigger can tip the whole system into a new state, and the effects follow power laws rather than bell curves: a few enormous consequences, not many moderate ones. ChatGPT was, technically, an incremental step on work specialists already knew. Its effect was a phase change.
• It is interactive. Changequakes rarely travel alone, and when they coincide they reinforce one another.
• It cuts both ways. The same forces that obsolete a business model, devalue a skill, or break an institution also open the room for the thing that replaces it. Schumpeter's "creative destruction" is the right frame — accelerated, and running across several domains at once.⁴

Run a disruption through those five. If it lights up most of them, you are not looking at a problem to solve and put behind you. You are looking at a new operating condition.

The five changequakes

Five forces are shaking our world at the same time. None is news on its own; the point is that they are happening together, and that none is slowing down.

Of the five, one is already sitting on most engineering leaders' desks: the move from imperative to declarative work — AI systems you instruct by outcome rather than by step. It is the most immediate tremor, and Part II is given over to it. But notice that it sits in a row with four others. To read everything through the lens of AI would be to make the very mistake this chapter warns against: treating one tremor as the whole earthquake. The harder and truer problem is the simultaneity.

Constructive interference: why they multiply

When two waves meet in phase, physics calls it constructive interference: they combine into something larger than either alone. Changequakes do the same. Coinciding disruptions are multiplicative, not additive, and the most extreme outcomes — the worst and the best — live at their intersections.

This is the most important idea in the chapter, because it is the one our planning instincts handle worst. We are passable at managing one change at a time and poor at the combinations. Consider a familiar one. A team is told to adopt coding agents in the same quarter that a hiring freeze lands and a new data-residency rule takes effect. Managed as three separate items on three separate plans, each looks survivable. Together they interfere: the freeze tells anxious engineers that the agents are here to replace them, adoption curdles into quiet resistance, and someone under delivery pressure routes confidential code through a service that puts it on the wrong side of the new regulation. None of those failures was inevitable on its own; their combination produced them. Run the same forces the other way and the interference turns positive — name the agents plainly as the way the team absorbs work it can no longer hire for, put a guardrail in place that keeps their context inside the compliant boundary, and the freeze, the rule, and the rollout reinforce one another instead of corroding. The forces did not change. The leadership did.

Doing that on purpose, rather than by luck, takes a structure that can see all the forces at once. Three forces interfering across engineering, security, and regulation cannot be steered from inside any one function, because each function sees only its own slice and optimises for it. The organisations that came out of the 2020 pandemic ahead were the ones that stood up cross-functional task forces — IT, HR, and communications in the same room, deciding together — rather than letting each department defend its own corner while the interference compounded between them. The engineering equivalent is a standing AI-adoption group with eng, security, legal, and people-ops at the table from the start, so that the rollout, the guardrail, and the message to anxious engineers are designed as one move instead of three.

Nowhere is this clearer than in the changequake closest to home. The economist W. Brian Arthur observed that technology "creates itself out of itself": each new capability is a recombination of existing ones, and as the stock of available parts grows, the space of possible combinations grows combinatorially.⁵ Agentic engineering is a textbook case. It is not a single invention but what happened when large language models, tool use, version-controlled codebases, cheap cloud compute, and continuous-integration plumbing all crossed their maturity thresholds at roughly the same moment, each one finally good enough to combine with the rest. The agent that writes, runs, and revises code is constructive interference made concrete.

Convergence of that kind does not produce incremental gains; it produces order-of-magnitude ones, because an improvement in one component multiplies the others. And it changes where disruption comes from. As the strategy researcher Ron Adner puts it, classic disruption was industry disruption — one better product unseating incumbents in a single market — while modern disruption is ecosystem disruption: value propositions assembled from several domains at once, erasing the boundaries between them.⁶ Tesla did not win on automotive engineering alone; it converged batteries, software, charging, and data into something the incumbents could not quickly answer. Amazon turned its own internal infrastructure into AWS and became its largest competitor in a business it had not previously been in. Convergence does not just move who wins; it moves where the value is captured. As the boundaries between domains dissolve, the surplus migrates to whoever owns the point the pieces converge on — the platform the others must build on, not the products built on top of it. It is the difference between owning the marketplace and selling one more thing inside it, and it is the question AI now forces on every engineering leader: as value moves to the model, the agent layer, and the data, which side of that line is your work on? The lesson for an engineering leader is uncomfortable and clarifying at once: your next serious challenger may not look like you, and may not come from your industry at all. Kodak is the cautionary case, and not for the reason usually given: it saw the digital camera coming — it invented the thing — and still missed the disruption, because the disruption was never the camera. It was the ecosystem the camera unlocked: digital imaging fused with sharing, social networks, and the phone in every pocket. What unseats you is rarely a single better technology you can point at and copy; it is a recombination across domains you were not watching, which is why monitoring adjacent industries and unconventional competitors is now part of the job rather than an optional luxury.

Scale invariance: the same shape at every size

There is a structural mercy in this. Changequakes are scale-invariant — the same patterns repeat at the level of a single squad, a whole engineering organisation, and an entire industry.⁷ The dynamics when one team adopts agentic tooling rehearse, in miniature, what plays out when the whole company does, which rehearses what plays out across the field.

That fractal quality is useful twice over. An insight earned at one scale tends to transfer to the others, so the frameworks in this book do not need relearning as you move from leading a team to leading an organisation. And it means a single team can serve as a safe-to-fail probe for a change you are weighing at scale — a point we return to when we come to adaptive process and to how a real pilot is run. For now, hold it lightly: understand the shape of a changequake at one level and you understand it at all of them.

So what does a leader do with this?

The practical payoff of the whole framework is a question you can ask in the moment, before you have committed a roadmap to it: is this a changequake, or a passing disruption?

If it is a passing disruption — a competitor's feature, a framework's rise and fall — manage it tactically. Absorb it, respond, move on; do not re-architect the organisation around it. If it is a changequake — foundational, multi-domain, here to stay — then a tactical response is a category error. You cannot project-manage your way through a permanent change in conditions. What it asks for instead is capability: the standing ability to sense, adapt, and keep shipping as the ground shifts. Building that capability is what the rest of this book is about.

The first move is the cheapest and the most neglected: name your fault lines. You cannot predict when the next slip will come, but you can say where the pressure is building in your world — model and vendor lock-in, brittle prompts and ungoverned AI adoption, critical knowledge concentrated in too few heads, a compliance regime that could reverse. Naming them turns a vague dread of "disruption" into a short list of things to build optionality against. That move — from forecasting a single future to preparing for a range of them — is the difference between forecasting and foresight, and it matters enough that a later chapter is given to doing it well.

Here is the part of the metaphor that matters most. Engineers in seismic country do not predict the next earthquake; the timing is genuinely unknowable. They assume it is coming and build so the structure stands when it does. That is the posture this book argues for. You will not predict the next changequake. You can stop building as though the ground were solid — and start leading an organisation designed to keep standing, and keep shipping, when it moves.

The next two chapters lay the groundwork: first, why the operating models most of us inherited fail in exactly these conditions, and then the one that takes their place.