06-reference

commoncog story about process improvement

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

“The Disaffected PhD Skunkworks: A Story About Process Improvement” — @CedricChin

Why this is in the vault

A concrete companion to Chin’s theoretical process-improvement essays — useful as a story the vault can cite when arguing why RDCO’s MAC practice has to be smuggled in under air cover in early engagements. Mapping strength is medium: the parallel is structural (hidden process-improvement work funded by line-of-business cover) rather than substantive (the article isn’t about data or AI).

The core argument (paraphrased)

Chin tells the story of Colleen Byrum and Jane Slade at early Amazon (1996). Customer service was five generalists at X-term command lines drowning in post-WSJ-profile traffic. Engineering refused to allocate resources: “suck it up, buttercup.” Byrum’s response was what she privately called the “disaffected PhD skunkworks” — she recruited unhappy grad students out of UW, seated them in CS answering emails half the day, and handed them books on Perl and SQL for the other half. That hidden team built the automation tooling CS needed, checking code into “the main pile of untested and ungovernable code that was the Amazon website.”

Chin pairs this with the Du Pont Manufacturing Game story from the Repenning/Sterman paper he covered previously. The common thread across both positive process-improvement stories is air cover: either you win management buy-in to absorb the short-term maintenance losses, or you hide the improvement work inside a line-of-business budget. Chin: “You need some free energy to invest in process improvement… either you buy cover for the inevitable short term losses, or you hide your improvement activities.”

He closes with a side anecdote — a manager who “kept an intern in reserve, every couple of months, hidden from upper management” to work on CI/CD and test tooling. Chin’s claim: this pattern is universal across every real process-improvement story he knows.

Mapping against Ray Data Co

1. The MAC engagement needs air cover, not a kickoff deck. RDCO’s consulting posture assumes a client sponsor who says “yes, we’re going to adopt Model Acceptance Criteria.” Chin’s story warns that the real-world version is messier: the first instantiation of MAC inside a client org will probably be one analyst running it on their own models, hidden inside normal BAU time, until the savings become visible enough to surface upward. The ../04-tooling/rdco-state-ownership-architecture handoff model should explicitly support this “skunkworks” mode — client owns the vault and skills, so the practice can start small without a formal program. Translate this into the coaching curriculum: teach the analyst how to buy themselves cover, not just how to run the matrix.

2. The phData vs MG decision is partly a question of who provides air cover. phData is a large consulting firm with process machinery; MG is a smaller shop. Byrum’s story suggests process improvement survives better when it’s protected by a single operator willing to hide the work — which is closer to MG’s shape than phData’s. Worth flagging in the active phData-vs-MG eval: which partner is more likely to let a single analyst run a quiet MAC pilot before the org commits formally? That is the real test, not the size of the statement of work.