Anand Naidu is a seasoned hand in the trenches of both frontend and backend development, bringing a rare, holistic view of how modern systems fail and function. Having spent years navigating the labyrinth of distributed architectures, he has witnessed firsthand how even the most sophisticated dashboards can leave engineering teams in the dark during a crisis. His expertise lies in bridging the gap between raw telemetry and actionable human insight, making him a pivotal voice in the evolving conversation around operational intelligence and incident response.
We explore the deceptive nature of modern observability, where high-resolution metrics often fail to provide the “why” behind a system failure. The discussion delves into the grueling manual labor of data assembly that senior engineers perform during outages and why the most critical members of a team are often the ones most burdened by fragmented data across various platforms. Finally, we look at the emerging shift toward automated correlation and how separating tedious reconstruction from high-level judgment can save teams from burnout and lost velocity.
Many engineering teams find that even with perfect dashboards, they still spend hours investigating why a service degraded. From your perspective, why does the observability stack often stop short of providing a true explanation for a failure?
I have had a version of this same conversation probably 30 times in the past year with various VPs of engineering and senior SREs. They describe their observability stacks—these beautiful Datadog or Grafana setups that they’ve spent months tuning to perfection—and yet, when the last major incident hit, they were still left scratching their heads. The alert fires in seconds and the dashboard shows exactly where the degradation is happening, but the team still spends two to three hours figuring out the “why” before they can even touch the code. This is because “what is happening” lives in the infrastructure layer—the metrics, traces, and logs—but the “why” often lives entirely outside that bubble, tucked away in a deployment from two days ago or a support queue that spiked before the monitor ever turned red. That vital context isn’t in the telemetry because it was never meant to be, leaving a gap between seeing a problem and actually explaining it.
When a customer-facing incident hits, you’ve talked about a process of reconstruction that happens before any fix is applied. Could you walk us through what that manual correlation actually feels like for an engineer in the heat of the moment?
It is a frantic, high-stakes game of connecting dots by hand while the clock is ticking and customers are complaining. Engineering is usually staring at infrastructure signals, knowing the system is unhealthy but having no idea which specific customers are feeling the pain or what those people reported before the alert fired. Meanwhile, the support team has cases and complaints written in plain language by people describing symptoms they can’t technically name, often knowing something is wrong long before engineering does. Somewhere else, tucked away in a Jira ticket or a CI/CD pipeline, is the record of what actually changed, complete with a timestamp and an author. The investigation isn’t actually problem-solving in those first few hours; it’s reconstruction, where someone has to hold all these disparate systems in their head simultaneously until a pattern finally surfaces.
You’ve noted that this investigation work systematically falls on the most consequential people in an organization. What are the long-term hidden costs of pulling these high-context experts into the weeds of data assembly?
This is the part of the industry that I believe gets systematically under-reported and ignored. This manual correlation work doesn’t fall to someone with spare capacity; it routes directly to the engineer who knows the system well enough to read across different views, like the veteran who remembers what shipped last week and why it was unusual. That person is pulled away from their actual work not because they are available, but because the investigation requires their specific, deep context. This creates a structural feature of incident response where your most consequential people are constantly stuck in the war room, leading to a quiet attrition of senior talent who have been through the fire one too many times. These hours spent reconstructing timelines are hours they aren’t spending on innovation, and that cost compounds over time, showing up in decreased velocity and recurring issues rather than the MTTR metrics organizations usually track.
There’s a crucial distinction between human judgment and data assembly that often gets bundled together during an incident. How would the workflow change if we treated these as two separate tasks?
Right now, the person who has the judgment to decide whether to patch a system or roll it back is also the one forced to do the mind-numbing labor of data assembly. Deciding which alerts are noise and which customers are truly affected requires years of developed intuition, but cross-referencing timestamps across Salesforce and a deployment dashboard is just tedious work. This assembly work is what consumes the first two to three hours of almost every serious incident I’ve seen, and it is far below the capability of an experienced engineer. If we separate these, the engineer arrives in the war room with a structured, pre-assembled view of the deployment history and customer cases already mapped to the timeline. Their job shifts from being a manual data-gatherer to a high-level decision-maker, which is the reason they became an engineer in the first place.
As organizations move toward what you call operational intelligence, what does the ideal integration look like between support tickets, deployment records, and infrastructure signals?
The ideal setup is a category of tooling that sits across your observability, ticketing, and deployment systems to do the cross-referencing automatically before a human ever has to open a second browser tab. The signals that explain why an incident happened are already sitting in your systems; they’ve been there since before the alert even fired, but they’ve just never been assembled in one place. When you have software that can bridge the gap between a support lead’s technical hypothesis and a record in a CI/CD pipeline, the entire picture changes for the response team. The real leverage in the future of incident response isn’t going to come from having “better” engineers, but from recognizing that the investigation itself is a workflow that can be automated, allowing the human to focus on refining the solution.
What is your forecast for the future of incident response?
I believe we are entering an era where the “investigation” phase of an incident will no longer be seen as an inevitability, but as a solvable data correlation problem. Over the next few years, as AI-driven correlation tools mature, the organizations that thrive will be the ones that have successfully separated data assembly from human judgment. We’ve seen the observability stack mature significantly over the last decade to tell us that something is happening, and now the focus is shifting entirely to the context that explains why. My forecast is that we will stop measuring success purely by how fast we can fix a known problem and start measuring how quickly a system can present a complete, narrated timeline of an event to the person responsible for fixing it. This shift will finally allow our most senior engineers to step out of the constant cycle of manual reconstruction and back into the work of building resilient, forward-thinking architecture.
