I once had a delicate problem to deal with.
The head of automated testing (at a company many of you interact with weekly) was extremely proud of his latest results. High-fiving himself, even!
Response times had dropped from 1.5 to 3 seconds all the way down to 50 milliseconds. He thought some miraculous code refactoring had produced a 60x improvement!
I had to tell him diplomatically that it was most certainly a test design flaw. The HTTP requests were never leaving the testing servers. There was no checkpoint to verify whether requests succeeded, and no validation of subsequent steps in the navigation flow. The tool reported every transaction at 50 milliseconds because none of them had actually occurred. There was no error-handling.
He didn’t take that revelation very well. To put it another way, he ignored my advice and presented the faulty data anyway. He was last seen running down the hallways in Southington, high-fiving himself, even congratulating himself about his ingenuity, and the third swimming pool he had just put in his house, at the expense of his banking clients.
Meanwhile, the average family can’t afford a mortgage. But they can afford the calculator app on their mobile phone, and they know when numbers don’t add up.
This is what happens when people don’t understand the data they’re looking at. And when organizations hire amateurs to manage application performance, they get exactly this: overconfident reporting of numbers that mean nothing.
If you want skilled professionals to run your systems, don’t call in The Southington Expendables. They’re more concerned about their Lanais and the ski lessons for the little ones, than they are with the systems that hold your money.
I’m not.
I’m just like you.
I scrutinize every transaction and I distrust institutions.
Modern technology organizations have become very good at collecting signals. They stream metrics from infrastructure, applications, databases, queues, and third-party integrations. They trace requests, monitor real-user sessions, synthetic journeys, payment latency, and deployment events. The instrumentation has never been more capable. The budgets committed to it have never been larger.
And yet, when things go wrong at scale, the same failure repeats: the data was there, and nobody knew whose job it was to act on it. If your organization cannot translate technical telemetry into customer impact, revenue risk, and reputational exposure, the data is useless. And so is the team responsible for it.
The tooling is almost never the issue
In 2020, an AWS Kinesis failure cascaded into Cognito, CloudWatch, Auto Scaling, and Lambda simultaneously. The crueler dimension was structural: Kinesis was a single point of failure for AWS’s own observability stack. The system used to detect the problem was itself broken. Teams with CloudWatch alerts configured to detect the outage found themselves flying blind at precisely the moment those alerts were most needed.
A company can have Datadog, Splunk, Grafana, AppDynamics, New Relic, distributed tracing, and real-user monitoring and still fail to answer the simplest operational questions during an active incident: Who owns this service? Who is on point? What customer journey is impaired? Who can authorize a rollback? What is the business impact right now?
Those are not telemetry problems. They are ownership problems. And they reveal themselves at the worst possible moment.
When observability cannot see itself
On October 4, 2021, a network configuration update withdrew the routes that told the internet how to reach Facebook’s servers. Facebook, Instagram, and WhatsApp were unreachable globally for nearly seven hours. The backbone and recovery systems were tightly coupled: when the backbone failed, engineers needed physical access to peering routers in data centers to authenticate to the systems that could resolve the issue. There was no out-of-band path.
Facebook had world-class observability. What the incident exposed was an architectural assumption so deeply embedded it had never been stress-tested: that the systems used to monitor and respond to failures would always be available when needed. When that assumption broke, the response model broke with it.
Observability is only as durable as the operating model around it. A monitoring stack that shares failure modes with the system it monitors is not a safety net. It is a liability dressed as one.
Operational visibility without operational accountability
In December 2022, Southwest Airlines canceled more than 60% of its flights on two consecutive days, stranding approximately two million passengers. Weather was the trigger, not the cause. The crew scheduling software couldn’t identify recovery paths and required extensive human intervention, while schedulers manually cross-checked eligibility as crews approached federally mandated hour limits.
The warnings had been documented and delivered to the CEO. The risk was known. What was absent was a clear owner with the mandate to resolve it before a major disruption arrived. When the triggering event came, the gap between what the system could observe and what it could act on produced a $140 million loss, a DOT settlement, and lasting reputational damage. The scheduling data existed. The authority structure to use it under stress did not.
When the monitoring platform is the platform
In July 2024, a faulty CrowdStrike configuration update caused approximately 8.5 million Windows machines to crash simultaneously, affecting hospitals, airlines, emergency response, and transit systems. Delta alone lost an estimated $500 million. Hospital systems incurred nearly $2 billion in costs reverting to manual workflows.
Many of the organizations hit hardest were running Falcon Sensor precisely because they had mature security monitoring programs. Their investment in instrumentation became the vector of failure. The organizations that recovered fastest were not the ones with the most dashboards. They were the ones with clear service ownership, tested rollback playbooks, and defined incident command. When the tool fails, the operating model is all that remains.
What observability actually requires
The highest purpose of observability is not more data. It is less ambiguity. A mature program answers four questions rapidly: What is happening? Who is affected? Who owns the response? What decision is needed next?
Most organizations overinvest in the first question and underinvest in the other three. They can detect latency spikes and failing traces. What they cannot do quickly is connect those signals to customer impact, service ownership, and required action. That gap is where operational excellence either exists or does not.
None of these signals become useful until the organization has decided what happens when they move. Who investigates? Who declares severity? Who owns rollback? Without those answers documented and tested in advance, observability platforms generate noise, not control.
Service ownership is a governance function, not a bureaucratic one
In complex platforms, service ownership defines who is accountable for reliability, performance, observability coverage, runbook quality, release readiness, and incident response. A checkout flow, payment integration, identity layer, or order management platform should not exist in an operational gray zone. The absence of ownership is itself a risk condition: no one is hardening the service before peak demand, no one is keeping runbooks current, and no one is translating telemetry into business risk.
That is how technical debt becomes operational debt. That is how operational debt becomes a visible incident.
The real incident response model is built before incidents: through service catalogs, ownership maps, escalation policies, runbooks, severity definitions, and postmortem discipline. In the best organizations, a critical alert is not merely a notification. It is the start of a known operating sequence. That is operational maturity: not because the dashboard is beautiful, but because the organization knows what to do with what it sees.
What leaders actually need to know
Leadership does not need every chart. It needs to understand operational risk, customer impact, response status, and decision points. A mature operational health report explains what is stable, what is degraded, what risks are emerging, and where leadership action may be required.
Many observability programs fail upward: too much technical detail, too little operational meaning. Executives do not need trace spans. They need to know whether checkout latency is rising ahead of a major event window, whether a payment integration is showing irregular failure patterns, or whether a vendor dependency has been carrying concentration risk for eighteen months without resolution authority.
The job of engineering leadership is to translate telemetry into judgment. If you cannot do that, the data and the people generating it are not assets. They are overhead.
Staff for the business, not the tool
The next phase of observability maturity will not be defined by more sophisticated collection. It will be defined by putting the right people in the room, people who understand what the business actually does, what a degraded checkout flow costs per minute, and what the difference is between a test result and a real signal.
The person running your performance program should be able to tell your CFO what last night’s latency spike cost in abandoned carts. Your incident commanders should understand the downstream consequences of a payment integration failure before they decide whether to escalate. Your monitoring engineers should know the difference between a dashboard that is technically correct and one that is operationally meaningful.
Tooling is a commodity. Judgment is not. The organizations that confuse the two end up with rooms full of dashboards, nobody who can read them in context, and a gap between what the system is telling them and what they are actually able to do about it. That gap is not a technology problem. It is a hiring and accountability problem, and it will remain one until leadership decides to treat it as such.
Leave APM to the professionals; the world always needs more print operators scooping debris from their swimming pool instead of fixing real-world problems.
I prefer to solve real problems, for real people, right now.
If you’ve been burned by a fraudlent Southington fintech, get in touch with me.
Nabeil Sarhan, MBA, is a dynamic technology delivery manager with over 15 years of experience in tech, cybersecurity, and computing scalability. He excels in leading diverse teams and delivering enterprise-class systems across industries such as healthcare, finance, and retail. Nabeil’s passion for solution design, systems architecture, and performance optimization makes him a sought-after consultant. He holds degrees from Harvard, MIT, and Bryant University. Connect with Nabeil on LinkedIn