Preface¶
I have spent the better part of twenty-five years building things. Embedded systems in defence programmes. IoT platforms at scale. Telecoms infrastructure serving millions of customers. Products that had to work in the field, under conditions nobody fully anticipated, built by teams who were asked to commit to dates before they understood the problem and held accountable for outcomes they were never given the authority to shape.
In that time I have watched capable engineers fail to deliver. Not because they lacked skill. Not because they weren’t trying. But because the systems surrounding them were designed - often without anyone noticing - to produce exactly the outcomes they produced.
I have watched risk registers get filed instead of acted on. I have watched honest estimates get replaced by commercially convenient ones. I have watched the gap between what engineers knew and what decision-makers believed grow into the space where programmes fail. And I have watched the blame for those failures travel downward, landing on the people who saw it coming and said so.
This book exists because that pattern is not inevitable. It is structural. And structural problems have structural solutions.
Firmitas is not an argument for a new methodology. There are enough of those. It is an argument for understanding why engineering programmes fail before reaching for the tools that are supposed to prevent it. The tools are often fine. The understanding is frequently absent.
The word comes from Vitruvius - the Roman architect who argued that any structure worth building required firmitas, utilitas, and venustas. Solidity, usefulness, and beauty. Firmitas came first. Not because beauty does not matter, but because without structural integrity nothing else can stand.
That sequence is the thesis of this book. Before methodology. Before process. Before governance frameworks and delivery models and maturity assessments - you need to understand the system you are working in, who owns what within it, and whether the people making the decisions that shape delivery have the information and the authority to make them well.
Most organisations have the sequence backwards. They install process and hope that understanding follows. It rarely does.
This book is written for the practitioner who has been on the programme that failed predictably. The engineer who knew the risk register was being filed rather than managed. The architect who watched an honest estimate get replaced by a commercially convenient one. The delivery lead who raised the issue at month two and was overridden, and who was then held accountable for the failure at month eight.
It is also written for the leader who made those decisions and genuinely did not understand the cost.
Not because leaders are the villains in this story - they are not. The leaders who override engineering judgement, who rubber-stamp gate reviews, who set dates before scope is understood, are almost always doing what their system has taught them to do. They are responding rationally to the incentives around them. Changing those incentives, and changing the systems that produce them, is what this book is about.
If you are looking for a process to install, this book will disappoint you. Firmitas is not a process. It is a philosophy that constrains a framework, which in turn constrains the process choices available within it. The distinction matters because it is precisely the inversion of that sequence - process first, philosophy never - that produces the failure patterns this book is designed to prevent.
If you are willing to examine the system you operate in honestly - including your own role within it - this book may be useful.
A note on what this book is not for.
Firmitas is not for every organisation. A small team building a product quickly without regulatory obligations does not need this framework. The overhead is disproportionate and the philosophy, though sound, will be applied at a scale that produces bureaucracy rather than clarity.
It is also not for organisations where the primary obstacle is not systemic but political - where the people with power benefit from the current dysfunction and have no incentive to change it. Firmitas can help a willing organisation build better systems. It cannot make an unwilling one want to.
And it is not a silver bullet for any organisation. Applied sincerely by a capable leader in a receptive organisation, it will improve delivery. Applied as a process without the philosophy behind it, it will produce the same outcome as every other framework adopted without understanding - compliance theatre, improved metrics, and the same underlying failures arriving slightly later and slightly harder to diagnose.
The honest limits of this framework are addressed directly in Part Three. A framework that cannot tell you when it is wrong is not a framework. It is a belief system.
The structure of this book follows the logic of the argument.
Part One diagnoses the failure. It describes the specific structural mechanisms by which capable engineering organisations consistently fail to deliver, and why those failures are misattributed in ways that make the next failure more likely. If you are sceptical that your organisation has a structural problem - if you believe the issue is execution, competence, or commitment - Part One is written for you. Read it with the last programme that failed in mind.
Part Two presents the framework. Every element is introduced as a direct response to a specific failure mechanism identified in Part One. The framework does not exist independently of the diagnosis. It is the structural answer to a structural question.
Part Three addresses adoption, sustainability, and honest limits. Including the limits of the framework itself, the conditions under which it fails, and the specific warning signs that it is being misused.
One final observation before the book begins.
The most important thing I have learned across twenty-five years of building things is that the people closest to the work almost always know what is wrong. They know which risks are real and which are filed for appearances. They know which estimates are honest and which were produced under pressure to say something more comfortable. They know when the architecture will not hold and when the plan was never achievable.
The question is never whether that knowledge exists. It is whether the system allows it to reach the people who need to act on it.
Building that system - designing the conditions under which what engineers know can influence what leaders decide - is the work this book is about.
It is harder than installing a process. It requires more of leaders than compliance with a framework. But it is the only thing that has ever actually worked.
Mark Bacon, April 2026