> ## Content Index
> Fetch the complete content index at: https://contextfirst.blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 393 Failures, 27 Root Causes - Triage by Spread, Not Volume
- URL: https://contextfirst.blog/spread-triage-393-to-27/
- Published: 2026-09-11T13:00:00.000Z
- Updated: 2026-09-11T13:00:01.000Z
- Description: Rank by contexts blocked, not row count
- Author: Iheatu Chris Wogu
- Tags: Field Notes, Engineering Management, Agentic Delivery, Learning Journey 2026

Three hundred ninety-three red rows look like hundreds of distinct bugs. Leadership says fix everything. Teams treat symptoms. A week later the same capability path fails in another locale. The dashboard lied about **volume**; the leverage was in **spread**.

**Here's what this piece covers:** why volume prioritization fails, what the Jun 2026 L4 analysis showed (393 → 27), the manager-level algorithm, the named pattern, and three habits for cert weeks. Companion to [tiered E2E L0–L4](https://contextfirst.blog/e2e-l0-l4-ninety-two-sites/).

Part of [Field Notes: agentic delivery](https://contextfirst.blog/field-notes-agentic-delivery/).

---

## 1\. The leadership problem

Red dashboards demand "fix everything." Engineers open the top ticket by raw count - often the tenth instance of a root cause that already blocks thirty contexts. Local fixes reopen across brand × region × browser while the systemic bug stays open.

**Wrong:** "393 failures."  
**Right:** "\~27 root causes - the same listing-filter failure counted thirty times; fix spread, clear the matrix."

The anti-pattern is **volume prioritization** \- chasing row count while the high-spread root still blocks the release.

---

## 2\. What the portfolio shows

Documented in `docs/e2e-program-portfolio-summary.md` and measured in `docs/polaris-repeat-issues.md` (generated **2026-06-22**):

| Metric                       | Value                                                                             |
| ---------------------------- | --------------------------------------------------------------------------------- |
| Total failing occurrences    | **393**                                                                           |
| Distinct issues (signatures) | **27**                                                                            |
| Issues spanning >1 context   | 25                                                                                |
| Widest single-issue spread   | **30** contexts                                                                   |
| Algorithm home               | docs/repeat-issue-algorithm-spec.md (port of analyze\_polaris\_repeat\_issues.py) |

One shared frontend codebase, many regional sites as configuration - same failure mode as [article 06](https://contextfirst.blog/e2e-l0-l4-ninety-two-sites/): fix one market, break another. Spread triage answers **which fix clears the most red cells**.

flowchart TD R\[393 raw failure rows\] --> G\[Group by signature\] G --> S\[Rank by distinct contexts\] S --> T\[Top spread = systemic\] S --> L\[Low spread = local\] T --> F\[Fix root once\] F --> C\[Clear matrix cells\]

---

## 3\. What I built: spread vs volume

| Lens       | Measures                                                            | Mistakes it causes                                          |
| ---------- | ------------------------------------------------------------------- | ----------------------------------------------------------- |
| **Volume** | Count of failing test rows                                          | Staff the loudest stack of duplicates                       |
| **Spread** | Distinct brand / region / viewport / browser contexts per signature | Surfaces the handful of roots that unblock the most markets |

A systemic bug produces hundreds of rows. A local bug produces one. Ranking by distinct contexts is how triage meetings stop arguing about noise.

Top signatures in that L4 cut were capability-path failures - listing sort/filter controls, search landing on a product grid, mobile nav affordances - each repeating across brands, regions, and browsers. Fix the root once; up to **thirty** contexts go green.

```python
def issue_key(failure):
    # Do not key on raw "toBeVisible failed" alone - thousands share it.
    return f"{failure.file} › {failure.title} :: {normalize(failure.error)}"

def context_hash(brand, region, viewport, browser):
    return sha1(f"{brand}|{region}|{viewport}|{browser}")[:12]

def rank_by_spread(errors_map):
    return sorted(
        errors_map.items(),
        key=lambda kv: len(set(kv[1])),
        reverse=True,
    )
```

Manager-level loop: ingest Playwright brand-report JSON → group by signature → rank by distinct contexts → ship a leaderboard of highest-leverage fixes. Bug-grouping notes (e.g. Jun 24 buckets) pair the same idea for ticket intake - one SEO/hreflang root, many market clones.

---

## 4\. Named pattern: spread triage

> **Spread triage** \- rank by contexts blocked, not row count - \~27 root causes, not 393 tickets.

| Outcome narrative                             | Confidence                                                             |
| --------------------------------------------- | ---------------------------------------------------------------------- |
| 393 → 27 distinct issues                      | **Verified** in polaris-repeat-issues.md (2026-06-22)                  |
| \~90% noise reduction in triage meetings      | **Team-measured** (portfolio narrative)                                |
| Part of broader \~35% defect-intake reduction | **Team-measured** \- verify baseline before citing outside this series |

**What broke:** without root-cause IDs on tickets, the same path reopens as "new" work. Recurrence and chronic clusters get their own treatment in [article 20](https://contextfirst.blog/chronic-regression-3403-tickets/).

---

## 5\. What I'd do as a lead

Three habits - steal one this cert week:

1. **Never prioritize by raw failure count alone.** Ask for spread before staffing.
2. **Staff one "spread captain"** during cert weeks - owns the leaderboard, kills duplicate tickets.
3. **Close the loop:** tag a root-cause ID in the tracker so recurrence is measurable, not folklore.

---

### Further reading

- Previous context: [Tiers beat the full matrix](https://contextfirst.blog/e2e-l0-l4-ninety-two-sites/)
- Upcoming: [Chronic regression across thousands of tickets](https://contextfirst.blog/chronic-regression-3403-tickets/)
- Planning: `docs/polaris-repeat-issues.md`, `docs/repeat-issue-algorithm-spec.md`, `docs/e2e-program-portfolio-summary.md`

---

![Iheatu Chris Wogu](https://avatars.githubusercontent.com/u/3457705?s=176&v=4)

## About the author

**Iheatu Chris Wogu** is an engineering manager focused on launch programs, honest engineering metrics, and **engineering-led, agent-accelerated** delivery - researching where work queues up when agents widen dev output, then building proof, gates, and measurement that scale.

Field notes live on [First Context](https://contextfirst.blog/). Values treatise: [engineering manager values](https://contextfirst.blog/engineering-manager-values/).

**LinkedIn:** [linkedin.com/in/iheatu-chris-wogu](https://www.linkedin.com/in/iheatu-chris-wogu/?ref=contextfirst.blog)