Ethics & Economics
The urgency test: how fast you fix known harm
How fast you fix a known harm is the truest statement of your values. Delay is a decision, and everyone inside the company can read it.
When an organization learns that something it built is hurting customers and lets it keep running, the delay itself is a value statement. Metrics showing no long-term impact measure what the company chose to count, not human impact. Speed of response to known harm is the most honest ethics metric a leadership team has.
When Meta discovered an algorithmic bug boosting harmful content, the problem stayed live long after it was known internally. The public fix came only under political and press pressure, and the internal justification leaned on metrics showing no long-term impact. That episode names a general pattern: leaving a known harm running is a controlled experiment on your own customers. The urgency test asks one thing of an organization. When you learn that something you built is hurting people, how fast do you act? If the harm were truly unintended, the response would be immediate. Delay is a decision, and it reveals where customer welfare actually ranks against revenue, engagement, and optics.
Why it matters to the business
Executives consistently misjudge how much trust they have to spend. PwC's 2024 Trust in US Business Survey found 90% of executives believe customers highly trust their company while only 30% of consumers agree, and 40% of consumers have stopped buying from a company they did not trust. A visible delay on a known harm converts the 60-point gap PwC measured into churn.
Regulators have also started billing for it. The FTC's settlements with Epic Games ($520 million) and Amazon ($2.5 billion, over its Prime cancellation flow) show that harmful designs left running accumulate liability, not just reputational risk. The cost of the fix is roughly the same whether you move now or after the headlines. The cost of the delay only grows.
How to use it
- Keep a live register of known customer harms, each with a severity rating, a named owner, and a fix date.
- Set a fixed internal deadline: confirmed harms preempt the roadmap, the way security incidents do.
- Ban 'metrics show no long-term impact' as a closing argument. Metrics count what you chose to measure, not human impact.
- Report time-from-detection-to-fix to the executive team as a standing governance metric.
- After every incident, review why the delay happened, not just what broke.
Where teams get it wrong
Teams wait for external pressure to set the priority. By the time a journalist, regulator, or viral thread forces the fix, the organization has already taught its own people that harm is acceptable when the dashboard looks fine. That lesson outlasts the incident and quietly lowers the bar for the next decision.
Ask your team
- What do we currently know is harming customers, and what is the fix date for each item?
- What is our oldest known, unfixed harm, and why is it still live?
- Have we ever kept something running because metrics showed no measurable damage?
If the harm were truly accidental, the response would be immediate. Delay is a decision.
Apply this
Reading about the urgency test: how fast you fix known harm is one thing. Seeing where it applies in your journey is the useful part.