Some of the hardest problems to deal with are the ones where nothing is technically wrong. Systems are up, checks are green and the dashboards look fine, and yet something feels off. Performance is worse than it should be. Things feel heavier, slower, less predictable. Not broken, just degraded. These are the problems that cause the most frustration, because they don’t give you anything clear to fix.
We’re Good at Fixing Broken Things
Most processes are designed around failure. Something stops working, an alert fires and a response is triggered. That model works well when the problem is obvious, because a clear fault leads to a clear action. Not all problems announce themselves like that. Some arrive gradually and quietly, without ever crossing a line, and because nothing is broken they are easy to ignore or explain away.
Degradation Doesn’t Look Like Failure
When performance degrades there is rarely a single cause. It’s usually a slow accumulation: a bit more load, slightly different usage patterns, dependencies behaving just a little differently, assumptions that no longer quite hold. Each change on its own is reasonable. Together they move the system into a state it was never designed for. Nothing trips and nothing crashes. It just doesn’t feel right anymore.
Something stops working, an alert fires and a response is triggered. A clear fault leads to a clear action.
Some arrive gradually and quietly, without ever crossing a line. Nothing trips and nothing crashes. It just doesn’t feel right anymore.
The Instinct to Wait for Certainty
When nothing is broken, the instinct is to wait. To wait for clearer signals, for a metric to cross a threshold, for something you can point to with confidence. The problem is that by the time you get that certainty, the system is already under stress. Performance issues are often best addressed before they’re undeniable, when they still feel subjective and uncomfortable to talk about, and that is an awkward place to act from.
Experience Shows Up as Discomfort First
One thing I’ve learned is that early warning signs don’t always look technical. They show up as things taking longer than they used to, small hesitations you can’t quite explain, a sense that you’re closer to the edge than before. Those signals are easy to dismiss because they don’t come with evidence, but they are often the most valuable ones.
Not when things break, but when you notice they’re starting to bend.
The Same Pattern Outside of Systems
The same thing happens elsewhere.
Relationships that aren’t broken but feel strained.
Routines that still work but drain more than they give.
Situations that technically function but take more effort than they should.
When nothing is obviously wrong it’s tempting to push through and normalise the discomfort. That works, until it doesn’t.
Performance Problems Are Usually Alignment Problems
In hindsight, most performance issues aren’t really about speed or capacity. They’re about misalignment. The system is being asked to do something it wasn’t shaped for, even if it’s still capable of doing it. The fix isn’t always dramatic. Sometimes it’s a small adjustment, sometimes it’s restoring margin, and sometimes it’s deciding not to keep stretching things just because you can. Those decisions rarely come from dashboards alone. They come from paying attention.
Acting Before Things Break
It’s uncomfortable to act when you can’t point to a clear failure. It takes judgement instead of certainty, context instead of rules, responsibility instead of reaction. But that is often where stability is recovered: not when things break, but when you notice they’re starting to bend.
Some of the most important work happens in that grey space, where nothing is broken, where performance is just a bit worse than it should be, and where you act not because you have proof but because you understand the direction things are moving in. That kind of judgement doesn’t show up in alerts, but it’s often what prevents them.
A companion piece: When Automation Stops Helping.
Leave a Reply