06-reference

commoncog executing data driven technicals

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

“Executing on Becoming Data Driven: The Technicals” — @CedricChin

Why this is in the vault

This is the technical companion to Chin’s “Politics” piece and the how-to bridge between 2026-04-15-commoncog-becoming-data-driven-first-principles and the WBR deep-dives. The full article (not the paywalled excerpt we had before) is a step-by-step field manual: start from the causal model in the operator’s head, attach output metrics, propose controllable input metrics as embedded hypotheses, commit operational definitions to a central place, instrument cheaply, and — critically — take action, because causal structure only reveals itself when you change things. Every one of those steps maps cleanly onto an agent-deployer’s first 90 days with a client, which makes this the single most operationally useful Commoncog piece in the vault for MAC delivery.

The core argument (paraphrased)

The technical work of becoming data-driven starts by drawing the causal loop of the business you already believe you have, then systematically testing it.

Chin’s opening move: “everyone has a causal model of their business in their heads” — even if parts are superstition, start there, because surfacing it forces the team to check they share the same model. His own Commoncog example exposes an immediate uncertainty: does a visitor become a newsletter subscriber then a paying member, or go directly to paying? “The truth is that I simply don’t know.” That admission is the point — if the operator of a simple content business can’t name the loop, no larger business can without doing this work.

The pipeline he prescribes:

  1. Draw the growth loop explicitly. Not a funnel — a loop. “Every business has a core growth loop.”
  2. Attach output metrics to each step. These are lagging indicators, and per Goodhart you do not drive them directly. They are the scoreboard, not the lever.
  3. Propose controllable input metrics as embedded hypotheses. “You’re likely going to pick the wrong controllable input metrics.” That’s fine — each is a hypothesis that moving the input will move the output. “You should feel uncomfortable looking at these proposed metrics.” Discomfort is the signal you’re doing it right.
  4. Write operational definitions before collecting data. Per Deming: “a procedure agreed upon for translation of a concept into a measurement.” Three parts: a criterion, a test of compliance, a decision rule. Bryar told Chin that “How are you measuring that?” is the most common question in an Amazon WBR. Skip this and you’ll spend every meeting quibbling over the data.
  5. Watch for silos. Deming’s “Understanding of a System” — you do not tune one department’s metrics in isolation. Wheeler’s entire chapter tells the story of a department that drove its material costs down and inadvertently reduced business-unit margins. This is why the WBR pulls every department’s metrics into one deck and requires every leader present.
  6. Instrument cheaply. Early Amazon ran the WBR off Excel with Finance manually pasting in weekly data and printing decks on paper. “The issue here is discipline, not technical sophistication.” Chin’s own stack is Posthog + Google Sheets + a CSV-and-YAML WBR tool — “data engineering equivalent of chewing gum and duct tape.”
  7. Take action. “Causal structures are revealed when you change things.” Analysis without intervention produces no knowledge. XmR charts are how you tell whether the action moved the output.

Chin closes with Bryar’s suggestion to instrument the P50 / P90 number of articles read before a reader becomes a subscriber — illustrating that the real work is chains of trial and error to find which input metrics move which outputs, and which qualitative reader-actions signal value received. “All of these things are going to take months.”

Mapping against Ray Data Co

Strong mapping — implementation-level. This article gives us the step sequence for the first 90 days of an agent-deployer engagement.

1. Engagement Session 1 deliverable: the causal loop, on a page. Before MAC cells are written, before any agent is deployed, the agent-deployer runs a workshop where the client team draws their business as a growth loop — not a funnel, not an org chart. The output is a single diagram with steps labelled and the loop closed (revenue → capability → acquisition → revenue). Divergence in the room is the point — Chin’s Commoncog admission (“I simply don’t know which model is correct”) is what we want the client to surface out loud. This becomes the seed document in the client-owned vault per ../04-tooling/rdco-state-ownership-architecture.

2. Session 2: output metrics mapped to loop steps. Session 3: controllable input metrics, flagged as hypotheses. The agent-deployer’s job is to resist the phData reflex of jumping to dashboards. Each controllable input metric gets registered as an embedded hypothesis — “we believe moving X moves Y.” The MAC matrix ../01-projects/data-quality-framework/testing-matrix-template then instruments each link in the chain. When the hypothesis fails, that MAC cell is the evidence; the causal model updates. This reframes MAC from “quality checks” to “epistemic instruments against stated hypotheses.”

3. Operational definitions become a first-class artifact in the client vault. Chin’s three-part definition (criterion / test of compliance / decision rule) is a near-perfect template for a vault schema. Every metric the client tracks should have an operational-definition doc with those three headings. This is the artifact that kills the WBR-killer question “how are you measuring that?” before it’s ever asked. Concrete proposal: 06-reference/operational-definitions/ folder in the client vault, one doc per metric, linked from the causal-loop diagram. This is a deliverable, not a best practice — the agent-deployer writes the first ten with the team and the team owns the rest.

4. The phData/MG contrast, sharpened with teeth. Traditional data consultancies sell (a) tooling, (b) dashboards, (c) data-warehouse consolidation. None of those three artifacts appear in Chin’s pipeline until step 6, after the causal model, output metrics, controllable input metrics, and operational definitions are in place. RDCO’s wedge is the first five steps. We do not compete with phData on warehouses; we do the layer underneath that makes warehouse work stick. An RDCO engagement that ends at step 5 has delivered more durable value than a phData engagement that delivered a warehouse.

5. “Start ugly” is permission to ship in week one. Chin’s duct-tape stack (Posthog + Sheets + CSV/YAML) is the template for the agent-deployer’s first instrumentation pass. The MAC pilot does not need Snowflake; it needs a spreadsheet the client can read and an agent that can write to it. Ship the first WBR-equivalent review in week 2 on whatever data is available, even if it’s manually exported. Discipline over sophistication. This protects the engagement from the common failure mode of spending months on data plumbing before producing any knowledge.

6. Silo-watch is the argument for cross-functional MAC deployment. Wheeler’s story (department optimizes, business unit loses) is the defensive frame against a single-team MAC pilot. The agent-deployer’s pitch must include every functional leader in the weekly review — same as Amazon. If a client tries to scope the pilot to one team, flag it: the SPC literature predicts this scope will produce local optimization that hurts the whole. Cross-functional attendance is a non-negotiable term of engagement.

7. “Action over analysis” is the anti-dashboard clause. Chin is explicit: analysis without intervention produces no knowledge. The agent-deployer’s weekly cadence must include a decided action, not just a metric review. MAC-triggered Stop/Pause/Go severity tiers fit this directly — a Stop is an action, a Pause is a scheduled action, a Go is the null action. This makes the MAC framework structurally compatible with Chin’s final principle: every week ends with a change to probe, not just a chart to admire.

8. The Bryar-on-Commoncog story is the agent-deployer’s coaching mode. Bryar, looking at Chin’s diagram for 60 seconds, proposed instrumenting P50/P90 articles-read before subscription. That move — reading the loop and proposing a specific latent metric — is the senior consultant’s craft move. An agent-deployer with strong Commoncog literacy can do the same in a client engagement. Add this as a competency to the agent-deployer JD (2026-04-14-levie-agent-deployer-role-jd): “can read a causal-loop diagram and propose non-obvious latent metrics that reveal reader/customer value delivery.”

One caution for the curriculum: Chin says the work takes months and is constrained by concurrent-experiment count (he runs a limited number of experiments at once, on purpose). The coaching curriculum must set this expectation with the client up front, or the engagement will be judged on the dashboards-in-week-two standard instead of the causal-model-in-month-six standard. Sell the months, not the weeks.