TBM 430: Incubate, Compound, Refinance, Liquidate
John Cutler · email · 2026-07-12 Reader 🖥️
AI as AmplifierDecision-Making PracticesOrganizational DebtPlatform EngineeringTechnical DebtVelocity Debt / Debt Accelerator
Software assets, teams, and initiatives can be read as a portfolio positioned by the value they create against what they cost to carry -- moving between Incubate, Compound, Refinance, and Liquidate over time -- and AI does not change this underlying economic physics of complexity, coupling, and decay, only the cost, speed, and feasibility of accelerating whichever direction, healthy or pathological, the portfolio is already moving.
practical · expository — Builds a diagrammatic 2x2 conceptual framework (value created x carrying cost) and a financial-portfolio metaphor (incubate/compound/refinance/liquidate), then applies it to AI. Explicitly self-described by the author as informal 'Sunday-morning diagramming and thought-provocation,' not a worked-out theory -- the diagrams carry as much argument as the text, in classic Cutler style.
Structure
| Part | Role |
|---|---|
| tl;dr framing | Thesis statement |
| Concession of non-novelty | Framing / scope-setting |
| Carrying Costs and Value (the 2x2) | Core framework introduction |
| Motion and Arc | Extension of framework via a generic case |
| Debt | Application of the framework to technical debt |
| Platforms | Application of the framework to platform strategy |
| An Intentional Portfolio | Synthesis / reframing of 'health' |
| The Traps | Named pattern catalogue |
| Not a Monolithic Situation (AI section) | Climactic application to AI |
| Closing line | Aphoristic summary |
Key terms
- Incubate / Compound / Refinance / Liquidate
The four quadrants of the value-created x carrying-cost 2x2: Incubate = low value, low carrying cost (cheap unproven bet); Compound = proven value, still cheap to carry, returns expanding; Refinance = rising carrying costs as the asset scales, interest starting to consume returns, needing restructuring; Liquidate = remaining value no longer justifies the cost of carrying the asset or its debt. - carrying cost
What it costs to change, operate, and support a software asset over time -- the second axis of the 2x2, alongside value created. Used qualitatively throughout; never assigned a metric or unit. - Build Trap
The pattern where Incubate fails to become Compound (value never proven) but the team keeps building anyway, so carrying cost keeps rising -- 'turning a cheap experiment into an expensive obligation.' - Zombie Portfolio
Old, low-value assets kept alive past their economic justification -- used only in the AI section as one of four situations AI interacts with. - Mandate Trap
The platform-strategy failure of mistaking compulsory usage for evidence that the platform improves anyone's economics.
Propositions
- explicitA software asset's position on a 2x2 of value-created versus carrying-cost implies one of four basic economic postures: incubate, compound, refinance, or liquidate.conf: highextendsTBM 416: Investment Stewardship (As Habit) · p1 — TBM 416 argues ROI understanding is continuously practiced behavior, not a one-off calculation; TBM 430's 2x2 gives a candidate structure (quadrant position, tracked over time) for what that continuous practice could actually track.
- explicitcorroboratedTechnical debt is a financing choice -- accepting higher future carrying costs in exchange for reaching value sooner -- and whether it is rational leverage, a dangerous obligation, or a liability depends entirely on which portfolio quadrant the asset carrying it occupies, not on any intrinsic property of the debt itself.conf: highsupports ←Technical Debt Quadrant · p2 — Both reject treating debt's moral status as intrinsic (debt vs. non-debt) in favor of a contextual, positional evaluation — Fowler's reckless/prudent axis and tbm-430's quadrant position are different instantiations of the same underlying claim: whether debt is a problem depends on where/how it was taken on, not on the mere fact of its existence.extends ←From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI · p5 — TBM 430 frames technical debt purely as a financing choice at the code/portfolio level, with reversibility a function of portfolio quadrant. Storey's tri-layer model extends this by adding two further loci (people, artifacts) where the financing metaphor breaks down -- intent debt, unlike financial-style technical debt, can become genuinely irrecoverable rather than merely costly to service.
- explicitdevelopedLiquidation is not inherently a failure; refusing to liquidate -- continuing to build an asset that has never proven its value (the Build Trap) -- is the more common and more damaging failure.conf: highextends ←John Cutler's Post · p14 — Extends Cutler's own Build Trap concept to a fuller list of eight organizational traps, with the same unresolved 'AI can help or deepen it' symmetric structure the corpus already flags as under-specified in his tbm-430 piece.
- explicitcorroboratedA platform's worth is determined by whether it measurably improves the value/carrying-cost economics of the assets that depend on it -- not by how much it ships or how many teams are made to use it.conf: highsupports ←TBM 390: Governance by Principle, Not by Template · p11 — Both argue a platform's/deep-capability's worth must be judged by its longer-horizon, indirect value contribution rather than short-term, visible shipping output.
- explicitCompulsory platform adoption (the 'Mandate Trap') is routinely mistaken for evidence that a platform is actually improving anyone's economics.conf: mediumsupportsShifting Platform Development from Projects to Products · p10 — Both identify the same failure mode from different angles: the InfoQ piece notes internal platforms lack a real market's exit/choice so mandate can substitute for genuine demand; TBM 430's 'Mandate Trap' names the same substitution explicitly as a platform-economics trap.
- explicitdevelopedPortfolio health is not just a snapshot of the current mix of assets -- it is also a function of what is flowing between categories, how fast, and whether anyone is intentionally managing that movement.conf: highextends ←TBM 390: Governance by Principle, Not by Template · p6 — Both treat portfolio/investment health as a property of durable units and their flows over time, not of discrete time-boxed projects.
- explicitcorroboratedAI does not eliminate complexity, coupling, coordination, uncertainty, or decay in a software portfolio; it changes the cost, speed, and feasibility of responding to them -- including the feasibility of responding badly.conf: highextendsTBM 415: Demand Mix, Discovery, and AI as a (Dys)function Multiplier · p2 — Both state the same amplifier thesis -- AI does not fix underlying dysfunction, it accelerates whatever is already there -- but TBM 415 applies it to the product-discovery funnel while TBM 430 extends it to portfolio/technical-debt economics, generalizing the claim to a second domain.supports ←TBM 432: Bundling & Unbundling Capabilities (and AI) · p6 — Both propositions make the identical 'physics vs. variables' move about AI: TBM 430#p7 says AI does not eliminate complexity/coupling/coordination/decay in a software portfolio, only changes the cost/speed/feasibility of responding to them; TBM 432#p6 makes the same claim one level up, about capability motions generally. TBM 432 generalizes TBM 430's portfolio-specific finding into Cutler's cross-essay methodological stance.
- explicitBecause AI enters an existing, non-neutral portfolio (a specific mix of bets, winners, drag, and aging assets), the operative question is not whether AI makes work faster but which movement -- toward healthier or more pathological economics -- it is being used to accelerate.conf: high
- explicitThe 'pure' movements on the 2x2 (straight up, down, left, right) are abstractions; real portfolio moves are mixed trade-offs -- growth usually adds some drag, cutting carrying cost usually sacrifices some value.conf: high
- implicitBecause AI shifts coefficients and thresholds rather than the portfolio's underlying dynamics, organizations that already move their portfolio intentionally (disciplined refinancing and liquidation) will compound their advantage faster with AI, while organizations with unmanaged or accidental movement (unchecked Build Traps, Mandate-Trap platforms) will accumulate the same failures faster and more expensively.conf: mediumextendsTBM 416: Investment Stewardship (As Habit) · p10 — TBM 416 claims organizations that invest in codebase 'gardening' compound their advantage over peers; TBM 430's implicit claim about intentional-movement organizations compounding faster under AI generalizes this from codebase maintenance specifically to portfolio-movement discipline broadly.
- implicitdevelopedWhether AI use in a given system is beneficial or harmful cannot be assessed from the technology alone; it requires first diagnosing which of the four quadrant/trap positions the asset already occupies.conf: mediumextends ←TBM 431: The Denominator That Matters · p11 — TBM 430 argues AI's benefit or harm can't be judged from the technology alone -- it first requires diagnosing which portfolio quadrant/trap an asset occupies. TBM 431 makes the analogous move for org-wide AI success: the Social Contract must be diagnosed first, as a gating precondition, before the numerator terms matter at all.
Arguments
The critical question when deploying AI into any part of a software organization is 'which movement are we asking AI to accelerate,' not 'will this make us faster.' strength: medium
Explicit premises:
- AI enters an existing portfolio with a particular mix of bets, winners, drag, and aging assets -- it does not enter a neutral system.
- The same AI capability can improve the economics of the portfolio or deepen the pattern that created the problem, depending on where it's applied.
Implicit premises:
- Speed itself is not intrinsically valuable -- it is valuable only when applied to a movement that improves portfolio economics.
- Organizations cannot reliably predict in advance which direction a given AI application will accelerate without first locating the asset on the portfolio diagram.
Inferences:
- If AI's effect depends on the direction of the movement it accelerates, then speed alone is not a sufficient decision criterion for adopting AI in a given system.
- Because organizations don't reliably know their portfolio position in advance, asking 'faster in which direction' functions as a diagnostic prerequisite to using AI safely, not an afterthought.
Technical debt should be evaluated relative to an asset's portfolio position rather than treated as a uniformly good or bad practice. strength: high
Explicit premises:
- Debt is defined as accepting higher future carrying costs in exchange for reaching value sooner.
- In Incubate, debt is dangerous because the asset's value is unproven.
- In Compound, debt can be rational leverage if it helps expand returns.
- In Refinance, the debt's interest is consuming too much of the returns, so restructuring is the needed move.
- In Liquidate, the asset no longer creates enough value to justify either the debt or the cost of repaying it.
Implicit premises:
- The moral/practical valence of a debt-taking decision is not a property of the code itself but of the economic context (quadrant position) the code sits in.
Inferences:
- Since the same technical choice (taking on debt) yields opposite outcomes depending on quadrant, judging debt in isolation from portfolio position is a category error.
- The question 'is this debt good or bad' must be replaced with 'which quadrant is this asset in.'
Narratives
- The generic arc of a startup: begins as a cheap, low-value Incubate bet; some prove their value and move to Compound; as they scale, carrying costs rise, pushing them to Refinance; a healthy company then either restores the economics or eventually Liquidates. Other bets never prove value, and if the team keeps building anyway, the product moves right without moving up -- the Build Trap.
→ Illustrates the motion/arc idea and introduces the Build Trap as a named failure pattern; serves as the archetypal case the rest of the piece (the AI section especially) keeps returning to.
Questions addressed
- ✅ What value does this asset create, what does it cost us to carry, and what should we do next?
Answered structurally by the 2x2 diagram: the answer is read off the asset's quadrant position (Incubate/Compound/Refinance/Liquidate). - ✅ Which direction is an asset moving, how quickly, and is that movement intentional?
Answered by the 'Motion and Arc' and 'An Intentional Portfolio' sections: movement can be intentional, an unavoidable byproduct of growth/aging, or accidental (oversight, avoidance, negligence). - ✅ Which movement are we asking AI to accelerate?
Answered qualitatively via four worked situations (Build Trap, Limits to Growth, Success Trap, Zombie Portfolio), each showing AI can accelerate a healthy or pathological movement depending on how it's applied -- though no decision procedure is given for telling which in advance. - ⭕ How do you actually measure 'value created' and 'carrying cost' for a real software asset, in practice?
- ⭕ Who has the organizational authority to decide an asset is in the Build Trap or should be liquidated, and what happens when that decision threatens careers, teams, or headcount?
Gaps
- incompleteThe entire framework depends on placing an asset on the value-created x carrying-cost 2x2, but the piece never operationalizes either axis -- no metrics, proxies, or even a single worked numeric example are given for how a team would actually locate a real asset on the diagram. Every judgment in the piece (Incubate vs. Compound, rational leverage vs. dangerous debt) presupposes an assessment the piece itself never shows how to make.
Read next: extract-tbm-416-investment-stewardship-as-habit's argument that ROI understanding is 'continuously practiced behaviors, not a calculation' supplies the missing discipline (habitual signal-gathering) this piece assumes but doesn't build; DORA/Core 4 cost-of-delay proxies could operationalize 'carrying cost' concretely. - incompleteCutler opens by conceding this is 'absolutely not a new idea' (software as a portfolio of assets/investments/bets/liabilities) but never names or differentiates from the obvious antecedents his own framing invites comparison to -- most directly the BCG growth-share matrix (Question Marks/Stars/Cash Cows/Dogs maps closely onto Incubate/Compound/.../Liquidate) and Kent Beck's Explore/Expand/Extract company-lifecycle model already in this corpus. The self-effacing 'none of the underlying ideas are especially new' reads as honest but is never cashed out into an actual comparison of what, if anything, the carrying-cost axis adds.
Read next: The explore-expand-extract concept (Beck's 3X) already in this corpus for a direct lifecycle-model comparison; BCG growth-share matrix literature for the portfolio-management antecedent. - incompleteThe piece analyzes portfolio movement from a God's-eye systems view and never addresses the political economy of admitting an asset belongs in Liquidate or a Build Trap -- whose careers, teams, and budgets depend on the asset continuing, who has the authority to call the move, and what happens when the people who benefit from an asset's continuation are also the people who would have to authorize its liquidation. This is the same organizational-authority gap already flagged in extract-tbm-416-investment-stewardship-as-habit's open gaps about who has standing to insist on stewardship habits.
Read next: extract-tbm-416-investment-stewardship-as-habit#g1 (authority to insist on stewardship habits); sunk-cost and loss-aversion behavioral-economics literature; organizational-debt concept. - incompleteEach of the four AI walkthroughs (Build Trap, Limits to Growth, Success Trap, Zombie Portfolio) is structured as a symmetric 'AI can help X, or AI can make X worse' pair, with no criterion offered for telling which effect will occur in a given organization before the fact. This is a more specific, but still undiagnosed, version of the same problem already flagged against extract-tbm-415-demand-mix-discovery-ai-dysfunction-multiplier (that Cutler treats AI as a uniform amplifier without a way to predict, case by case, which effect dominates) -- TBM 430 segments by portfolio position instead of by AI application type, but the underlying diagnostic gap (predicting the branch in advance) persists at the finer grain.
Read next: extract-tbm-415-demand-mix-discovery-ai-dysfunction-multiplier (the sibling gap about AI's heterogeneous effects); decision-making concept for what a genuine ex-ante diagnostic would require. - uninformedThe 'Zombie Portfolio' term is used in the AI section as if it were already established, but no such trap was defined in the earlier 'The Traps' section (which named only Build Trap, Limits to Growth, and Success Trap). The piece also asserts all its central claims (the four traps, the six platform traps, the debt-by-quadrant claims) with no citation, case study, or empirical data -- every claim rests entirely on the stipulated diagram, not on evidence external to it.
Read next: None of the corpus's existing case-study or empirical-measurement documents (e.g. DORA & Engineering Metrics) are drawn on here; a rigorous treatment would need to show the traps occurring in named, evidenced organizations rather than as archetypes.
Related documents
- Shifting Platform Development from Projects to Products
- TBM 416: Investment Stewardship (As Habit)
- TBM 415: Demand Mix, Discovery, and AI as a (Dys)function Multiplier
- The "funhouse mirror": How AI reflects the hidden truths of your software pipeline
- Fragments: February 18
- AI Enthusiasts Are in a Race Against Time, AI Skeptics Are in a Race Against Entropy
- The Pulse: AI load breaks GitHub – why not other vendors?
- 2024_final_dora_report
- State Of AI-Assisted Software Development
- AI-Assisted Software Development: Team Profiles and Capabilities for Putting Research into Action