Nobody put these on the syllabus. You did not learn them in your MBA, your computer science degree, or your first management training programme. They come from sociology, systems theory, military logistics, and the dry observations of engineers who got tired of watching the same failures repeat themselves.
And yet they explain — with uncomfortable precision — why software projects are late, why performance metrics stop working, why transformation programmes collapse, and why the wrong people keep getting promoted.
I call them the laws they do not teach. Not because they are obscure. Because most organisations would rather not acknowledge what they imply.
Here are the six that matter most.
Conway’s Law: Your Organisation Is Your Architecture
Mel Conway observed in 1967 that any organisation that designs a system will produce a design whose structure mirrors the organisation’s communication structure.
Fifty years of software development have done nothing to disprove this. When your platform team and your product team do not talk, you get a platform your product cannot use. When your mobile team and your backend team are in different reporting lines, you get an API that does not fit the app. The structure of the conversation produces the structure of the system.
The implication for product leaders is specific: if you want to change the architecture, you first have to change how the teams communicate. Reorganise the teams, and the system will follow. Try to change the system without reorganising the teams, and the system will drift back.
Most technology transformations ignore this. They announce the new architecture and leave the org chart alone. Then they wonder why the new architecture looks, six months later, suspiciously like the old one. Conway’s Law in full →
Goodhart’s Law: Your Metrics Are Lying to You
Charles Goodhart, advising the Bank of England in the 1970s, articulated something that had always been true: when a measure becomes a target, it ceases to be a good measure.
In product, this plays out constantly. You measure story points — engineers game story points. You measure customer satisfaction scores — teams learn when to send the survey. You measure deployment frequency — teams deploy smaller, meaningless changes to hit the number.
The metric does not disappear. The behaviour it was supposed to capture does. What remains is the appearance of performance without its substance.
There is no clean solution to Goodhart’s Law — only awareness of it. Metrics are always an approximation of what you care about. The moment they become a target, the approximation degrades. The answer is not to stop measuring but to hold your metrics loosely, rotate them before teams optimise for them, and never mistake the map for the territory. Goodhart’s Law and what to do about it →
Brooks’ Law: Adding People Makes It Later
Fred Brooks published The Mythical Man-Month in 1975. Its central observation: adding manpower to a late software project makes it later.
This feels counterintuitive. More people should mean more capacity. In software, it means more communication overhead, more onboarding time, more coordination cost — all of which slow the existing team down before the new people contribute anything.
Brooks’ Law does not mean you should never hire. It means that headcount is not a delivery lever. When a project is late, the right questions are about scope, clarity, and process — not about who else you can pull onto it. Defaulting to “we need more people” is a way of avoiding those harder questions, and it tends to make the hard questions harder. Brooks’ Law and your delivery problem →
Gall’s Law: Complex Systems Cannot Be Designed
John Gall’s Systemantics (1975) contains one observation that should be tattooed on the forehead of every programme director who has ever kicked off a transformation:
A complex system that works is invariably found to have evolved from a simple system that worked.
The corollary: a complex system designed from scratch never works and cannot be patched into working. You have to start again with a simple system.
This is not a small claim. It is a direct argument against the design philosophy behind most enterprise transformation programmes — the big bang, the blank-sheet redesign, the multi-year platform rebuild. These approaches assume that complexity can be engineered in advance. Gall says it cannot. Complexity that works has always been earned, iteratively, from something simple.
Product leaders who understand Gall’s Law stop asking “how do we design the right system” and start asking “what is the simplest thing that could work, from which we can grow?” Gall’s Law and why your transformation will fail →
Putt’s Law: The Competence Inversion
Archibald Putt observed that technology organisations are dominated by two types of people: those who understand what they do not manage, and those who manage what they do not understand.
Its corollary is that every technical hierarchy, in time, develops a competence inversion. The people who understand the work rise until they are too far from it to do it well. The people who cannot understand it rise into positions where they decide what gets built.
The uncomfortable reading of Putt’s Law is not structural but personal. The inversion is not something that happens to you — it is something you either resist as a discipline or slide into as a comfort. Staying on the understanding side, as you rise, is a choice that gets harder every year. The quiet surrender of technical leaders →
The Peter Principle: Promotion as the Enemy of Performance
Laurence Peter argued in 1969 that in a hierarchy, every employee tends to rise to their level of incompetence. You are promoted for what you are good at — until you reach a role where those same skills do not apply. There you stay.
In technology organisations, this typically looks like the exceptional engineer who becomes a struggling engineering manager, or the outstanding individual contributor who becomes a poor director. The skills that earned the promotion are not the skills the new role requires. Nobody says this at the time. The performance review avoids it. The system continues.
The Peter Principle does not indict individuals. It indicts the assumption that performance in one role predicts performance in the next. Product and engineering leaders who understand it build career paths that do not require people to become managers to advance — because the cost of misaligned promotions lands on the teams those people manage. The structural problem your performance review won’t name →
What Unites Them
Each of these laws was articulated by someone who had watched a particular failure repeat itself often enough to name it. None of them are cynical. They are precise.
What they share is this: organisations behave in predictable ways that individual intelligence cannot easily override. The shape of a team produces the shape of a system. Metrics corrupt what they measure. Adding resources to broken processes adds to the breakage. Complexity cannot be designed, only grown. Competence and management diverge. Promotion amplifies misfit.
Knowing this does not make you immune. But it does change what you look for, what you name, and — sometimes — what you choose to do differently.
The Laws They Don’t Teach series:
- Conway’s Law: Why Your Org Chart Is Your Product Architecture
- Goodhart’s Law: Why Your Metrics Are Lying to You
- Brooks’ Law: Why Hiring Won’t Fix Your Delivery Problem
- Gall’s Law: Why Your Transformation Programme Will Fail
- The Peter Principle: The Structural Problem Your Performance Review Won’t Name
- Putt’s Law: The Quiet Surrender of Technical Leaders
Leave a Reply