Over the past year I’ve spent four articles naming laws. Laws. Forces that operate on systems whether the teams has read them or not. It was my take on both playing with words and trying to describe the things I saw in the form of Thermodynamic Laws. They were my sarcastic take: Problem energy shifts form. Complexity accumulates until it collapses. Context decays faster than code. Preserved context fossilises into a trap.
They all sound like weather
A former colleague apparantly read through the series and sent me a message. “These all sound like weather,” she wrote. “Things that happen to you. Who’s making them happen faster?”
I didn’t have a good answer. I had been describing forces as if they were impersonal. As if I was acting like a victim. They’re not impersonal and I am not a victim.
Accomplices or enablers
Every repo degrading under the Second Law (Complexity accumulates until it collapses) has a backlog behind it. And in that backlog, somewhere, is a product manager who got measured on velocity. Number of stories delivered. A sprint ceremony that celebrated features shipped without ever counting the complexity added. A someone who approved “we’ll fix the tech debt next quarter” for umpteen consecutive quarters. Each one with a green checkmark.
The First Law operates. Problem energy shifts form. But the shift happens faster when someone closed the ticket and moved on. Explicitly. Measurably. Deliberately.
The Third Law operates. Context decays. But it decays faster when the team that built the system got reorganised away from it. When the architecture decision record was last opened three years ago because nobody scheduled a review. When the senior developer who actually understood why the thing was moved away, and onboarding consisted of giving their replacement a GitHub account and a list of Jira tickets and some Confluence pages.
The Amber Trap doesn’t spring itself. Someone sets it, probably unconsciously.
These are not weather events. They are decisions that someone made. To be fair, with a limited context or scope.
The gap
What’s interesting to notice is that the people who accelerate the laws are usually the same people who complain about the symptoms. The CTO who mandated weekly features is surprised by the Sunday outages. The product manager celebrating velocity is baffled by the emergency patch costs. The organisation that keeps adding approval layers wonders why nothing ships anymore.
(The Second Law, by the way, doesn’t just apply to codebases. A governance framework under relentless policy injection follows exactly the same entropy curve. TJust look at what is happening at De Belastingdienst.)
The question I now toy around with is: Is the gap ignorance? Because most of these people have sat in these complexity conversations. They’ve approved “we’ll sort this out next year” for long enough to know they won’t. Either they know, or it is political.
The gap is consequence. Nothing happens when the quarterly interest payment goes unacknowledged. Nobody’s performance review includes the line: “approved fourteen consecutive deferments on platform investment, resulting in the following operational costs.” So the deferments continue. The laws accelerate. And in the next all-hands, someone announces a new initiative to move faster.
What you’re actually choosing
To put it very black and white. All we do or chose to do has consequences. Every time a team celebrates “shipped” without tracking what new problem the solution created: that’s a choice.
Every time a complexity conversation gets deferred because “we don’t have bandwidth right now” that is a choice.
Every time a system gets handed from one team to another with a README and a cheerful “let me know if you have ANY questions” that is a choice.
I am not describing malice. Most of these decisions are made by people genuinely trying to move fast, ship value, and keep the business happy. Intention doesn’t change the physics. The laws don’t ask what you meant, they just compound interest over time.
The audit trail nobody runs
The laws that started as sarcastic take, now almost feel like gravity. But I think that is because nobody traces them back. Start tracing. Pick one degraded project. and then start interviewing peope. What decision made this worse? Who made it? And then the million dollar question: Did they know what they were setting in motion?
Usually the answer is no. That is the problem worth solving.
The people who set the conditions
I’ve been writing this series of articles mostly for myself, to get around and think about all the ideas I have and to think them through. Some of my articles, like my ideas are getting better. BUT! The question my former colleague asked keeps rattling in my brain. It links directly to the people who set the conditions. Because I am one of them!
We all know that setting velocity targets without a complexity costs have quietly trained engineers to hide the wrong numbers. The C-suite that runs “we need to move faster” all-hands without asking what faster costs is enabling that. Good architecture reviews slow down the worst of these laws.
Who chairs those reviews? What authority do they have to say no? Who do they report to? Are they in the room when the roadmap gets approved, or sent the slides afterwards and asked to “flag any concerns”?
These are organizational design questions.
Manage it well
The only organizations I’ve seen manage this well have two things in common. First, they have someone with a map. A clear picture of which systems are operating and at what acceleration. Second, that person has enough organizational authority to stop a decision that’s about to make things worse.
Not to slow everything down. To make the trade explicit. To say: “We can do this feature. Here is what we are trading for it. Here is the new problem it creates. We are choosing this delibarately”
That’s not obstruction. That’s accountability. And right now, in most organizations, nobody owns it.
Leave a Reply