Our systems are only stable on weekends. And we call that innovation?

Ever notice the silence of a Saturday? No urgent Slack pings. No panicked emails about a failed deployment. Dependency doom? The monitoring dashboards are all green. It’s beautiful.

More !

And it’s the most damning indictment of our entire industry. We spend millions on engineering talent, agile coaches, and CI/CD pipelines. We celebrate velocity. The relentless push for more features, more updates, more progress!

And the result? The most stable, performant version of our applications, platforms and services is the one that exists from Friday afternoon till Monday morning. You know until the moment our teams start working, then the system starts breaking.

In my earlier articles I tried to articulate that underlying something. We’re not solving problems anymore. We’re just orchestrating future outages. We are focussed on frantic activity. I called it in a cynical mode the First Law of Engineering Thermodynamics: Problem energy can neither be created nor destroyed, only changed in form.

That was focussed on the engineers perspective. I think I’ve found another one. It’s the unspoken law of technological entropy:

In a closed system, the relentless injection of new features increases complexity until the point of collapse

So how do we architects best approach this?

Kill Velocity as the #1 metric. Stop celebrating the team that closes 100 tickets and start celebrating the team that delivers a quiet, uneventful quarter. Reward the non-event. Reward stability. The lessening of complexity. Mandate a Complexity Budget. Every new feature, every new dependency, costs something. That cost is future instability. Make that cost visible. Force a trade-off. Yes, we can add this feature, but that means our complexity budget is spent for this quarter. Sell the Cost of a feature. How do you explain this to a board obsessed with feature parity? You do not stop talking about technical debt but also start talking about risk. Show them the data. The correlation between deployments and P1 incidents. Frame stability as the ultimate feature.

This isn’t about slowing down. It’s about being strategic enough to go fast on the things that matter, by building on a solid foundation.

It’s time to stop being firefighters: What’s the one metric you would kill tomorrow to get off this treadmill?