ANDREW/
← Back to writing

MANAGEMENT / JUDGMENT & FOLLOW-THROUGH

Finding the Cause Is Not the End

Andrew Yuan · Management reflection · 2026.10.06

Finding the cause is an important step. How to deliver a remedy to users, and how the frontline team should handle it, still require decisions.

Contain the impact and keep the investigation moving

In one device stability investigation, the failures were real, but engineering could not reliably reproduce them in internal testing.

I arranged temporary protective measures while coordinating engineering, testing and external partners to continue the investigation.

We had to address the immediate impact and preserve resources for finding the cause. Having temporary protection in place did not end the investigation.

We eventually identified the cause of one category of failures. After that issue was corrected, the device returned to normal operation.

An effective fix still needs a delivery decision

But ordinary users could not carry out that correction themselves. We had found the cause, yet devices already in users’ hands still needed a remedy.

We also tried an update-based approach. Our assessment was that it could introduce many additional issues we did not yet understand, so we did not adopt it.

That was an important decision in the process.

The update approach was worth trying. Adopting it also depended on whether we could understand its effects. The existing problem was already creating pressure; introducing more uncertainty would leave both the team and users to deal with the consequences.

We ultimately chose to handle affected devices through returns and replacements.

Give the frontline team a basis for action

That decision brought more work. The frontline team would encounter similar symptoms, but not every failure had the same cause.

I provided handling guidelines to help the support team distinguish cases covered by this remedy from other failures requiring further investigation.

Looking back, finding the cause was only one stage.

We still had to choose the remedy, define where it applied and give the frontline team a basis for action. Without those connections, engineering could have an answer while users were still left with the problem.

Choosing the remedy did not end our responsibility for the work that followed.

Three questions for your next discussion

These questions extend the reflection above. Adapt them to your team and situation.

  1. Which category of problems does the remedy address? Separate what has been confirmed from the effects that are still uncertain.
  2. Can users actually use the remedy? If they cannot, who will take responsibility for the alternative and the work that follows?
  3. How will the frontline team recognize cases where it applies? Clarify which cases need further investigation and where to turn when the distinction is unclear.

Context

Based on my experience handling the issue, with product names, partner identities and internal technical details omitted. This article focuses on management judgment and collaboration; it does not present the full validation record or the final outcome of the returns and replacements.