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.