--- name: decision-and-tradeoff-ledger description: Use this skill when a technology leader is stuck in a "should we decide this now or keep our options open" argument, or when a real tradeoff — build vs. buy, speed vs. quality, security vs. convenience, monolith vs. microservices, AI-generated vs. human-written code, or any other decision two reasonable people are arguing past each other about — needs to be priced honestly instead of argued as if one side is simply correct. Triggers on requests like "help me classify this decision," "is this early-binding or late-binding," "build a tradeoff ledger," "we keep relitigating this decision," "run the decision classification worksheet," or "what are we actually giving up here." --- # Decision Classification and the Tradeoff Ledger This skill is Labor as Code™ for two consecutive chapters of *The Code Takes Care of Itself* — "Know Which Decisions to Make Early and Which to Delay" and "Every Real Decision Gives Something Up." Read both for the full argument: some decisions deserve conviction because their cost of reversal grows over time (early-binding), some deserve deliberate patience because delay buys real information at low cost (late-binding), and once a decision is genuinely early-binding — or once a real dispute needs resolving even on a reversible choice — the discipline that ends the argument isn't finding who's "right." It's writing a ledger of what's gained, what's given up, who pays, and what would make you reverse. This skill runs both the classification and the ledger. It does not decide which side of a tradeoff the user's organization should choose. Unlike a skill that stops short of a conclusion out of caution, this one stops there because the ledger *is* the book's full, considered answer to the question "which side is right" — the book's own diagnosed failure mode is precisely a verdict that declares one side correct and prices the other side's concern at zero, which produces the exact relitigating this skill exists to end. Where this skill does owe a stated call with reasoning is the classification itself (Part A): whether a decision is early- or late-binding is a judgment this skill makes explicitly, from the named evidence, not a question it defers. ## Before running 1. **This skill needs the real decision and the real room.** Generic tradeoffs ("build vs. buy, in general") don't produce a useful ledger. Get the specific decision, the specific people or roles arguing it, and what each side has actually said, before starting Part A. 2. **Don't skip straight to the ledger.** Part A (classification) comes first every time, even when the user is certain this is an early-binding decision. Running the two dependency-and-reversal questions out loud is often what breaks a stalled argument on its own, before the ledger is even needed. 3. **This skill will not invent what a real stakeholder would think.** Part B asks who pays and who benefits, and what a CFO or CISO or engineering lead would actually value. Those answers have to come from the user's real knowledge of the actual people in the room — this skill can prompt for that knowledge, but it should not supply a generic "CFOs typically want X" answer as a substitute for the user finding out what *this* CFO actually cares about. ## Part A: Classify the decision Run this whenever someone says "let's keep our options open" or "we need to lock this down now." Don't accept either instinct at face value — run the decision through these five questions first. 1. **Map the dependencies.** Count and *name* the components, teams, and downstream decisions that depend on this one. A short, specific list means a late-binding candidate. A list that's hard to finish, because the decision touches almost everything, means early-binding — whatever the room feels about it in the moment. 2. **Price the reversal.** If this decision turns out wrong, what does changing it cost in six months? In eighteen months? A flat cost over time means you can safely defer. A sharply growing cost means bind early — the growth curve itself is the argument for deciding now, even without full confidence in the choice. 3. **Identify what you're actually waiting for.** Name the specific information, customer signal, or business alignment the decision is waiting on, and give a date or trigger event by which that input must exist. If you can't name the input, this isn't late-binding — it's avoidance wearing late-binding's vocabulary. 4. **Assign the owner and the trigger.** Every genuine late-binding decision needs one named person who makes the call when the trigger fires, plus something that actually surfaces it again — a calendar reminder, a milestone. A late-binding decision with no owner and no trigger gets made by default, usually badly, by whoever happens to be in the room when the cost finally comes due. 5. **Check the execution cost, not just the decision cost.** How long does the work take once the decision is actually made? If AI-assisted execution has meaningfully shrunk that window, use the new number in Step 2 — a decision that needed early commitment only because the *work* used to be slow may not need it anymore. But check this against Step 1's dependency map first: faster execution shortens the cost of the work sitting on top of a decision, not the length of the dependency chain underneath it. A core data model or a primary cloud provider stays early-binding no matter how fast the tooling gets, because that cost is structural. **Output of Part A:** a one-line classification — early-binding (commit with conviction) or late-binding (name the owner and trigger, then genuinely stop relitigating it until the trigger fires) - stated as this skill's own read of the five questions above, with the specific answer that tipped it. If the dependency map and the reversal cost curve genuinely point in different directions (a short dependency list but a sharply growing reversal cost, or the reverse), say so explicitly and treat it as early-binding by default - the book's own logic is that a growing cost curve is the more dangerous error to get wrong, so ambiguity resolves toward caution on the axis that's harder to undo, not toward whichever classification the room prefers. ## Part B: Build the Tradeoff Ledger Run this for any decision Part A classified as early-binding, or for any decision — reversible or not — that's consuming real argument time because two people are defending true statements about *different dimensions* of the same choice (this is the book's signature diagnostic: a debate that survives multiple long meetings is usually not a debate where someone is wrong, it's a debate where nobody has said what they're each optimizing for). 1. **In one sentence each: what do we gain, what do we give up?** If the second sentence comes back empty, or reads "nothing significant," stop — you haven't found the tradeoff yet. A decision whose cost can't be named is a decision that isn't understood yet, not a decision with no cost. 2. **Name the constraint that binds this quarter** — time, money, talent, attention, trust, or patience. Then state which future problems the organization is accepting, and use the word "intentionally" in that sentence. It matters later, when someone asks whether this was a mistake or a bet that didn't pay off. 3. **List the risks this decision reduces *and* the risks it increases.** Every real decision does both. A proposal that only reduces risk is a sign its author never looked for the second column — push back and ask them to find it. 4. **State the assumptions that make this decision correct, then the reversal trigger** — the observable event that would show one of those assumptions has failed. Give the trigger a named owner. A trigger with no owner is a wish, not a mechanism. 5. **Name who pays the cost and who gets the benefit, by team and by role.** Never write "the org." The book's own warning: the most toxic decisions are the ones where the payer and the beneficiary are different people and nobody said so out loud. 6. **Write the likely second-order effects within two years, and the capabilities the choice requires** — the team you'll need, not just the system you'll get. Sign the ledger, date it, and file it somewhere the next leader can actually find it. The last reader of a ledger is almost always someone who wasn't in the room when it was written. ``` TRADEOFF LEDGER — [decision name] Date: ____ Signed: ____ Gain: ____ Give up: ____ Binding constraint this quarter: ____ Future problem we are INTENTIONALLY accepting: ____ Risks reduced: ____ Risks increased: ____ Assumptions this depends on: ____ Reversal trigger: ____ Owner: ____ Who pays: ____ Who benefits: ____ Second-order effects (2 years out): ____ Capabilities this requires (team, not just system): ____ ``` ### If it's genuinely a multi-role dispute, name the objective functions first Before filling in the ledger, it's often worth naming what each seat in the room is actually optimizing — the book's list, adapted to whoever's actually arguing: Finance optimizes capital efficiency and predictable spend; a CISO optimizes tail risk; a CTO optimizes optionality (the ability to change direction later at survivable cost); engineering left to itself optimizes its own daily experience; support/ops optimizes operational simplicity; customers optimize their own outcomes and ignore the architecture entirely; compliance optimizes demonstrable evidence after the fact. None of these is wrong — the dysfunction starts when people argue as if they're optimizing the same thing, so a disagreement about *weights* gets mistaken for a disagreement about *facts*. ## Watch for Decision Debt while you're at it While running either part of this skill, flag it out loud if the situation matches any of these five signs the book gives for a decision that's been quietly rotting instead of genuinely deferred: - A decision has been "almost final" for more than one planning cycle. - The same question is being asked, unresolved, in more than one recurring meeting. - Nobody can explain in one sentence why a *past* decision was made. - A shadow process has emerged to route around the undecided thing (an unsanctioned spreadsheet, a private channel that's become the real source of truth). - A vendor has started pricing in the organization's own indecision (padded timelines, contingency built into a quote before anything unusual was said). Any one of these is worth naming to the user directly — it means the decision in front of them isn't actually being deferred deliberately, whatever it's being called. ## The check that catches this book's own failure mode - **This produced a ledger, not a verdict — and that's the considered answer, not a stopping-short of one.** A verdict says "here's what we chose and why it's good" and invites endless relitigation, because whoever valued the losing dimension senses, correctly, that their concern was never priced. A ledger says what was chosen, what was knowingly given up, who pays, and what would trigger a reversal — and people accept a tradeoff they argued against far more readily than a verdict that pretended their side cost nothing. Before calling this done, confirm the "what we give up" line is real and specific, not empty or hand-waved, and confirm Part A's classification was stated as this skill's own read with its reasoning, not left as an unresolved question. - **Every trigger has a named owner.** Scan the ledger and the classification output for any trigger without one — that's an unfinished step, not a stylistic choice. - **Reversal cost was priced over time (Part A, Step 2), not just at one moment.** A flat-versus-growing cost curve is the actual signal; a single point-in-time estimate misses it. ## Used in *Acquired Alpha* A build, buy, or generate-once argument is a tradeoff to price before any seller is evaluated. In *Acquired Alpha* the ledger prices the three options of the Three-Way Sort, and the buy option's claims then go through the book’s claim test (the Three Tests). The skill's own conclusion does not change.