Decision distillation as a workshop you can run in a week

Here's the pitch I've made, more times than I can count, to a platform team staring at a process they want to rewrite. Give me a week. Five days, four people, a wall for sticky notes. At the end you'll have a working Decisions as Code surface the team can take to real users and start testing. Not a deck. Not a roadmap. A surface.

Most platform teams have never run this. They've run discovery workshops that ended in a Miro board nobody touched again. They've run prioritization workshops that produced an OKR. The thing they haven't run is the one that produces a thing, a curated decision surface, scoped by who actually decides what, ready to validate with the people whose decisions you've claimed to extract.

This piece is the agenda. Five days, five outputs, the failure modes each day generates.

The setup, before day 1

Four people in the room. The platform engineer who'll own the surface afterwards. A facilitator who hasn't worked on this process before, fresh eyes are non-negotiable. The business owner of the process. And one consumer, the person who currently fills in the form. Four. The workshop scales badly past five; the discussion fragments and you spend day three re-aligning instead of progressing.

You also need a real process. Not a hypothetical. Pick the messiest provisioning workflow, the most-complained-about onboarding form, the intake the request-management team has been promising to fix for two years. The week works on a real artifact or it doesn't work at all.

Day 1. Discovery: catalog every decision

The first day is the dull one and the most important one. The goal is mechanical: catalog every decision currently made anywhere in the process. Not the fields on the form. The decisions. A field is sometimes a decision and sometimes a re-statement of one already made; you sort that out tomorrow. Today you just collect.

The morning is silent capture. Each person walks through the process end to end and writes one decision per sticky. "Which environment does this go to." "Whether it's a production workload." "Whether the request needs CISO sign-off." Hundreds of stickies. Not dozens, hundreds. If you ended the morning with thirty, you didn't go deep enough.

The afternoon is the walk-through: each person presents their stickies, the others add what they missed. The output of day 1 is one artifact, every decision the process touches, on a wall, photographed.

Failure mode for day 1. The team conflates "decision" with "field." The signal is platform vocabulary, replicaCount, instanceClass, tolerations. Plain-language decisions read like sentences: "this is a production workload," "this needs to run in EU." If your wall is full of YAML keys, restart the morning. The wall must be in the user's vocabulary or day 2 will fail.

Day 2. Grouping: cluster by who-actually-decides

Day 2 applies the step-2-of-the-migration move to the wall from day 1. For each sticky, write down (in plain language) who actually decides this. Not who edits the field. Not who fills it in. Who decides.

You'll usually end up with five or six clusters: application team, platform standards, security/compliance, finance/cost-attribution, on-call/operations, and (every single time) "nobody decides this; it's been on the form since 2019 and nobody knows why." Label that one too.

Spend the morning clustering, the afternoon arguing. The arguments are the point. When the platform engineer claims replicaCount is an application decision and the application owner claims it's a platform standard, neither is wrong about what's in their head, they're discovering, in real time, that the line has never been drawn. The arguments are the highest-signal output of day 2; they're exactly where your future surface will leak if you don't resolve them.

The output: the wall, regrouped, each cluster labeled by decision-maker. Photograph it.

Failure mode for day 2. The room agrees too quickly. If everyone nods at every clustering, you're letting the loudest voice in the room own the line. Push for the argument. Ask "would two different application teams pick differently?" for every sticky in the application cluster. If no, the sticky belongs in the platform cluster, regardless of where it sits on the form today. The platform engineer will resist; owning more decisions means more work. Push anyway.

Day 3. Prioritization: find the five that matter

By day 3 the application-team cluster usually has between twenty and forty stickies. Today's job is to apply the five-not-eighty-nine test and find the five decisions that actually matter.

The technique I use is forced ranking. Every person in the room gets five physical dots and places them on the stickies they believe are the real, unavoidable decisions an application team has to make. Not the ones they wish were genuine. The ones that, if the platform decided for them, would actually be wrong for some teams. The dots combine. By lunchtime you'll see a clear top five, a clear bottom twenty, and a contested middle band of about ten.

The afternoon is the interrogation of the middle band. For each contested sticky, the person who voted explains why. Often the explanation is "I can imagine a team needing this." Not enough. The bar is "two real teams in our org would, in good faith, pick differently." If no, the sticky drops out of the surface and into the platform cluster. If yes, it stays, it's decision number six or seven.

The output of day 3 is a ranked list of five to ten real application-team decisions, with explicit owners. The other thirty stickies become defaults, templates, or computed values the platform will own.

Failure mode for day 3. The room can't let go. Somebody (usually the platform engineer who wrote the original form) keeps lobbying for sticky number twelve "in case." If the case is hypothetical, the sticky comes off. If it's real, the team naming the case becomes the test consumer in day 5, and if they actually need the field, day 5 will tell you and you'll add it back. The cost of removing a needed field and adding it back is small. The cost of leaving twenty unneeded fields on the surface is the entire reason you're doing this workshop.

Day 4. Surface design: model the DaC layer

Day 4 is the day the workshop produces something that runs. Up until now the wall has been paper. Today the wall becomes schema.

Take the five-to-ten-decision list from day 3 and write it as a concrete artifact in whatever your foundation is: a values.schema.json for Helm, a Crossplane XR, a Backstage software template, a Terraform module input contract. The foundation doesn't matter; the discipline does. Each decision becomes a named field, with a type, a constrained set of allowed values where possible, a default where appropriate, documentation in the user's vocabulary.

Then start the standards layer. Every sticky from day 2 that ended up in the platform cluster needs a home, a default, a template, or a computed value. You won't finish the standards layer in half a day. You only need enough that the surface from this morning will render into a working artifact for day 5.

The afternoon is render-and-test. Fill the surface with a plausible request, render it through the standards layer into the foundation's actual artifact, apply it to a sandbox. If it doesn't render, your standards layer is missing a piece. If it renders but doesn't work, your defaults are wrong. By end of day 4 you have a working surface that produces a working artifact.

Failure mode for day 4. The team designs the surface for the foundation instead of the user. Symptoms: field names that match the foundation's API (storageClassName), enums that mirror the foundation's allowed values verbatim, defaults that are platform-engineer instincts rather than day 2 standards. The fix is the boundary discipline from earlier in the series: the surface speaks the user's vocabulary; the standards layer translates into the foundation's. If you find yourself naming a field "InstanceClass," rename it "Sizing" and move the InstanceClass logic into the standards layer.

Day 5. Validation with real users

Day 5 is the day the workshop survives contact with reality. The four people in the room have spent four days arguing themselves into agreement. That agreement is meaningless if a real user (a real application team lead, not the consumer who's been in the room all week) can't read the surface in five minutes and tell you what they're choosing.

Schedule three users in the morning, three in the afternoon. Twenty minutes each. The protocol from the five-not-eighty-nine test: sit them in front of the surface, ask them to provision the thing they came to provision, time it, watch them work, note the panic responses. The workshop team watches silently.

By end of day, you have six sets of notes, and a list of every field that produced a panic response, every field that got skipped, every field that triggered "wait, I don't make this decision." The list goes back into the loop: which failures are wording problems (fix the label), which are placement problems (push the field down into the standards layer), which are missing fields (the surface is too thin; the user actually does need a sixth decision).

The output is the surface itself, validated, with a punch-list. The surface is now a thing the team can take into a real sprint.

Failure mode for day 5. The team coaches the user. The platform engineer leans in to "explain what this field means," the consumer answers a question the user asked, the facilitator says "you're doing great." All of this poisons the data. The user's confusion is the data. If the team can't sit on their hands for twenty minutes, the test fails for the team, not for the user. Tape mouths shut if you have to. (I have, more or less.)

What you ship at the end of the week

By Friday at 5 p.m. the team has, in their hands, an artifact list that didn't exist on Monday morning. A wall of decisions, photographed. A clustering by decision-maker. A ranked five-to-ten-decision surface. A working schema in the foundation. A standards layer thick enough to render. Six validation sessions. A punch-list of next-sprint work.

That isn't the finished product. The finished product takes another four to eight weeks of platform work, depending on how thick the standards layer needs to be. What you have at week's end is the shape of the finished product, with enough validation that the team can build with confidence rather than guessing.

The week is the cheapest way I've found to get a platform team out of the "we'll redesign the form someday" loop and into shipping. Five days, four people, one wall, one working surface. Run it.

, Sid