06-reference

commoncog process improvement is hard

Tue Apr 14 2026 20:00:00 GMT-0400 (Eastern Daylight Time) ·reference ·source: Commoncog ·by Cedric Chin

“Process Improvement is Trickier Than You Think” — @CedricChin

Why this is in the vault

Chin summarizes the canonical Repenning/Sterman 2001 paper (Nobody Ever Gets Credit for Fixing Problems That Never Happened) and names the self-reinforcing dynamic — the capability trap — that kills continuous improvement in nearly every company that attempts it. Directly diagnoses the #1 deployment risk for RDCO’s MAC consulting posture: clients who can’t carve out the ~20% time-on-the-work will default into a feedback loop that actively rewards skipping it. This is the companion “why it fails” piece to Chin’s first-principles article on SPC/WBR.

The core argument (paraphrased)

Process improvement fails for systemic reasons, not because managers are lazy — and the system is set up to reinforce the wrong conclusion.

Chin opens with a familiar experience: walking into a company and thinking “the processes here are really good”, with his instinctive follow-up — “who designed this, and how can I speak to them?” Good processes rarely emerge on their own; someone drove the trial-and-error loop. The contrast case is the company where “this is the way things have always been done” and nobody spends any time thinking about improvement.

His thought experiment: pick any process you run and ask when it was last improved, how often you improve it, and if you have an idea, why it hasn’t been implemented. The honest answer is that improvement only happens during a lull, because “it takes considerable effort and work to change it.”

Then the punchline on continuous improvement: it means “one out of every five days is spent not doing the work, but working on the work” — forever, crunch be damned. Described that concretely, “continuous improvement” stops sounding like a platitude.

Repenning and Sterman’s capability trap (the paper Chin summarizes):

The authors open with a provocation: careful studies show TQM firms outperform their competitors, yet fewer than 10% of Fortune 1000 companies have well-developed TQM programs. Most improvement programs get branded fads — “old ideas with new acronyms” — when in fact their underlying content is sound. The failure is organisational, not methodological.

The dynamic, compressed:

  1. There are two ways to improve productivity: work harder, or improve the process. When demand outpaces capacity and you can’t hire, managers must choose between a “better before worse” path (invest in improvement, accept short-term degraded output) and a “worse before better” path (squeeze harder, defer improvement).
  2. Managers almost always pick the latter, because process improvement isn’t guaranteed (experiments fail, tools disappoint) and its payoff is delayed, while “work harder” produces immediate results.
  3. Whichever option gets picked reinforces itself. Working harder runs down people and machines, which creates more firefighting, which forecloses improvement time further. Meanwhile, organisations that somehow invest in improvement get virtuous-cycle capability gains that free up more improvement time.
  4. The negative loop is the default outcome because people take shortcuts under pressure — cutting maintenance, skimping on documentation — producing short-term productivity gains that come due later as debt.
  5. The “depressingly sad org psychology” kicker: managers don’t learn to self-correct because the feedback signal is corrupted. When they turn up pressure, throughput rises — but they can’t see that much of the rise came from workers quietly cannibalising training, experimentation, and maintenance time. Chin/Repenning: managers “overestimate the impact of their get-tough policy … by as much as a factor of three.” The get-tough policy appears to work, reinforcing the belief that the problem was lazy workers all along.
  6. Over decades this selects for a heroic-delivery culture. One interviewee: “Our culture rewards the heroes … I’ve delivered programs under duress … Those are the opportunities for advancement.” Senior management becomes populated by war heroes, locking in the “people are the problem, not the system” belief.

Chin’s closing takeaway: you cannot make headway on process improvement until you first defeat the default belief that people are the problem. The art of implementing it is either to carve out “secret” resources for investment, or to convince management that improvement is load-bearing for long-term performance. And — echoing his first-principles piece — these are “deceptively simple, deceptively powerful ideas” from Deming’s lineage that remain almost invisible outside manufacturing.

Mapping against Ray Data Co

1. The capability trap is the default failure mode for every MAC engagement. RDCO’s Playbook + Coaching posture requires the client to commit ~20% of data-team time to running the MAC practice — Chin’s “one day in five.” Repenning/Sterman are clear: that budget will be the first thing sacrificed the moment a crunch hits, and the sacrifice will appear to work in the short term because management can’t observe the cannibalisation. Implication for SOWs: the time commitment can’t be a recommendation, it needs to be a contracted deliverable with a named executive sponsor who owns protecting it. Otherwise the engagement degrades into a skill handoff that silently decays. See ../04-tooling/rdco-state-ownership-architecture — the vault survives the decay; the practice is what’s at risk.

2. “Managers overestimate get-tough by 3x” is the exact argument for state-ownership over more-model. The Repenning/Sterman feedback-loop corruption maps directly onto the phData/MG-style engagement failure mode: client hires consultants, consultants deliver short-term throughput by throwing bodies at the data problem, apparent wins reinforce the “we just needed more hands” conclusion, and the underlying process never gets instrumented. RDCO’s positioning wedge is that the vault + MAC discipline is visible in a way that cannibalisation isn’t — you can see when testing coverage slips. See 2026-04-14-levie-agent-deployer-role-jd — the agent-deployer’s core job is to make the improvement loop observable so it can’t get silently harvested.

3. “Who designed this?” is the consulting origin story, literally. Chin’s instinct that good processes have a driver is the canonical argument for the named operator role. In an AI-agent workflow the driver has to exist or the entire MAC apparatus collapses into “this is how we’ve always prompted.” RDCO’s engagement pattern — embed for 3-6 months, leave behind a vault/skills/driver — is the answer to Chin’s rhetorical question: we are the people you want to speak to, and then we train the person you should speak to after we leave.

4. The heroic-delivery trap is the internal risk for RDCO itself. Chin’s war-hero observation is a warning for the consulting business model too: if RDCO rewards heroic client-rescue engagements, we’ll select for the same dysfunction we’re selling against. The MAC drip course and vault-as-artifact are the anti-heroic design choices — the unit of value is a discipline a client can operate, not a rescue we perform. Worth naming in internal principles; the state-ownership thesis is partly an inoculation against becoming the kind of consultancy Repenning/Sterman would critique.