The operating model that survives the reorg: process as data
Every process documented as prose breaks on contact with change: the wiki says one thing, the dashboard implies another, and the truth lives in someone's head. I turned the operating model into a versioned data contract, so change arrives as a config diff instead of a re-briefing.
The setup
The org changed constantly. Reorgs, leadership transitions, tool swaps, and then an AI-first strategy arriving mid-flight. None of that is unusual for a public tech company. What made it expensive was how change landed.
Every process was documented as prose, and prose breaks on contact with change. Update the wiki and the dashboard now implies something different. Update the dashboard and the onboarding deck is stale. Miss one surface and the truth quietly relocates to someone’s head. People called the resulting exhaustion “change fatigue,” and the standard diagnosis was that people resist change.
I didn’t buy the diagnosis. Change fatigue wasn’t caused by change. It was caused by change arriving inconsistently across surfaces, plus mid-cycle rug pulls and the relearning cost of every inconsistency. Those are design flaws, not character flaws.
And the stakes were about to jump. A tooling workstream was starting to build automation on top of the process. Automating a process that shifts underneath its documentation is how you get confident, automated wrongness at scale.
Where I came in
I had built the quarterly planning system and the lifecycle underneath it (both are their own case studies). This work is the layer that makes them durable: turning the operating model from documents into architecture. Nobody asked for it. I saw that everything I had built would erode the same way every previous process had, and decided the fix was structural.
A process document describes the system. A data contract is the system. Everything else is a rendering.
The design bet: if every gate criterion, artifact requirement, and ownership rule lives in one versioned, machine-readable place, then documents, dashboards, and AI assistants all become renderings of that contract. You regenerate them; you never hand-edit them. Change becomes one edit that propagates, instead of a scavenger hunt across surfaces.
What I built
The process data contract. Every gate criterion encoded as an artifact plus a required state, each carrying its owner, the phase it’s initiated in, the phase it must be complete by, the gate it blocks at, and its source system. One versioned, reviewed edit point. The contract is the canon; every other surface is downstream.
The invariants/parameters split. Five invariants that never change, published to the org as a stability promise. Everything else is an explicit parameter with a named edit point. I split it this way because flexibility without invariants isn’t adaptability, it’s drift, and people can’t absorb change gracefully unless something is guaranteed to hold still.
Seven enumerated change scenarios. A ceremony can’t run full size. Pressure to skip a gate. A rename. A new artifact. AI takes over producing an artifact. A tool swap. A reorg. For each: what changes, what holds, and the single edit required. A model is only as flexible as its enumerated answers, and enumerating them in advance turns the next surprise into a lookup.
The AI-readiness design. Gates assert artifact states, not authorship. When AI takes over producing an artifact, nothing in the contract changes, because the contract never cared who wrote the document, only whether it reached the required state. Verification is what makes delegation to AI safe. The endpoint isn’t fewer gates; it’s gates that cost minutes.
The workstream interface. The tooling workstream builds against parameters instead of prose that shifts under them. Process changes arrive as config diffs, not re-briefings. Change requests route in both directions as proposed edits, reviewed and versioned like any other change to a contract.
Making it stick
The hardest moment in this story was organizational, not technical. A parallel workstream began building tooling with overlapping vocabulary and no reference to the existing architecture. The default script for that situation is a turf war, and turf wars burn the credibility of both sides.
I didn’t contest ownership. I positioned the data contract as the canonical interface, and their tooling became an implementation consumer of the process architecture. The handoff was a spec, not a negotiation. I made the interface the resolution mechanism. When two teams disagree about who owns a system, giving them a contract to build against is usually a better answer than giving them a meeting to fight in.
The invariants did adoption work too. Publishing “these five things will not change” bought the trust that made every parameter change cheaper, because people stopped bracing for rug pulls.
Impact and results
The contract became the build spec for the tooling workstream. Handed over as a versioned document, not a series of briefings. Another team now builds against an interface I designed, which is what canonical means in practice.
Change fatigue got reframed org-wide. From “people resist change” to a design constraint with named causes and structural answers. That reframe outlives any single process, because it changes what the org considers an acceptable way to ship a change.
One edit propagates. A process change that once meant hunting down every stale copy across wiki pages, dashboards, and decks now means one reviewed edit, with every surface regenerated from it. The scavenger hunt is retired as a category of work.
Reflections
What I’d do again: publish the invariants first. Stability promises are the cheapest trust-building tool I’ve found, and trust is what makes the flexible parts flexible.
What I’d do differently: version the contract from day one instead of retrofitting history. The versions I can reconstruct are fine; the ones I recorded as they happened are evidence.
Where it’s going: the contract is what makes the AI layer safe. An assistant that answers process questions from a versioned canon can decline to improvise. That story continues in the AI-native operations case study.