Disaggregate

Disaggregate

A single average is where false consensus gets manufactured. "Net positive for workers" can hide a 16% employment drop for one age cohort and a raise for another. "The model is 90% accurate" can hide a 40% miss rate for the group that matters most. The average isn't wrong so much as it's a claim about a fictional average person nobody is. This skill forbids the aggregate-only verdict and forces the question the average erases: positive or negative for whom?

The rule

No verdict ships as a population-wide average. Before stating any "X does Y to Z," run Z through the disaggregation dimensions below and report a separate directional call for each slice where the effect plausibly differs. If the slices agree, that agreement is itself a finding worth stating. If they diverge — and they usually do — the divergence is the answer.

The six dimensions

Not every dimension applies to every question. Run through all six, keep the ones that move the outcome, and say why the others don't:

1. Geography / development tier — rich vs. emerging vs. low-connectivity regions. The gap between them is a first-order finding, not a footnote. A tool that helps most where infrastructure is thinnest often reaches there last.
2. Socioeconomic strata — income, wealth, education, capital ownership. Winners and losers of any efficiency gain are rarely symmetric; ask who captures the surplus.
3. Power position — labor vs. capital, incumbent vs. challenger, platform vs. user, state vs. citizen. The same change strengthens one side of each pair and weakens the other.
4. Time-in-adoption-curve — early adopters vs. laggards experience different, sometimes opposite effects during a transition. A first-mover's advantage is a late-mover's disruption.
5. Demographic — age/cohort, gender, race. Early-career and established workers can see opposite effects from the identical change; effects often concentrate on one group.
6. Institutional capacity — whether the surrounding institution (a hospital, court, school, agency) can integrate the change well or badly. The same tool helps a well-run system and harms a fragile one.

Compounding: the trap disaggregation exists to catch

Slices are not independent. When disadvantages stack on the same group, the combined effect is worse than any single stat shows — and invisible in every aggregate. Example from the source material: women's occupations are more exposed to automation (≈29% vs. 16%), women adopt the assisting tools ≈25 points less, and AI-skill wage premiums favor the adopters. That's one compounding freedom-contraction, not three separate statistics — but only disaggregation across gender + exposure + adoption makes it legible. Always check whether your slices land on the same people.

Procedure

1. State the aggregate claim you were handed or about to make.
2. For each of the six dimensions, ask: does the effect plausibly differ across this axis? Keep the ones that do.
3. Give each retained slice a directional call (helps / mixed / harms) and a confidence (pairs with grade-the-evidence).
4. Check for compounding — do the negative slices concentrate on one group?
5. Report convergence explicitly where slices agree; label sharp divergence explicitly where they don't.
6. Replace the original aggregate with the disaggregated verdict. If a one-line summary is required, make it name the divergence, not paper over it.

Output template

AGGREGATE CLAIM: <the single-number / single-verdict version>

DISAGGREGATED:
  Geography:      <slice> → helps | mixed | harms  (conf: …)  — <why>
  Socioeconomic:  <slice> → …
  Power position: <slice> → …
  Adoption stage: <slice> → …
  Demographic:    <slice> → …
  Institutional:  <slice> → …
  (drop dimensions that genuinely don't differentiate — and say so)

COMPOUNDING: <do negatives stack on one group? name it>
VERDICT: <the honest summary — names the divergence, not an average>

Example

Input: "AI coding assistants make developers more productive."

Disaggregated:

AGGREGATE CLAIM: AI coding tools boost developer productivity.

DISAGGREGATED:
  Task type:    boilerplate/greenfield → helps a lot (+55% on some tasks);
                complex work in a familiar, idiosyncratic codebase → can slow
                seniors down (a controlled study found −19%: verification
                overhead exceeded time saved).
  Demographic:  junior devs on new code → largest gains; senior devs on
                deeply-known systems → smallest or negative.
  Institutional: teams with review/verification infra → capture gains safely;
                teams without → ship more vulnerabilities faster.
  Adoption stage: shadow users already fluent → real value; mandated rollout
                without workflow redesign → most of the measured 95% pilot-
                failure rate.

COMPOUNDING: the "it's slower for me" cases cluster on exactly the
  experienced engineers orgs most trust to evaluate the tool — so the
  aggregate and the expert impression can disagree.
VERDICT: Not "boosts productivity." It compresses routine and novice work,
  and can tax expert work on familiar systems — the sign depends on task
  novelty, seniority, and whether verification exists.

Gotchas

• Don't manufacture slices to seem thorough. If an axis genuinely doesn't differentiate, say so in one line and move on. Six real slices beat sixteen padded ones.
• Disaggregation is not "it depends." Each slice gets a directional call, not a shrug. "It depends" is the failure this skill prevents; "helps A, harms B, here's why" is the deliverable.
• The average can still be worth reporting — as one line among the slices, never as the verdict.
• Pairs with grade-the-evidence (each slice needs a confidence) and value-frames (a slice can be "good" under one value and "bad" under another).