Shiva Gangaraju, who works in enterprise systems at Ping Identity, has a specific view on why technically correct software can still fail an organization: the flaws that matter most rarely show up until a system is under real pressure.
A Milestone Framework That Broke Under Pressure
That view traces back to a specific incident. During a customer outage tied to a strategic commercial engagement, Gangaraju says, which was valued at approximately 3.5 million dollars, he identified an architectural limitation in Salesforce’s standard milestone framework, the system used to track whether support cases are meeting their response-time commitments. The framework allowed a customer’s own reply to a case to prematurely satisfy the milestone tracking and an engineer’s required response, even when no engineer had actually responded yet.
The effect was quiet but serious. Because the milestone appeared satisfied, the system stopped generating the operational alerts that would normally flag a case falling behind. SLA reports showed cases as on track when they were not; engineering responses were delayed without anyone receiving an automatic warning; and the gap between what the dashboard showed and what was actually happening on the ground widened until the case escalated into a full customer crisis.
Separating Two Things That Look Similar But Are Not
Gangaraju’s fix addressed the root cause rather than patching the symptom. He designed a centralized milestone management architecture that separated customer interactions from engineer response events entirely, two categories of activity the original framework had effectively treated as interchangeable. Under the new design, a customer replying to a case no longer had any bearing on whether the engineer-response milestone was considered met, and SLA pause and resume behavior was instead controlled automatically based on the actual operational state of the case.
That separation restored something the original system had quietly broken: an accurate link between what the SLA dashboard reported and what was actually happening in the support queue. It also preserved automated alerting through PagerDuty, the tool engineering teams rely on to get paged when a case needs attention, which the flawed milestone logic had been silently suppressing.
“A solution that appears technically correct may create operational challenges years later if the broader business context is not considered,” Gangaraju says, describing the pattern behind the incident more broadly rather than this case specifically. A milestone framework can pass every test written for it and still fail in production, if the tests never modeled the specific sequence of events, a customer replying before an engineer does, that breaks the underlying assumption the framework depends on.
Why the Distinction Matters Beyond One Case
The incident illustrates a problem that is easy to describe in the abstract and easy to miss in practice: two events that look similar on the surface, a customer message and an engineer response, can carry very different operational meaning, and a system built without that distinction will eventually produce reporting that looks fine right up until it does not. Gangaraju has said his broader approach to enterprise architecture treats this kind of gap, between what a system reports and what is actually true, as one of the more consequential failure modes in large-scale software, because it tends to surface only under the exact conditions, a real crisis, where accurate information matters most.
The fix, once identified, was not especially complicated. Separating two categories of event that had been conflated is a narrow, specific correction. What made the underlying problem hard to catch in the first place was that it required no unusual load or edge case to trigger, only the ordinary and common sequence of a customer replying to a support case before the assigned engineer had a chance to respond, a sequence that happens constantly in any active support queue and had been quietly generating misleading data the entire time.
That gap between simplicity of the fix and difficulty of the diagnosis is, in Gangaraju’s telling, characteristic of enterprise architecture work more broadly. The systems involved are rarely exotic. Salesforce’s milestone tracking framework is standard, widely deployed infrastructure used across countless support organizations. The failure mode it produced under this specific sequence of events was not a defect anyone had built into the system deliberately, but a gap between how the framework was designed to be used and how customer support interactions actually unfold in practice, one that only became visible once a high-stakes engagement pushed the system hard enough to expose it.
