Your AI Roadmap Is Already Out of Date  🔗 **Source:** [Your AI Roadmap Is Already Out of Date](https://leaddev.com/ai/your-ai-roadmap-is-already-out-of-date) > [!note]+ Document Notes > tags: [technical-direction, reversible-decisions, engineering-leadership, thin-slice-delivery, assumption-driven-planning, ai-architecture] > author: [MISSING] > source: LeadDev > reference: https://leaddev.com/ai/your-ai-roadmap-is-already-out-of-date > date created: 2026-08-24 09:00 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: Your AI roadmap is already out of date > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [LeadDev](https://leaddev.com/) — publisher; engineering leadership audience - Amazon's one-way versus two-way doors — the widely-known prior formulation of the reversibility heuristic, not cited in the piece - Walking skeleton / tracer bullet development — the established name for the thin end-to-end slice pattern, also uncited - Assumption-based planning — the management-literature antecedent for naming assumptions rather than asserting conclusions ## 📝 Summary - **What happened.** A short engineering-leadership piece arguing that the standard approach to technical direction — pick a stack, draw a two-year roadmap, commit the team — fails in AI work because **"three months... is roughly the interval at which the 'right way' to build something in AI shifts under you."** It offers three practices instead. - **Why it matters.** The three are genuinely usable and mostly not AI-specific. **Sort decisions by reversal cost, not importance.** **Present direction as named assumptions rather than conclusions.** **Build the thinnest possible end-to-end version before committing to a direction.** Each has a concrete boundary rule, which is what separates this from generic agility advice. - **Key stakeholders.** Engineering leaders setting technical direction under uncertainty; senior leadership receiving those plans and making portfolio decisions on them; teams who bear the cost when a committed plan is walked back. - **Risks and tradeoffs.** All three practices predate AI by decades and are presented as personally derived — one-way/two-way doors, walking skeletons, and assumption-based planning are all established, and none are credited. The evidence is one personal side project plus unspecified day-to-day experience. And the framing risks implying this is new advice for a new situation when it is mostly good advice that a fast-moving field makes unavoidable. - **Bottom line.** The single most useful line is the abstraction rule: **"abstract when you have two real implementations in play, not before."** It names the failure mode on the *other* side of the commitment/experiment split, which most treatments of this idea omit. The second most useful is the reframe that when an assumption breaks, **"the conversation isn't 'the plan failed,' it's 'assumption three changed, here's the revised plan'"** — a credibility mechanism, not just a documentation style. ## 📖 Main Content The opening diagnosis is the piece's sharpest contribution and it is a *pace* claim, not a novelty claim: **"Three months. That's roughly the interval at which the 'right way' to build something in AI shifts under you."** Three concrete instances follow, and they are well chosen because they represent three different kinds of obsolescence: - **A new agent harness lands** and makes orchestration you spent a quarter on "look overweight" — your *implementation* is now excessive. - **A better retrieval pattern** quietly changes what "good" looks like for a feature you are mid-flight on — your *target* moved. - **A new evaluation technique** shows "the numbers you've been reporting for two months don't actually measure what you thought they did" — your *measurement* was wrong all along. The third is the most alarming and the least discussed. Implementation and target drift are visible; discovering your metric was measuring the wrong thing invalidates two months of reporting retroactively, including any decisions made on it. That connects to a theme running through this batch — Christopher Penn refusing a favourable benchmark result until he could reproduce it under quarantine, on exactly this instinct. The author is careful not to overcorrect: **"Not every new pattern is worth adopting, and not everything worth adopting can be adopted mid-flight. The answer isn't to freeze on what you have or to chase every release. It's to plan differently."** **Practice one: separate the bets you'd hate to reverse.** The core move is sorting every direction-setting decision into **costly-to-reverse commitments** and **reversible experiments**. Commitments get "slow and careful deliberation, the kind of design review where you invite the skeptics." Experiments get "a bias toward action" because "the cost of moving fast is small for such decisions, and you'll learn more from shipping than from discussing." That is Amazon's one-way/two-way door framing, uncredited. What makes the piece worth reading anyway is that it supplies **a specific boundary for AI systems: "architecture and interfaces are commitments, orchestration and prompts are experiments."** Generic reversibility advice leaves you to work out which is which; this names the line. The mechanism is a clean interface — "a single abstraction that takes structured input, returns structured output, and hides the specifics." With that in place, three otherwise-expensive changes become cheap: swapping a model variant, switching from single-shot prompting to a planning loop, and moving from server-side to on-device inference. **"A few days of work instead of a quarter of refactoring."** The worked example is a personal agent that reads calendar and inbox, prepares drafts, and schedules replies. The insight is precise: **"the thing I'm glad I committed to early wasn't the model, it was the tool-use schema."** A small set of tools — `read_calendar`, `send_draft`, `search_thread` — with strict input and output shapes, and the model treated as swappable behind them. When he changed model variant six weeks in, **"the agent's behavior changed but the surrounding code didn't."** That is the right lesson and it recurs across this batch: **the durable commitment is the contract, not the component behind it.** Zsolt Viczián's Story OS makes the same move with pinned world-facts in files. WooCommerce makes it with an extensible shipment-tracking API where providers hook in. The stable thing is the shape of the interaction. Then the part most versions of this advice omit — **the failure mode on the other side.** "Building a fully model-agnostic layer before you've shipped anything is its own form of waste." And the rule: **"abstract when you have two real implementations in play, not before."** That is the piece's most portable single sentence. Reversibility advice reliably produces over-abstraction in teams that take it seriously, and naming the counter-rule is what makes the guidance safe to follow. **Practice two: communicate direction as assumptions, not conclusions.** The confession is useful: the instinct when presenting to senior leadership was "to sound as certain as possible, i.e. firm dates on the roadmap, a picked stack, a clear path." That instinct fails when evaluation results come in below the bar, or when a capability the plan depended on doesn't ship on schedule — and "walking the plan back a few weeks later is uncomfortable for everyone in the room." The replacement is that every document **names its assumptions explicitly**, with a worked example: the plan assumes the latency and cost profile of the current model tier stays in range, "and if any of these change, here is what we would revisit." Note the second half — it is not just naming the assumption but pre-committing to the response. **Two payoffs, and the second is the real one.** Leadership gets "a more accurate picture of the risk they're carrying, which is what they need to make portfolio decisions" — a genuinely leadership-shaped argument, since portfolio decisions require knowing variance, not just expected value. And when an assumption breaks, **"the conversation isn't 'the plan failed,' it's 'assumption three changed, here's the revised plan.' That's a much easier conversation, and it protects the team's credibility."** The related habit is separating knowns from known-unknowns in every update, with the reasoning stated well: **"When I'm honest about what I don't know, leadership tends to trust me more when I say I do know something. On the other hand, when I pretend to be certain about things I'm not, I lose that trust the first time I'm proven wrong."** Calibration as a credibility asset — you spend certainty when you claim it, so claiming it falsely is expensive. **Practice three: ship the thinnest version first.** The definition is the important part, and it is stated precisely enough to be actionable: **"Not a prototype in one component. The whole path, front to back, working for one user on one input, even if every piece is held together with duct tape."** Most teams that think they are doing this are building a deep prototype of one component, which teaches you about that component and nothing about the system. The claim: **"What you learn in the two weeks it takes to build that thin slice will usually tell you more about the plan than two months of design review."** Same personal agent, and the specifics matter: read one calendar event, draft one reply, send it. **No planning layer. No memory. No fallback handling.** What two weeks taught — latency, tool-use reliability, error handling — "I could not have anticipated from design alone and it shaped every architectural decision I made afterward." And the consequence when the planning layer came later: **"I already knew where the real cost centers were, which made scoping the work for the fully fledged AI agent honest rather than optimistic."** Honest rather than optimistic is the phrase to keep. Estimation is not usually wrong through carelessness; it is wrong because nobody knows where the costs are until something has been built. He addresses the objection directly: shipping a thin slice *feels* slow next to designing the real version, but "designing the real version of assumptions that haven't been tested is almost always the more expensive path." Two supporting arguments: **"Every hour spent on a thin slice buys back days of arguing about architecture in the abstract"** — arguments about untested assumptions cannot terminate, because there is no evidence to settle them — and it gives leadership something concrete when they ask how it's going. The last point is underrated and easy to miss: **the thin slice creates a natural review point.** "You built it to answer specific questions, and once it answers them, that's your decision moment." Decision points that arise from the work are far more reliable than dates in a calendar, which arrive whether or not anything has been learned. The conclusion names both failure modes: "keep everything provisional and never commit, or plant a flag and hope reality cooperates. Neither works." The synthesis is a portfolio of bets with different reversal costs, communicated as assumptions, validated by thin end-to-end slices. And the honest closing: none of this removes uncertainty. **"It shifts the team from reacting to change to expecting it."** **What to hold.** All three practices are established. One-way and two-way doors is Amazon's, widely known. The thin end-to-end slice is the walking skeleton or tracer bullet, decades old. Naming assumptions rather than asserting conclusions is assumption-based planning from the management literature. None is credited, and the article's framing — "three practices I rely on" — presents them as personally derived. The AI-specific contributions are real but narrower than the framing suggests: the three-month pace claim, the architecture/interfaces versus orchestration/prompts boundary, and the tool-use-schema-over-model insight. Those are worth the read. The rest is good advice that a fast-moving field makes unavoidable rather than newly true. The evidence base is also thin — one personal side project, described twice, plus unspecified day-to-day corroboration ("I've seen the same pattern hold up in my day to day work as well"). For a practices piece this is normal and the practices are sound; it is worth noting that nothing here is measured. ### 🗒️ Notes #### The pace claim, and three kinds of obsolescence - **"Three months. That's roughly the interval at which the 'right way' to build something in AI shifts under you."** - **Implementation obsolescence:** a new agent harness lands and makes orchestration you spent a quarter on "look overweight." - **Target obsolescence:** a better retrieval pattern changes what "good" looks like for a feature you are mid-flight on. - **Measurement obsolescence:** a new evaluation technique shows "the numbers you've been reporting for two months don't actually measure what you thought they did." **The most alarming and least discussed** — it invalidates two months of reporting retroactively, including decisions made on it. - Why the standard playbook fails: pick a stack, draw a two-year roadmap, commit the team "doesn't survive contact with a field where the toolkit itself is being rebuilt every quarter." - **Correctly refuses to overcorrect:** "The answer isn't to freeze on what you have or to chase every release. It's to plan differently." #### Practice 1 — sort by reversal cost, not importance - Two buckets: **costly-to-reverse commitments** and **reversible experiments**. - Commitments get "slow and careful deliberation, the kind of design review where you invite the skeptics." - Experiments get "a bias toward action" — "the cost of moving fast is small for such decisions, and you'll learn more from shipping than from discussing." - **The AI-specific boundary, which is the contribution:** "architecture and interfaces are commitments, orchestration and prompts are experiments." - Mechanism: a clean interface — "a single abstraction that takes structured input, returns structured output, and hides the specifics." - What that buys: swapping a model variant, moving single-shot → planning loop, moving server-side → on-device all become **"a few days of work instead of a quarter of refactoring."** #### The worked example — commit to the contract, not the component - Personal agent reading calendar and inbox, preparing drafts, scheduling replies. - **"The thing I'm glad I committed to early wasn't the model, it was the tool-use schema."** - A small tool set — `read_calendar`, `send_draft`, `search_thread` — with strict input and output shapes; model treated as swappable behind it. - Six weeks in, changing model variant: **"the agent's behavior changed but the surrounding code didn't."** - **Recurs across this batch:** the durable commitment is the contract, not the component. Same move as Zsolt Viczián's pinned world-facts in files, and WooCommerce's extensible shipment-tracking API with providers hooking in. #### The counter-rule most versions of this advice omit - The other failure mode: **"Building a fully model-agnostic layer before you've shipped anything is its own form of waste."** - **The rule: "abstract when you have two real implementations in play, not before."** - **This is the piece's most portable sentence.** Reversibility advice reliably produces over-abstraction in teams that take it seriously; naming the counter-rule is what makes the guidance safe to follow. #### Practice 2 — assumptions, not conclusions - The confession: the instinct was "to sound as certain as possible, i.e. firm dates on the roadmap, a picked stack, a clear path." - Why it fails: evaluation results land below the bar, or a capability the plan depended on doesn't ship on time. "Walking the plan back a few weeks later is uncomfortable for everyone in the room." - The replacement: every document **names its assumptions explicitly** — e.g. this plan assumes the latency and cost profile of the current model tier stays in range — **and pre-commits to the response**: "If any of these change, here is what we would revisit." - **Payoff one:** leadership gets "a more accurate picture of the risk they're carrying, which is what they need to make portfolio decisions." Portfolio decisions need variance, not just expected value. - **Payoff two, the real one:** when an assumption breaks, **"the conversation isn't 'the plan failed,' it's 'assumption three changed, here's the revised plan.' That's a much easier conversation, and it protects the team's credibility."** #### Calibration as a credibility asset - Related habit: separate knowns from known-unknowns in every update. - **"When I'm honest about what I don't know, leadership tends to trust me more when I say I do know something. On the other hand, when I pretend to be certain about things I'm not, I lose that trust the first time I'm proven wrong."** - The underlying economics: you *spend* certainty when you claim it, so claiming it falsely is expensive. #### Practice 3 — the thinnest end-to-end version - **The definition is what makes it actionable:** "Not a prototype in one component. The whole path, front to back, working for one user on one input, even if every piece is held together with duct tape." - Most teams who think they're doing this build a deep prototype of one component — which teaches you about that component and nothing about the system. - **The claim:** "What you learn in the two weeks it takes to build that thin slice will usually tell you more about the plan than two months of design review." - The instance: read one calendar event, draft one reply, send it. **No planning layer. No memory. No fallback handling.** - What it taught — latency, tool-use reliability, error handling — "I could not have anticipated from design alone and it shaped every architectural decision I made afterward." - **The payoff phrase to keep:** when the planning layer came later, "I already knew where the real cost centers were, which made scoping the work for the fully fledged AI agent **honest rather than optimistic**." #### Why the thin slice feels slow, and isn't - The objection acknowledged: shipping a thin slice feels slow next to designing the "real" version. - The answer: "designing the real version of assumptions that haven't been tested is almost always the more expensive path." - **"Every hour spent on a thin slice buys back days of arguing about architecture in the abstract"** — arguments about untested assumptions can't terminate, because there's no evidence to settle them. - Second benefit: it gives leadership something concrete when they ask how it's going. - **The underrated third:** the thin slice **creates a natural review point.** "You built it to answer specific questions, and once it answers them, that's your decision moment." Decision points that emerge from work beat dates that arrive whether or not anything was learned. #### The synthesis, and the honest ending - Both failure modes named: "keep everything provisional and never commit, or plant a flag and hope reality cooperates. Neither works." - The three together: a portfolio of bets with different reversal costs, communicated as assumptions, validated by thin end-to-end slices. - **Honest close:** none of this removes uncertainty. "It shifts the team from reacting to change to expecting it." #### Provenance worth noting - **All three practices are established and none are credited.** Costly-to-reverse versus reversible is Amazon's one-way/two-way doors. The thin end-to-end slice is the walking skeleton or tracer bullet, decades old. Naming assumptions rather than asserting conclusions is assumption-based planning from management literature. - Framed as "three practices I rely on," which presents them as personally derived. - **The genuinely AI-specific contributions are narrower but real:** the three-month pace claim, the architecture/interfaces versus orchestration/prompts boundary, and the tool-use-schema-over-model insight. - **Evidence base is thin:** one personal side project described twice, plus unspecified day-to-day corroboration. Normal for a practices piece; worth noting nothing here is measured. ## 📚 References - [LeadDev](https://leaddev.com/) — publisher - Amazon shareholder letter, 1997 and 2015 — origin of one-way versus two-way door decisions - Alistair Cockburn, *Crystal Clear* — the walking skeleton pattern - Hunt & Thomas, *The Pragmatic Programmer* — tracer bullet development - Dewar, *Assumption-Based Planning* (RAND) — naming assumptions and defining signposts for revisiting them - Tetlock, *Superforecasting* — the calibration-as-credibility argument, empirically ## 🗣️ Paraphrase - **Premise.** The interval at which the correct approach to building AI systems changes is roughly a quarter, which defeats conventional multi-year technical planning. - **Three obsolescences.** New tooling makes existing work look excessive; new patterns move the quality target mid-project; new evaluation methods reveal that prior measurements were invalid. - **Balance.** Neither freezing nor chasing every release is workable; the planning method itself must change. - **Practice one.** Classify decisions by how expensive they are to unwind rather than how significant they seem; deliberate slowly on the expensive ones and act quickly on the cheap ones. - **Boundary.** In these systems, architecture and interfaces are the expensive decisions; orchestration and prompting are the cheap ones. - **Mechanism.** A single abstraction taking structured input and returning structured output makes substituting the underlying model a matter of days. - **Example.** In a personal assistant, the durable commitment was the tool schema rather than the model; changing models altered behaviour without touching surrounding code. - **Counter-rule.** Premature abstraction is its own waste; introduce it only once two real implementations exist. - **Practice two.** Present plans as explicitly named assumptions with stated triggers for revision, rather than as confident conclusions. - **Effect.** Leadership can assess the risk it is carrying, and a broken assumption becomes a revision rather than a failure. - **Calibration.** Distinguishing what is known from what is not increases trust in the claims that are made confidently. - **Practice three.** Before committing to a direction, build the smallest complete path end to end, however crude, for a single case. - **Evidence.** A fortnight of building this way surfaced latency, reliability, and error-handling realities that design work could not have predicted. - **Consequence.** Later scoping became realistic rather than hopeful because the true costs were already known. - **Objection answered.** Building a thin version feels slower than designing properly but is cheaper than designing on untested assumptions, and it ends abstract architectural argument. - **Bonus.** The completed thin version constitutes a natural decision point. - **Conclusion.** Uncertainty remains; what changes is that the team expects change rather than reacting to it. ## 📰 Newsletter **"Abstract when you have two real implementations in play, not before"** That's the line I'd pin above a desk, and it's from a short LeadDev piece on setting technical direction when the ground keeps moving. **The premise:** *"Three months. That's roughly the interval at which the 'right way' to build something in AI shifts under you."* Three flavours of that, and they're usefully distinct — a new agent harness makes the orchestration you spent a quarter on look overweight (**your implementation is obsolete**); a better retrieval pattern changes what "good" means for a feature you're mid-flight on (**your target moved**); a new eval technique reveals *"the numbers you've been reporting for two months don't actually measure what you thought they did"* (**your measurement was wrong all along**). That third one is the scary one and nobody talks about it. It invalidates two months of reporting *retroactively*, including whatever you decided on the strength of it. Which is precisely why Christopher Penn refused his own favourable benchmark result last week until he'd re-run it in a quarantined folder. **Three practices, and the second half of each is the good bit.** **Sort decisions by reversal cost, not importance.** Expensive-to-unwind decisions get slow review where you *invite the skeptics*; cheap ones get a bias toward action. That's Amazon's one-way/two-way doors, uncredited. What earns the read is the specific boundary: **architecture and interfaces are commitments, orchestration and prompts are experiments.** Generic reversibility advice leaves you to figure out which is which. The worked example is good — a personal agent reading calendar and inbox. *"The thing I'm glad I committed to early wasn't the model, it was the tool-use schema."* A handful of tools with strict shapes, model swappable behind them. Six weeks later he changed models: *"the agent's behavior changed but the surrounding code didn't."* **Commit to the contract, not the component.** (Same move as Zsolt Viczián pinning world-facts to files, and WooCommerce building one shipment-tracking API for providers to hook into. It keeps recurring.) **And then the counter-rule most versions of this advice skip:** *"Building a fully model-agnostic layer before you've shipped anything is its own form of waste."* Teams that take reversibility seriously reliably over-abstract. Two real implementations, then abstract. Not before. **Present direction as assumptions, not conclusions.** He admits the instinct was to sound certain — firm dates, picked stack, clear path — and that it doesn't survive evals landing below the bar. So now every doc names its assumptions *and pre-commits to the response*: "if any of these change, here is what we would revisit." Two payoffs. Leadership gets the risk picture they actually need for portfolio decisions. And when an assumption breaks — **one will** — *"the conversation isn't 'the plan failed,' it's 'assumption three changed, here's the revised plan.'"* That's a credibility mechanism, not a documentation style. The related line is the sharpest in the piece: *"when I pretend to be certain about things I'm not, I lose that trust the first time I'm proven wrong."* **Ship the thinnest version first** — and the definition is what makes it usable: *"Not a prototype in one component. The whole path, front to back, working for one user on one input, even if every piece is held together with duct tape."* Most teams who think they're doing this are building a deep prototype of one component, which teaches you about that component and nothing about the system. His: read one calendar event, draft one reply, send it. No planning layer, no memory, no fallback handling. Two weeks taught him latency, tool-use reliability, and error handling that design review couldn't have surfaced — so when the planning layer came later, scoping was **"honest rather than optimistic."** Keep that phrase. Estimates aren't usually wrong through carelessness; they're wrong because nobody knows where the costs are until something exists. Best supporting argument: *"Every hour spent on a thin slice buys back days of arguing about architecture in the abstract."* Arguments about untested assumptions can't terminate — there's no evidence to settle them. And the thin slice gives you a **natural review point**: you built it to answer specific questions, and when it answers them, that's your decision moment. Far better than a date in a calendar that arrives whether or not you learned anything. **One honest note:** none of these three are new, and none are credited. One-way/two-way doors is Amazon. The thin end-to-end slice is the walking skeleton, decades old. Naming assumptions is assumption-based planning out of RAND. The genuinely AI-specific bits are narrower — the three-month pace claim, the architecture-vs-prompts boundary, and the schema-over-model insight. Those are real. The rest is good old advice that a fast field makes unavoidable rather than newly true. ## ✅ Action Items #### DevRel - Developer advocacy: teach the reversal-cost sort with the AI-specific boundary attached. Generic versions of this advice fail because nobody knows where to draw the line. - Education: build a session on thin end-to-end slices using the definition here — the "not a prototype in one component" distinction is what most teams get wrong. - Developer experience: define your model-layer interface as a commitment and treat prompts and orchestration as disposable. That single decision determines how expensive your next model change is. - Developer marketing: "your AI roadmap is already out of date" is an effective hook precisely because it is true and non-blaming. - Community management: adopt assumption-naming in public roadmaps. Communities handle "assumption three changed" far better than a silently abandoned plan. - Internal/external/cross-project: the tool-schema-over-model insight is directly applicable to MCP work — the ability contract is the durable commitment, the model behind it is not. #### OSPO - Policy & Governance: require named assumptions with revisit triggers in technical direction documents. It is a small format change with a large effect on how failures are handled. - License Compliance: not applicable to this source. - Security Management: the interface-as-commitment pattern has a security dimension — a stable, structured boundary is also where you enforce authorization and validation, rather than scattering it through orchestration code. - Software Inventory: track which of your integrations are behind a stable interface and which are wired directly to a specific model or provider. The second category is your reversal-cost exposure. - Developer Support: publish the abstraction counter-rule internally. Over-abstraction is the predictable failure mode once teams internalise reversibility. - Community Engagement: not applicable to this source. - Strategic Alignment: report risk as named assumptions to leadership rather than confidence intervals nobody believes. It gives portfolio decisions something to work with. #### Community - Maintainers: apply the reversal-cost sort to your own roadmap — API surface is a commitment, implementation is an experiment, and conflating them is why deprecations hurt. - Contributors: propose thin end-to-end slices rather than deep component work when exploring a new direction; it produces a decision point rather than an artifact. - Sponsors: fund the thin slice. It is the cheapest way to discover whether a proposed direction is viable, and it looks like less progress than it is. - Ecosystem: shared interface contracts are the reversibility mechanism at ecosystem scale — the same argument, one level up. #### WordPress - Core: the architecture-versus-implementation reversibility distinction maps onto backward-compatibility policy. **Trac #65919 is exactly a case where something treated as implementation turned out to be a contract others depended on.** - Core Performance: not applicable to this source. - Core AI: **the most relevant team.** Commit to the abilities contract, treat the model and prompting behind it as swappable, and name the assumptions any AI feature plan rests on. - **Core Program Team:** assumption-naming in release planning would improve how the project communicates when a feature slips — "assumption changed" beats silent removal from a milestone. - Mobile: not applicable to this source. - Playground: Playground is an excellent thin-slice environment — end-to-end, disposable, one case working. - Community: not applicable to this source. - Training: the thin end-to-end slice is a teachable practice that improves learner outcomes regardless of AI, and the definition here is unusually clear. - Marketing: not applicable to this source. - Support: not applicable to this source. - Design: not applicable to this source. - Documentation: document interface contracts explicitly and mark what is *not* contract. The implicit-contract problem is the recurring cause of unexpected breakage. - Photos: not applicable to this source. - TV: not applicable to this source. - Polyglots: not applicable to this source. - Accessibility: not applicable to this source. - Meta: not applicable to this source. - CLI: WP-CLI's command interface is the durable contract; implementation behind it is freely changeable. A good existing example of the pattern. - Hosting: not applicable to this source. - Tide: not applicable to this source. - Themes: `theme.json` is a commitment; the rendering behind it is an experiment. That is precisely why the theme.json-first cadence exists, and this framing explains it better than the cadence discussion did. - Plugins: plugin authors should identify which of their hooks and filters are contracts and say so — most of the pain comes from users depending on things the author considered internal. #### The WPOCC - Programs: a workshop on assumption-based planning would serve project leads who currently present plans as certainties and then have to walk them back publicly. - Projects: adopt named assumptions with revisit triggers in project planning documents as a standard format. - Funding experiments: fund thin slices explicitly — small, time-boxed, end-to-end explorations whose deliverable is a decision rather than a product. ### FAIR - Technical independence: a stable interface with a swappable implementation behind it *is* independence in practice — it is what makes changing provider a days-long task rather than a quarter-long one. - Policies and covenants: naming assumptions and their revisit triggers is a transparency practice that suits governance documents as well as technical ones. - Productized governance artifacts: an assumption register with defined triggers is a small, reusable artifact worth templating. ### 🧪 Hypotheses 1. **Reversal-cost sorting improves decision quality under uncertainty.** Teams explicitly classifying decisions by reversibility will show fewer costly reversals and faster cheap iterations than teams treating all decisions uniformly. 2. **Interface-first architecture reduces model-switching cost.** Systems with a structured model-layer abstraction will require materially less engineering effort to change model or provider than systems without one. 3. **Premature abstraction costs more than it saves.** Systems abstracted before two real implementations existed will show higher total effort than systems abstracted at the two-implementation point — the counter-rule, stated falsifiably. 4. **Assumption-framing preserves credibility through plan changes.** Leaders presenting plans as named assumptions will retain higher stakeholder confidence after a plan revision than leaders presenting conclusions. 5. **Thin end-to-end slices improve estimate accuracy.** Projects preceded by a complete-path thin slice will show smaller variance between estimated and actual effort than projects preceded by design review alone. 6. **The three-month obsolescence interval is real and measurable.** The dominant recommended approach for a given AI capability will change on roughly a quarterly cadence — the piece's founding claim, and entirely unevidenced. ### 📊 Methodology - **H1:** Comparative case study across teams adopting explicit reversibility classification versus matched controls; measure reversal frequency, cost of reversals, and iteration rate. Hard to randomise; matched observation is the realistic design. - **H2:** Direct measurement — instrument model-swap tasks across codebases with and without a structured abstraction layer, counting engineering hours. Clean, and cheap to run inside a single organisation with several services. - **H3:** The hard one, because it requires counterfactual effort. Best available approach is retrospective analysis of abstraction layers, coding each as premature or justified by whether a second implementation eventually materialised, then comparing maintenance cost. - **H4:** Vignette study with engineering leadership audiences — same plan revision, presented with and without prior assumption-naming; measure rated confidence in the team. Straightforward and would test the piece's central credibility claim. - **H5:** Compare estimate-to-actual variance across projects segmented by whether a thin end-to-end slice preceded scoping. Confounded by team maturity, but the effect claimed is large enough to survive some noise. - **H6:** Longitudinal tracking of recommended approaches for specific AI capabilities — retrieval, orchestration, evaluation — measuring how often the dominant recommendation changes. Nobody has done this, and the entire article rests on it. ### ❓ Questions - Is three months a measured interval or a felt one, and does it vary by capability area — is evaluation methodology churning faster than orchestration? - How do you distinguish a genuinely costly-to-reverse decision from one that merely feels important, before you have paid the cost of being wrong? - What happens when a decision you classified as reversible turns out not to be — is there a recovery pattern, or is the classification error just the cost of the method? - Does assumption-framing survive contact with leadership that reads named uncertainty as weakness rather than as calibration? - How thin is too thin — at what point does a slice fail to surface the problems it was built to surface? - Does the architecture-versus-prompts boundary hold as orchestration frameworks mature, or does orchestration gradually become architecture? - If measurement obsolescence is real, what is the practice for reporting metrics you may later discover were measuring the wrong thing? - Why are none of the three practices credited to their origins, and does presenting established ideas as personally derived cost the piece anything with its intended audience? ### 🔮 Future Research - **The obsolescence interval.** The founding claim is entirely unevidenced and would be straightforward to track. If it is real, it has implications for planning horizons well beyond AI. - **Measurement obsolescence specifically.** Discovering your metric was wrong invalidates past decisions retroactively. Nobody has a practice for this, and it is the most consequential of the three obsolescences named. - **The abstraction timing rule.** "Two real implementations" is a specific, testable threshold. Whether it is the right one is an empirical question with real cost consequences either way. - **Assumption-framing and credibility.** The claim that naming uncertainty increases trust is testable, matters for how technical leaders communicate, and connects to established calibration research nobody in the piece cites. - **Thin slice depth.** How minimal a slice can be while still surfacing latency, reliability, and error-handling realities is a practical question with no published guidance. - **Contract-over-component as a general principle.** This batch surfaces the same move in four independent domains. Whether it generalises formally is worth treating as a real question. ### 💡 Implications - **Practice.** Two immediately actionable items: draw the line in your own system between what is contract and what is implementation, and write down the assumptions your current plan rests on along with what would trigger revisiting them. Both take an hour. - **Policy.** Assumption registers with revisit triggers belong in technical direction documents as a standard format. The cost is a paragraph; the benefit is that plan changes stop reading as failures. - **Security.** A stable structured interface is where authorization and validation belong; scattering them through orchestration code is what makes them expensive to change and easy to miss. - **Education.** The thin end-to-end slice is teachable, AI-independent, and improves outcomes generally. The definition offered here is unusually precise and worth adopting verbatim. - **Funding.** Thin slices are underfunded because their deliverable is a decision rather than a product. Naming them as a fundable output would change what gets explored. ### 🧠 Learning Styles Assessment - **Reading level estimate:** Flesch-Kincaid Grade Level ≈ 11; Flesch Reading Ease ≈ 48. Professional prose with long compound sentences. Assumes familiarity with agent harnesses, retrieval patterns, evaluation practice, and inference deployment; accessible to its intended engineering-leadership audience and opaque outside it. #### 👀 Visual learners - Present: a stock hero image and a key-takeaways box; three clearly-signposted sections. - Improve: no diagram anywhere. A simple two-axis chart of reversal cost against decision frequency, or a picture of the thin slice versus deep prototype distinction, would carry more than the prose does — and the thin slice distinction is the one most often misunderstood. #### 🔊 Aural learners - Present: none; text-only article. - Improve: **Not applicable to this source** — a short written piece with no audio component. #### 🗣️ Verbal learners - Present: strong. Concrete rules stated memorably — "abstract when you have two real implementations in play, not before," "honest rather than optimistic." The key-takeaways box compresses the argument well. - Improve: terms like agent harness, retrieval pattern, and model tier arrive undefined; fine for the audience, limiting for anyone adjacent to it. #### 🧩 Kinesthetic learners - Present: the thin-slice practice is inherently hands-on, and the worked example is specific enough to imitate — read one event, draft one reply, send it. - Improve: no template for the assumption-naming format, which is the practice most easily adopted if someone shows you the shape. #### 🧠 Logical learners - Present: clean structure — problem, three practices, synthesis — with each practice given a mechanism and a boundary condition. The counter-rule on over-abstraction shows the author reasoned about the failure mode on both sides. - Improve: the founding three-month claim carries the entire argument and is stated without evidence. And no prior art is acknowledged, which makes the reasoning appear more original than it is. #### 🧑‍🤝‍🧑 Social learners - Present: the second practice is explicitly about a relationship — how to communicate with senior leadership so trust survives plan changes. The "invite the skeptics" line is a social mechanism. - Improve: nothing on how to get a team to adopt these practices, which is usually the harder half. #### 🧘‍♀️ Solitary learners - Present: short, self-contained, immediately applicable alone. The key-takeaways box supports later recall. - Improve: no further reading, which is a shame given how much established literature sits directly behind each practice. #### 🌿 Naturalistic learners - Present: none. - Improve: **Not applicable to this source** — an engineering-management article with no environmental dimension, though inference cost profiles are mentioned in passing. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: conventional article structure with headings, a key-takeaways list, and clearly delineated sections. - Improve: the hero image appears decorative; confirm it is marked as such rather than carrying a meaningless filename as alt text. Maps to **WCAG 2.2 A 1.1.1 Non-text Content**. #### Keyboard navigation - Present: standard article links. - Improve: the inline newsletter signup interrupting the article flow needs sensible focus order and should not trap. Maps to **2.4.3 Focus Order** and **2.1.2 No Keyboard Trap**. #### Contrast and readability - Present: standard publication typography. - Improve: not assessable from captured text; verify against **1.4.3**. #### Text resizing and reflow - Present: expected responsive layout for a professional publication. - Improve: verify the key-takeaways box and inline promotional blocks at 200% zoom. Maps to **1.4.4** and **1.4.10**. #### Media and captions - Present: a hero image; no audio or video. - Improve: nothing significant. #### Forms and interactions - Present: an inline newsletter subscription form mid-article, plus a promotional block. - Improve: the form needs a programmatically associated label and accessible error handling. Mid-article interruptions are also a comprehension cost for some readers. Maps to **3.3.1 Error Identification** and **3.3.2 Labels or Instructions**. #### Standards reference - Main items are the mid-article form (**3.3.1**, **3.3.2**) and the decorative hero image (**1.1.1**). Nothing severe; this is a conventionally-structured article. ### 🌍 DEIB Assessment #### Cultural breadth - Present: no geographic or cultural specificity; the advice is not tied to a particular market. - Improve: implicitly assumes a well-resourced context — senior leadership to present to, portfolio decisions being made, capacity to spend two weeks on a throwaway slice. That is not most engineering contexts, and the practices would need adapting for teams with less slack. #### Inclusive language - Present: neutral throughout; first-person and second-person, no gendered assumptions, no in-group signalling. - Improve: undefined domain vocabulary is the only real barrier. #### Neurodiversity support - Present: excellent structure for the length — key takeaways up front, three clearly-labelled sections, one idea per paragraph, a synthesis at the end. Easy to scan and easy to re-enter. - Improve: nothing significant. #### Representation - Present: a single author drawing on personal experience, with no claim to represent others. - Improve: **the byline is absent from the captured content**, which is a genuine problem for a piece whose authority rests on the author's experience — a reader cannot assess whose experience this is. The examples come from one personal side project, so the range of contexts represented is narrow. #### Psychological safety - Present: genuinely good. The author admits the instinct to project false certainty and describes the discomfort of walking plans back "for everyone in the room." Framing broken assumptions as revisions rather than failures is explicitly a mechanism for protecting a team. - Improve: nothing significant. The piece models the calibration it recommends. ### ✅ Logical Validity #### Strong reasoning - **Well-typed problem decomposition.** The three obsolescences — implementation, target, measurement — are genuinely distinct failure modes with different consequences, not three examples of one thing. The taxonomy does real work. - **Refusal to overcorrect.** "The answer isn't to freeze on what you have or to chase every release" pre-empts the two obvious wrong responses before proposing a third, which is how a recommendation earns its place. - **Boundary conditions supplied.** Each practice comes with a rule for applying it — architecture versus orchestration, two implementations before abstracting, whole path rather than one component. Advice without boundaries is unusable, and this piece consistently supplies them. - **Counter-rule on over-abstraction.** Naming the failure mode created by taking your own advice too seriously is rare and is what makes practice one safe to follow. - **Causal, on credibility.** The mechanism is properly specified: pretending certainty spends trust you lose at the first disconfirmation, while calibration makes confident claims more believable. The reasoning is sound independent of the anecdote. - **Cost argument for the thin slice.** "Every hour spent on a thin slice buys back days of arguing about architecture in the abstract" identifies why abstract architecture arguments cannot terminate — no evidence exists to settle them. That is a real explanation, not a slogan. #### Fallacies - **Unsupported foundational claim** — "Three months. That's roughly the interval at which the 'right way' to build something in AI shifts under you." *Weakness:* the entire article rests on this and it is offered with no evidence, no source, and no method. It also has the shape of a claim that feels true to someone immersed in the field regardless of whether it is. *Fix:* present it as an observation from experience, or cite something. - **Failure to credit prior art** — all three practices are established: one-way/two-way doors (Amazon), the walking skeleton or tracer bullet (Cockburn, Hunt & Thomas), assumption-based planning (RAND). *Weakness:* "three practices I rely on" frames them as personally derived, which overstates originality and denies readers the far richer literature behind each. This is the piece's most substantive shortcoming. *Fix:* cite the origins; it would strengthen rather than diminish the argument. - **Anecdotal evidence, single instance** — the same personal side project supports two of three practices, with day-to-day work invoked only as unspecified corroboration ("I've seen the same pattern hold up in my day to day work as well"). *Weakness:* a calendar-and-inbox side project is a low-stakes, single-user, single-developer context; whether the lessons transfer to team-scale production systems is assumed. *Fix:* one production example would do more than the second retelling of the side project. - **False dilemma (minor)** — "keep everything provisional and never commit, or plant a flag and hope reality cooperates. Neither works." *Weakness:* presented as the two available instincts, with the article's approach as the third way. Other established approaches exist — staged commitment, real options, set-based design — and go unmentioned. *Fix:* acknowledge the landscape rather than positioning the recommendation against two strawmen. - **Overgeneralization (minor)** — "abstract when you have two real implementations in play, not before." *Weakness:* offered as a general rule, but there are cases where a second implementation is foreseeable with high confidence and the abstraction is cheaper built early. The rule is good; the absoluteness is not. *Fix:* state it as a default with the exception named. - **Convenient scoping of the boundary** — "architecture and interfaces are commitments, orchestration and prompts are experiments." *Weakness:* this holds only while orchestration remains genuinely lightweight. Once orchestration carries state, retry semantics, and cost controls, it becomes architecture by another name, and the article does not address where the line moves. *Fix:* note the condition under which the boundary shifts. #### Tone of voice - Measured and practitioner-first; recommendations arrive with reasons rather than as assertions. - Openly self-correcting — the author describes an earlier instinct as wrong and explains what replaced it, which is the piece's main credibility mechanism. - Concrete where it counts: named tools, specific timeframes, actual sentences from a planning document. - Non-alarmist about AI pace despite the headline, and explicitly against both freezing and chasing. - Honest at the close: the practices do not remove uncertainty, only change the team's relationship to it. Refusing the tidy ending is the right call. ### 🛡️ DARVO Analysis - **Deny:** Not present. The author's characteristic move is admission — that the instinct to project certainty was wrong, that assumptions will break, that uncertainty does not go away. - **Attack:** Not present. No person, team, tool, or vendor is criticised anywhere. The critique is aimed at a planning *method*, described neutrally. - **Reverse victim/offender:** Not present. No accusatory dynamic exists in the material. - **Emotional cues and rhetoric:** Restrained. The headline is mildly provocative and the body does not cash it in for urgency or fear. - **One item catalogued elsewhere:** presenting established practices as personally derived is an attribution failure, not a defensive pattern, and is treated under Logical Validity above. - **Assessment:** DARVO is **not applicable to this source** — a practices article with no accusatory or defensive dynamic. ## 🎯 Conclusion - **Bottom line.** Three practices, each with a usable boundary rule: **sort decisions by reversal cost rather than importance** (architecture and interfaces are commitments; orchestration and prompts are experiments), **present direction as named assumptions with pre-committed revisit triggers**, and **build the thinnest complete end-to-end path before committing to a direction**. - **The single most portable line** is the counter-rule: **"abstract when you have two real implementations in play, not before."** Reversibility advice reliably produces over-abstraction in teams that take it seriously, and naming that failure mode is what makes the rest safe to follow. - **The most useful reframe** is that a broken assumption becomes "assumption three changed, here's the revised plan" rather than "the plan failed." That is a credibility mechanism, not a documentation style — and its companion line is sharper still: "when I pretend to be certain about things I'm not, I lose that trust the first time I'm proven wrong." - **The recurring idea this batch keeps surfacing:** **commit to the contract, not the component.** Here it is a tool-use schema with the model swappable behind it. Zsolt Viczián pins world-facts to files with the model swappable behind them. WooCommerce builds one shipment-tracking API with providers hooking in. MCP is standardising one result contract so servers can reason about what the model sees. Four independent domains, one move. - **What to discount.** None of the three practices is new, and none is credited — one-way/two-way doors is Amazon's, the thin end-to-end slice is the walking skeleton, assumption-naming is assumption-based planning. The foundational three-month claim carries the whole argument and has no evidence behind it. And the evidence base is one personal calendar-and-inbox side project, described twice, with production experience invoked but never detailed. - **Next steps for readers.** Two things, each about an hour. Draw the line in your own system between what is contract and what is implementation — that line is your reversal-cost exposure. And write down the assumptions your current plan rests on, with what would trigger revisiting each. If you want the deeper version, the uncited literature behind all three practices is considerably richer than the article. ## 🔄 Refactor Appendix — Your AI roadmap is already out of date > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] Abstract only after two real implementations exist > [!quote] > abstract when you have two real implementations in play, not before **Context & use**: - The counter-rule that makes reversibility advice safe. Teams that internalise "keep options open" reliably over-abstract, and "building a fully model-agnostic layer before you've shipped anything is its own form of waste." Most treatments of this idea omit the failure mode on this side. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> #### [H2] Commit to the tool schema, not the model > [!quote] > the thing I&#39;m glad I committed to early wasn&#39;t the model, it was the tool-use schema **Context & use**: - Strict input/output shapes on a small tool set, model swappable behind them. At six weeks he changed model variant: "the agent's behavior changed but the surrounding code didn't." The same move recurs in Viczián's pinned world-facts, WooCommerce's shipment-tracking API, and MCP's result contract — **commit to the contract, not the component.** **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H3] Broken assumptions are revisions, not failures > [!quote] > the conversation isn&#39;t "the plan failed," it&#39;s "assumption three changed, here&#39;s the revised plan." **Context & use**: - Naming assumptions explicitly, with pre-committed revisit triggers, converts an uncomfortable retraction into an expected update. A credibility mechanism rather than a documentation style — and it gives leadership the variance they need for portfolio decisions. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> #### [H4] The thin slice is the whole path, not one component > [!quote] > Not a prototype in one component. The whole path, front to back, working for one user on one input, even if every piece is held together with duct tape. **Context & use**: - The definition is what makes it actionable — most teams who think they're doing this build a deep prototype of one component, which teaches them about that component and nothing about the system. Payoff: later scoping becomes "honest rather than optimistic," because the real cost centres are already known. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Sort decisions by reversal cost, not by felt importance **Claim** (one sentence, Courtney's voice): How much deliberation a decision deserves is determined by what it costs to undo, not by how significant it feels at the time. **Evidence pointer**: [[#H1]] and [[#H2]] **Scope & conditions**: Holds where reversal cost is estimable in advance, which is the hard part — a decision misclassified as reversible carries its full cost anyway. Requires a domain-specific boundary to be usable; the generic version leaves people unable to apply it. Prior art: Amazon's one-way and two-way doors, uncredited in the source. **Links** (≥1 with annotation): - [[CRM-stages-forecast-deals-they-do-not-run-them]] — because contrasts on mistaking one thing for another - [[Declarative-configuration-lets-a-platform-swap-renderers]] — because applies-in platform design - [[Real-options-thinking]] — because extends <!-- atomicity: 1 idea ✓ --> #### [P2] Stated uncertainty is what makes stated confidence worth anything **Claim** (one sentence, Courtney's voice): Being explicit about what you do not know is what gives your confident claims credibility, because certainty is spent rather than displayed. **Evidence pointer**: [[#H3]] **Scope & conditions**: Holds where the relationship is repeated and disconfirmation is eventually visible — which is most working relationships. Fails in one-shot contexts where confident assertion is never tested, which is why the incentive runs the other way in sales and pitching. Related to calibration in forecasting, where the same result is established empirically. **Links** (≥1 with annotation): - [[Suspicious-results-demand-reproduction-before-acceptance]] — because extends - [[The-producer-of-an-artifact-must-not-be-its-only-evaluator]] — because applies-in verification - [[Calibration]] — because evidence-for <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] **"Commit to the contract, not the component"** now appears in four sources across this batch — tool-use schema here, pinned world-facts (Viczián), shipment-tracking API (Woo), result contract (MCP). That's the synthesis piece, alongside the verification one. — https://leaddev.com/ai/your-ai-roadmap-is-already-out-of-date #fleeting #articleseed - [F2] Measurement obsolescence — discovering your metric measured the wrong thing, invalidating two months of decisions retroactively — is the scariest of the three and nobody has a practice for it. Pairs with Penn's quarantine re-run. — #fleeting #articleseed - [F3] None of the three practices is credited: one-way/two-way doors (Amazon), walking skeleton (Cockburn), assumption-based planning (RAND). Worth reading the primary sources; they're richer than the article. — #fleeting #inbox - [F4] The three-month obsolescence interval carries the entire argument and has zero evidence. Feels true to people inside the field, which is exactly when to be suspicious. Would be straightforward to actually track. — #fleeting #xref - [F5] "Architecture and interfaces are commitments, orchestration and prompts are experiments" — does this hold once orchestration carries state, retries, and cost controls? At some point orchestration *becomes* architecture and the article doesn't say where. — #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Draw the contract-vs-implementation line in my own AI tooling and note the reversal-cost exposure — engineering #things - [ ] Write the assumption register with revisit triggers for my current active plan — planning #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Your AI Roadmap Is Already Out of Date.md|Your AI Roadmap Is Already Out of Date by leaddev.com]] ## Highlights - On a personal agent outside of work I’ve been running for a few months, that reads my calendar and inbox, prepares drafts, and schedules replies, the thing I’m glad I committed to early wasn’t the model, it was the tool-use schema. ([View Highlight](https://read.readwise.io/read/01m0sz19drh7hnjks6cc6wwhk7)) - Note: [H2] Commit to the tool schema, not the model. Strict input/output shapes, model swappable behind them — at six weeks he changed model variant and "the surrounding code didn't" change. Same move recurs in Viczián's pinned world-facts, Woo's shipment-tracking API, MCP's result contract: commit to the contract, not the component. - Tags: atom/literature/h2, articleseed - The rough rule I use: abstract when you have two real implementations in play, not before. ([View Highlight](https://read.readwise.io/read/01m0sz0zz6s5h7qejg3bnfwxej)) - Note: [H1] Abstract only after two real implementations exist. The counter-rule that makes reversibility advice safe — teams that internalise "keep options open" reliably over-abstract. Most treatments of this idea omit the failure mode on this side. - Tags: atom/literature/h1, aphorisms - There are two payoffs. Leadership gets a more accurate picture of the risk they’re carrying, which is what they need to make portfolio decisions. When an assumption breaks, and one will, the conversation isn’t “the plan failed,” it’s “assumption three changed, here’s the revised plan.” ([View Highlight](https://read.readwise.io/read/01m0sz1jf954yggmtj443tqyqc)) - Note: [H3] Broken assumptions are revisions, not failures. Naming assumptions with pre-committed revisit triggers converts an uncomfortable retraction into an expected update. A credibility mechanism rather than a documentation style. - Tags: atom/literature/h3, share