Introduction

If your organisation refers to “the business” as a group that excludes engineers, this book is about your company. It maps the structural dysfunction of software-dependent corporates and the changes AI now demands.

If you have ever sat in a meeting where everyone agreed on a plan you knew could not work, and stayed silent because speaking up would cost more than the dysfunction itself, this book explains why that keeps happening and what changes when the structure stops rewarding it.

This book is for people who work inside software-dependent corporates and suspect that something is structurally wrong. It is for CTOs, senior engineers, architects, and product leaders who have watched technology investment produce activity without proportional outcomes, and who suspect the cause is not execution, talent, or technology, but something in the structure itself that no one has named. It will also be useful to CEOs willing to engage the operational detail behind that diagnosis. The board-level case is made separately in the companion volume, Illusions in the Boardroom.

Most examples in this book are fictional, but they are not hypothetical. Each is a composite drawn from patterns observed repeatedly across software-dependent corporates in banking, insurance, retail, logistics, and enterprise software. If they feel familiar, that is the point. The figures attached to them are illustrative of the magnitude these patterns reach rather than measurements of any single named organisation: the cost of a cancelled platform investment, the months of coordination behind a few days of code, the improvement a first autonomous unit produces. Each is something you can measure in your own; the appendix A Note on the Numbers sets out how, and what a sceptic should ask before accepting any figure in these pages. One chapter departs from this. The Programme That Wasn't an IT Project is built from a single real engagement, anonymised and compressed; the sequence, the structural diagnosis, and the intervention are real, and the note accompanying it explains what it is and is not offered as evidence of.

There is a particular kind of exhaustion that comes from working inside a large organisation that now runs on software, if you are close to how things actually work. It is quiet and corrosive: the feeling of navigating representations everyone treats as real, while knowing that they are not.

You sit in meetings where “the business” discusses priorities that have no stable relationship to the systems that produce value. You watch strategy documents grow longer as understanding shrinks. You see engineers blamed for outcomes that were decided elsewhere, in abstractions disconnected from reality. You notice that the more precisely you describe reality, the more friction you generate.

The exhaustion does not come from bad people, bad intentions, or incompetence, but from a specific organisational form that has become widespread over the last two decades: the software-dependent corporate.

Software-dependent corporates are large, established organisations whose products and operations now depend critically on software, but whose power structures, budgeting models, and decision-making processes were designed for a world in which software was a support function: something you procured from vendors, managed through an IT department, and governed as a cost centre. Banks, insurers, retailers, logistics firms, airlines, public sector bodies, and also older companies that describe themselves as “technology companies” but still operate with these inherited assumptions all fall into this category.

These organisations are not “pre-software”; they have had software for decades. What they have not adapted to is the shift that began between roughly 2008 and 2012, when software stopped being infrastructure and became the primary medium through which these companies create and deliver value. In the space of five years, smartphones made software the default customer interface, cloud computing made custom development at scale economically viable, and the expectation that large organisations would build and operate their own software continuously went from radical to mainstream.

...

See also: Full contents · Preview chapters · Illusions in the Boardroom