Phase 1: move the remaining sections in, one commit per section

content/firmitas/01-preface.md

@@ -0,0 +1,73 @@
+---
+title: Preface
+---
+
+# 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*

content/firmitas/02-acknowledgements.md

@@ -0,0 +1,59 @@
+---
+title: Acknowledgements
+---
+
+# Acknowledgements
+
+The ideas in this book are not new.
+
+That is not a disclaimer. It is the point.
+
+Frederick Brooks described the essential nature of software complexity in 1975. He showed why adding people to a late project makes it later, why there is no silver bullet, and why the optimism that drives engineering programmes is also the primary source of their failure. Fifty years later, programmes are still being staffed up when they are late, silver bullets are still being purchased, and optimism is still being mistaken for a plan.
+
+Tom DeMarco spent a career articulating why engineering organisations fail - not through incompetence but through the systematic elimination of the conditions that make good work possible. Across his full body of work - from his early writing on structured analysis, through *Peopleware* (with Timothy Lister), *The Deadline*, *Slack*, and *Waltzing with Bears* - he returned repeatedly to the same hard truths: that schedule pressure destroys the conditions for quality, that risk is managed by naming it rather than optimising it away, and that the human cost of permanently urgent systems is real, measurable, and routinely ignored. His work on estimation and risk alone should be required reading for every programme manager who has ever asked a team to commit to a date before the scope was understood.
+
+Timothy Lister, DeMarco's long-time collaborator and a formidable thinker in his own right, brought the same clarity to the human dimensions of engineering work - the teams, the environment, the trust, and the conditions under which people either do their best work or learn to protect themselves from the consequences of doing otherwise. His writing on risk management, on the sociology of engineering teams, and on what actually determines whether projects succeed deserves more recognition than it typically receives.
+
+Dan Pink demonstrated that the conditions for sustained motivation - purpose, autonomy, mastery - are not soft concerns. They are structural prerequisites. Remove any of them and performance degrades regardless of how hard people try. Organisations that claim to value their engineers while systematically undermining those three conditions are not cruel. They are structurally dishonest.
+
+Simon Sinek articulated why purpose precedes everything else - why organisations that cannot answer why they exist will always struggle to align what they do. His observation that people do not buy what you do, they buy why you do it applies as much inside engineering organisations as it does in markets. Leaders Eat Last extended that argument into the conditions of trust and psychological safety that determine whether teams operate out of confidence or fear.
+
+Steve McConnell gave the software industry its most rigorous treatment of estimation, planning, and the cost of shortcuts. *Software Estimation* alone dismantles the assumptions behind most programme planning - the optimism bias, the estimation by analogy, the political pressure that converts an honest range into a single committed date. *Code Complete* and *Rapid Development* remain essential references for anyone serious about the craft and management of software. His work is notable for its refusal to separate technical excellence from delivery discipline.
+
+Watts Humphrey brought the same rigour to process discipline and the personal and team dimensions of software practice. His insight that quality is built in through disciplined individual and collective practice - not inspected in at the end - was decades ahead of its mainstream acceptance. The Personal Software Process and Team Software Process work demonstrated empirically that estimation accuracy and quality outcomes improve dramatically when engineers are given the tools and the trust to manage their own work rigorously.
+
+Johanna Rothman has spent decades writing practically and honestly about the reality of managing software projects - the estimation traps, the scheduling failures, the team dynamics, and the specific decisions that distinguish programmes that deliver from those that don't. Her work is grounded in the messy reality of actual programmes in ways that more theoretical frameworks are not. She writes for practitioners who have to make decisions under uncertainty, and she does not pretend those decisions are easy.
+
+Joel Spolsky's writing on software management, hiring, and the conditions that make engineering teams effective remains some of the sharpest practitioner thinking available. His Joel Test - twelve questions that reveal more about a development organisation's health in five minutes than a maturity assessment reveals in a week - was a direct inspiration for the Firmitas Delivery Diagnostic in this book. His willingness to state uncomfortable truths plainly, without the hedging that characterises most management writing, set a standard this book attempts to follow.
+
+Gerald Weinberg spent a lifetime examining the human and organisational dimensions of software work - the psychology of programming, the politics of quality, the systems dynamics that produce the outcomes organisations claim not to want. His observation that every organisation is perfectly designed to get the results it gets is one of the most important sentences ever written about organisational behaviour. His *Quality Software Management* series, *The Psychology of Computer Programming*, and *Becoming a Technical Leader* together constitute an indispensable library for anyone serious about the human side of engineering.
+
+Donald Reinertsen brought the economics of product development flow into sharp focus - the cost of delay, the damage done by large batches, the mathematics of queue theory applied to the reality of engineering programmes. *The Principles of Product Development Flow* is a book that rewards careful reading and re-reading. His work on flow efficiency over resource efficiency underpins much of what this book says about utilisation, slack, and the myth of the fully loaded team. The economic argument for slack - that maximising utilisation destroys throughput - is not intuitive, but once understood it is impossible to unsee.
+
+Gene Kim, Kevin Behr, and George Spafford made the same arguments accessible to a generation of technology leaders through *The Phoenix Project* - demonstrating through narrative what Reinertsen demonstrated through economics, and reaching an audience that might not have engaged with the underlying theory.
+
+Matthew Skelton and Manuel Pais gave the industry a precise vocabulary for team topology and cognitive load - the language of stream-aligned teams, platform teams, enabling teams, and the interaction modes between them. Their work on Conway's Law as a design constraint rather than a warning is directly reflected in how this book treats team structure and organisational design.
+
+W. Edwards Deming understood quality as a system property before most of the software industry was born. His insistence that quality problems are management problems - not worker problems - and that the system produces the outcomes it is designed to produce is the foundational insight from which much of this book's argument flows. His fourteen points and his red bead experiment remain as relevant to engineering programme management as they are to manufacturing.
+
+Peter Senge made systems thinking accessible and practical. *The Fifth Discipline* gave a generation of leaders the language to describe the feedback loops, delays, and unintended consequences that make organisational change so difficult and so necessary. The concept of the learning organisation - one designed to surface and act on its own failure patterns - is central to everything Firmitas proposes about how programmes should be governed.
+
+Steve Tockey brought rigorous engineering economics to software decision-making - the argument in *Return on Software* that engineering decisions are always economic decisions, whether acknowledged or not, and that treating them as purely technical produces the same quality of outcome as treating financial decisions as purely aesthetic. His work on the cost and value dimensions of software engineering choices is underread and underappreciated.
+
+Michael Lopp wrote about the human reality of engineering management with honesty and precision - the conversations that do not happen, the signals that get missed, the specific moments where leadership either earns or loses the trust of the people it is responsible for. *Managing Humans* is the book that many engineering managers wish they had been given before they started, and his ongoing writing continues to name the things that most management literature is too polished to say plainly.
+
+---
+
+I owe an intellectual debt to all of these writers and practitioners. Their work shaped the thinking in this book in ways that are sometimes explicit and sometimes so thoroughly absorbed that the original source is hard to separate from the argument.
+
+The reason this book exists despite that body of work is simple and uncomfortable: the lessons are still not being learned.
+
+Not because the books are wrong. Not because the principles are unsound. But because knowledge does not change systems. A manager who reads *Peopleware* and then returns to a programme governed by utilisation targets, rubber-stamped gates, and reverse-engineered plans has not been equipped with what they need to change those things. The knowledge exists. The structural response to it does not.
+
+Firmitas is an attempt to build that structural response - to take the lessons that have been available for decades and embed them in a framework that addresses the organisational conditions that prevent them from being applied. It does not supersede the works listed above. It stands on them and asks why, fifty years after Brooks first described the problems, we are still producing programmes that fail in exactly the ways he predicted.
+
+The answer is systemic. So is the solution.
+
+---
+
+*The Further Reading section at the end of this book provides a curated guide to the works referenced here, with specific recommendations on which to read first and why.*