The Illiquidity of Intelligence: Challenging the Financial Orthodoxy in Enterprise Technology Strategy

Executive Synthesis: The Categorical Error of the Portfolio Metaphor

For the past three decades, the governance of enterprise technology has been dominated by a singular, pervasive metaphor: the “portfolio.” Institutionalized through frameworks like Project Portfolio Management (PPM) and its contemporary evolution, Lean Portfolio Management (LPM), this orthodoxy posits that software initiatives are functionally equivalent to financial assets stocks, bonds, or commodities that can be selected, balanced, and divested based on risk and return profiles.¹ Implicit in this worldview are two foundational assumptions regarding the nature of the resources deployed and the assets produced. First, the model assumes the fungibility of the labor force that engineering talent is a uniform, interchangeable resource that can be reallocated across initiatives without significant loss of value.³ Second, it assumes the liquidity of the resulting assets that software systems, like financial instruments, can be easily converted, traded, or divested to liberate capital for new investments.⁵

A rigorous, evidentiary examination of organizational dynamics, software architecture, and behavioral economics reveals that both assumptions are demonstrably false in the context of complex systems engineering. Unlike standardized commodities such as Grade No. 2 yellow corn or fiat currency, which are fungible because their provenance is irrelevant to their value ⁷, software engineers possess deep, tacit domain knowledge that renders them non-fungible; their value is inextricably linked to the specific context of the systems they build.⁸ Furthermore, unlike a stock portfolio where a low-performing asset can be sold instantly to stop losses, software assets are characterized by high “entanglement” and “illiquidity”.⁹ They are not easily decoupled from the enterprise; they accrue “technical debt” that acts as a negative compounding interest ¹¹, and they resist divestiture due to intricate dependencies, as evidenced by the massive complexities involved in corporate splits like eBay/PayPal and HP.¹²

The persistence of this flawed metaphor induces a form of strategic paralysis. By treating illiquid, entangled systems as liquid assets, and non-fungible cognitive experts as interchangeable resources, organizations inadvertently maximize “entangled costs” ¹⁵, accelerate technical debt, and create “zombie projects” that consume vast resources without delivering value.¹⁶ This report argues for a fundamental shift from an investment-management mindset to a product-flow mindset one that recognizes software not as an asset to be hoarded, but often as a liability to be managed, where the true value lies in the flow of business behaviors enabled by stable, cognitively-optimized teams.¹⁸

Part I: The Genealogy of a Flawed Metaphor

To dismantle the current orthodoxy, we must first trace its lineage. The application of portfolio theory to Information Technology is not an indigenous development but a transplant from the worlds of finance and consumer packaged goods (CPG). The rejection of the biological and systemic reality of software in favor of these abstracted models has created a dissonance between strategy and execution.

1.1 The Financial Roots: Markowitz and the Illusion of Independence

The intellectual bedrock of modern IT governance is Modern Portfolio Theory (MPT), pioneered by Harry Markowitz in the 1950s. MPT revolutionized finance by demonstrating that a collection of investments could be managed to maximize return for a given level of risk through diversification.¹ The success of MPT relies on specific properties of financial markets: the assets are distinct, the transaction costs are low, and the liquidity is high. An investor can sell shares in an industrial conglomerate and purchase bonds with near-zero friction. Crucially, the investor’s decision to reallocate capital does not physically disrupt the operations of the companies involved. The capital is abstract and fungible.⁶

In the late 1990s and early 2000s, this concept was imported into IT governance to address the chaos of the “dot-com” boom and the proliferation of “shadow IT.” The promise was seductive: the “quantification of previously informal IT efforts,” enabling objective evaluation of investment scenarios.² However, this transposition ignored a critical distinction. In software, the “investor” (the enterprise) is also the “builder.” The act of reallocating capital (budget) requires the physical reallocation of cognition (developers). While financial capital moves at the speed of light, cognitive capital moves at the speed of human learning. The friction of reallocating a software team is not a trivial transaction fee; it is a profound disruption of the “value stream” that destroys the very capacity it seeks to optimize.¹⁸

Nicholas Carr’s 2003 assertion that “IT doesn’t matter” positioning it as a utility commodity akin to electricity further cemented the view of IT resources as interchangeable inputs.² If IT is a utility, then the labor providing it must be fungible, and the management task is simply one of cost minimization and allocation. This logic, while sound for electricity grids, fails catastrophically when applied to the creative, non-linear work of software engineering.

1.2 The Brand Management Distortion: P&G vs. The Monolith

Parallel to the financial model, enterprise strategy heavily borrowed from the “Brand Management” system pioneered by Neil McElroy at Procter & Gamble (P&G) in the 1930s.²¹ McElroy’s innovation was the creation of the “Brand Man” a dedicated manager responsible for a specific product’s success, distinct from the manufacturing or sales functions. This effectively created a “portfolio of brands” (e.g., Camay vs. Ivory) that competed for resources but shared a corporate infrastructure.²³

This model works in CPG because the products are physically distinct. A bar of soap does not crash because a bottle of shampoo has a manufacturing defect. If P&G decides to divest a brand like Duracell or Pringles, the divestiture is complex but achievable because the product is separable from the parent organism.²⁴ The manufacturing lines can be physically retooled or relocated, and the brand equity is legally transferrable.

In software, the “Brand Manager” evolved into the “Product Manager” or “Project Manager,” but the underlying “product” proved far less separable. Unlike a bar of soap, a software application in a modern enterprise is often a tangled web of shared databases, common libraries, legacy code, and undocumented dependencies.¹¹ When IT organizations attempted to manage these “products” as a portfolio of discrete brands, they encountered the reality of entanglement. A feature in a mobile banking app is not a standalone product; it is a view into a monolithic mainframe transaction system shared by fifty other applications. Managing it as a discrete portfolio item masks the underlying structural dependencies, leading to decisions that look rational on a spreadsheet but cause systemic failure in production.⁹

1.3 The Oscillating Pendulum of Control

The friction between the abstract portfolio view (centralized control) and the tangible execution reality (decentralized knowledge) has led to a decades-long oscillation in organizational design.²⁵

• Centralization (The Portfolio View): This model concentrates decision-making at the top to optimize resource allocation and standardization.²⁷ It aligns with the “financial” view of IT, where a CIO acts as a fund manager, moving “resources” (people) to the highest-yield projects.²⁸ This often leads to increased layers of approval and slower decision-making.
• Decentralization (The Agile View): This model pushes decision-making down to the teams to maximize speed and responsiveness.²⁵ It aligns with the “product” view, acknowledging that those closest to the work possess the necessary tacit knowledge to make decisions.

The failure of traditional PPM lies in its attempt to impose centralized, financial-style liquidity on a decentralized, knowledge-intensive process. As noted in organizational studies, shifting to shared services (centralization) often results in “slower, less agile processes” and “hardened silos,” destroying the very responsiveness the portfolio was meant to optimize.²⁶ The “efficiency” gained by centralizing resources is often an illusion, paid for by the “inefficiency” of context switching and communication overhead.

Part II: The Myth of the Fungible Engineer

The first pillar of the portfolio orthodoxy—fungibility—rests on the assumption that one unit of engineering labor is equivalent to another.⁴ If a project is falling behind, the portfolio manager’s instinct is to “inject liquidity” by adding more “resources.” This reflects a fundamental misunderstanding of the cognitive economics of software development and violates the core tenets of modern organizational psychology.

2.1 The Cognitive Economics of Context Switching

In financial markets, a dollar is a dollar. In software, a developer’s hour is not a fixed unit of output; its value depends heavily on their “context”—the mental model of the system they are modifying. Research indicates that context switching—stopping work on one task to perform another—can consume a massive percentage of a developer’s productive capacity.²⁹

When a developer switches tasks, they must perform a “mental reset.” This involves unloading the current problem state from working memory and loading a different set of logic, variable names, architectural constraints, and business rules.³⁰ This is not instantaneous. It is estimated that context switching consumes 45 to 90 minutes of usable output daily per developer when they are forced to juggle multiple priorities.²⁹ For a team of 20, this hidden tax can amount to over $1 million annually in lost productivity.³¹

Table 1 illustrates the devastating impact of treating staff as “liquid” across multiple projects.

Table 1: The Cost of Context Switching (The “Liquidity Tax”)

Data derived from Gerald Weinberg’s “Quality Software Management” and supported by modern productivity research.²⁹ Shows that treating staff as “liquid” across multiple projects destroys their productive capacity.

When portfolio managers treat teams as fungible pools of labor, assigning them to multiple projects to “optimize utilization,” they effectively fragment the team’s cognitive RAM. The result is a paradox: Higher resource utilization leads to lower throughput. The “resource” is busy 100% of the time, but the “value” is stuck in the friction of context switching.³² The developer is not working on the code; they are working on remembering how to work on the code.

2.2 The Non-Fungibility of Domain Knowledge

The financial definition of fungibility implies interchangeability—that one unit can be substituted for another of like kind without loss of value.³ However, software development is a process of knowledge acquisition, not just code typing. A developer who has spent two years working on a legacy payment gateway possesses “domain knowledge”—an understanding of the edge cases, the regulatory quirks, and the undocumented “ghosts” in the machine.³³

This “Tribal Knowledge” is a critical, intangible asset that is rarely captured in documentation.³³ When a portfolio manager “reallocates” this developer to a new, higher-priority initiative (treating them as a fungible resource), the organization incurs a double cost:

1. Brain Drain: The original team loses the domain expert, slowing down maintenance and increasing the risk of defects.⁸ The remaining team members must spend time rediscovering what the expert already knew.
2. Ramp-Up Latency: The developer is a novice in the new domain, requiring months to achieve proficiency. The “resource” has arrived, but the “capability” has not.

This phenomenon explains why “Project-to-Product” shifts emphasize long-lived, stable teams over project-based staffing.¹⁸ In a product model, the team is the asset. Disrupting the team to “balance the portfolio” is akin to disassembling a factory to use its bricks for a different building; you destroy the productive capacity to salvage the raw material. The cost of re-teaming is not just the administrative cost of moving a headcount; it is the destruction of the team’s collective neural network.³⁴

2.3 Team Topologies and Cognitive Load

The “Team Topologies” framework provides a rigorous counter-argument to the fungibility assumption by introducing the constraint of Cognitive Load.³⁵ Humans have a finite limit on the number of meaningful relationships and complex contexts they can maintain, often referenced as Dunbar’s Number.³⁶

The “Fungibility Limit” dictates that you cannot simply add more people to a complex problem to solve it faster—a principle famously known as Brooks’s Law: “Adding manpower to a late software project makes it later.” More people increase the communication pathways geometrically, increasing cognitive load and decreasing flow.³⁷

Therefore, organizational design must prioritize minimizing cognitive load to maximize flow.³⁸ This requires static, optimized team structures with well-defined interactions, rather than dynamic, fluid pools of “resources” that change with every quarterly budget cycle.

• Stream-Aligned Teams: Focused on a single stream of work to minimize context switching.
• Platform Teams: Focused on reducing the cognitive load of stream-aligned teams by abstracting away infrastructure complexity.³⁹

By respecting these topologies, organizations acknowledge that the cognitive capacity of the team is the constraint, not the budget.

Part III: The Physics of Entanglement (The Illiquidity of Software)

The second pillar of the orthodoxy—liquidity—assumes that software assets can be bought, sold, or decommissioned with relative ease to free up capital.⁶ Real-world evidence suggests that software is inextricably “entangled,” making it one of the most illiquid assets an enterprise can own.

3.1 Entanglement and the “One-Way Door”

In decision theory, a “one-way door” is a decision that is difficult or impossible to reverse.⁴⁰ Selecting a core technology stack, architectural pattern, or data model is often a one-way door because the cost of change (reversibility) is prohibitive.⁴¹

Once code is written and deployed, it becomes entangled with the business processes it supports, the data it generates, and the other systems it talks to. This entanglement creates Technical Debt—not just in the code (poor variability, lack of tests) but in the architecture itself.¹¹

• Hidden Debt in ML Systems: Machine Learning systems exhibit “high-interest” technical debt due to “entanglement” (changing one input feature changes the entire model’s behavior) and “hidden feedback loops”.⁹ The system becomes a fragile web where a change in one area causes unforeseen collapses in another.
• Infrastructure as a Liability: As evidenced by the concept of “Zombie Servers,” infrastructure often persists long after its useful life because the cost and risk of decommissioning (verifying no dependencies exist) outweigh the ongoing opex of keeping it running.¹⁷

The “Entangled Cost” of a software asset is the cost required to untangle it from the rest of the enterprise. This cost is often orders of magnitude higher than the original development cost.

3.2 “Code is a Liability, Not an Asset”

A provocative but essential reframing proposed by industry experts like Dan North is that software is a liability, not an asset.¹⁰

• Asset vs. Liability: An asset has intrinsic value and can be sold. Code has no intrinsic value; it only has value in execution.¹⁹ When at rest, it is a liability that requires maintenance, security patching, and compliance auditing.¹¹
• Inventory as Waste: In Lean manufacturing, inventory is waste. In software, “un-deployed code” or “half-finished projects” are inventory. They represent sunk costs that generate no value but incur “holding costs” (merging conflicts, rotting knowledge).⁴²

This challenges the very foundation of “Asset Management” in IT. We should not be maximizing the size of the software portfolio (hoarding assets) but minimizing the amount of software needed to deliver the desired business behaviors. Every line of code written is a commitment to future maintenance—a future liability on the balance sheet of the team’s cognitive capacity.

3.3 The One-Way Door of Technology Choice

The classification of decisions into “One-Way” and “Two-Way” doors is critical for portfolio management.⁴⁰

• One-Way Doors: High-stakes, irreversible decisions like platform selection or architectural standards. These require deep deliberation because they create massive entanglement.
• Two-Way Doors: Reversible, low-stakes decisions like feature toggles or UI experiments. These should be decentralized to teams to encourage speed.⁴¹

The error of traditional portfolio management is applying the heavy governance of One-Way doors to Two-Way door decisions, slowing down innovation, while often ignoring the entanglement risks of the actual One-Way doors until it is too late.⁴³

Part IV: Case Studies in Illiquidity (The Divestiture Stress Test)

The ultimate test of asset liquidity is divestiture. If software projects were truly like financial assets, a company could simply “sell off” a division’s IT systems along with the business unit. Corporate history shows this is excruciatingly difficult, revealing the true depth of entanglement.

4.1 eBay and PayPal (2015): The Clone Wars

The separation of eBay and PayPal required disentangling a decade of shared infrastructure. It was not a simple matter of reallocating shares.

• The Scope: The separation involved cloning or migrating 9,000 servers, 30,000 end-user devices, 900 applications, and 1,900 vendor contracts.⁴⁴
• The Entanglement: “Everything was in the eBay domain,” meaning PayPal’s entire digital existence was fused with eBay’s.⁴⁴ There was no clean line of separation.
• The Strategy: The CIO adopted a “Clone and Go” strategy.⁴⁴ They realized they could not logically separate the systems; they had to physically duplicate the entire stack. This massive duplication of effort—rebuilding identical networks and data centers—proves that the assets were not liquid. They could not be transferred; they had to be recreated.
• The Cost: The project took “half the time we really needed” and required a massive infusion of resources, freezing innovation for the duration.⁴⁴

4.2 Hewlett-Packard (2015): splitting the Atom

The split of HP into HP Inc. and Hewlett-Packard Enterprise (HPE) was another massive test of IT disentanglement.⁴⁵

• The Challenge: The company lacked a documented IT organization with clear cost allocations, making it nearly impossible to assess the impact of the split on strategies or EBITDA.¹²
• The Reality: The separation revealed that “synergies” (often cited to justify mergers) are actually entanglements. Shared services, which look efficient on a balance sheet, become liabilities during a divestiture because they create “stranded costs”—fixed costs that remain even after the revenue-generating unit is sold.⁴⁶

4.3 The “Synergy” Trap

These cases demonstrate that the drive for “efficiency” through centralization (shared services, monolithic platforms) often destroys “liquidity” (the ability to divest or pivot). When a portfolio manager funds a “shared service” to save money, they are often reducing the future liquidity of the business units that rely on it.⁴⁷ The “savings” are essentially a loan taken out against the future flexibility of the enterprise.

Part V: The Financial Fiction (Accounting, Incentives, and Zombies)

The behavior of IT portfolios is heavily distorted by accounting rules that were designed for manufacturing and real estate, not for intangible digital assets. These rules create perverse incentives that encourage the accumulation of technical debt and the persistence of “Zombie Projects.”

5.1 CapEx vs. OpEx: The Perverse Incentive

Accounting standards like ASC 350-40 (Internal-Use Software) dictate when software development costs can be capitalized (treated as an asset on the balance sheet) versus expensed (treated as an operating cost).⁴⁸

• Capitalization (CapEx): Application development stages (coding, testing) can be capitalized. This spreads the cost over years (amortization), making the current quarter’s profits look better.⁵⁰
• Expensing (OpEx): Preliminary planning and post-implementation maintenance must be expensed immediately, hitting the current quarter’s bottom line.⁵¹

The Distortion: This creates a perverse incentive for portfolio managers to:

1. Favor “New Projects” (CapEx) over “Maintenance” (OpEx): Building a new, potentially unnecessary feature increases the company’s “assets” and protects EBITDA. Fixing technical debt or refactoring (maintenance) is an expense that hurts EBITDA.¹¹ This encourages the proliferation of features and the neglect of systemic health.
2. Discourage Decommissioning: Retiring a legacy system often triggers a write-off of its remaining book value. It is financially “safer” to leave the zombie server running (low OpEx) than to decommission it (potential CapEx write-off and high effort).⁵²

5.2 The Sunk Cost Fallacy and Zombie Projects

The Sunk Cost Fallacy—the tendency to continue an endeavor once an investment has been made—is rampant in software portfolios.⁵⁴

• Psychological Entrapment: “We’ve already spent $5 million on this ERP migration; we can’t stop now.” This bias ignores the “Bygones Principle”—that past costs are irrelevant to future rational decisions.⁵⁶
• Zombie Projects: These are projects that fail to deliver value but refuse to die due to political momentum and the fear of writing off sunk costs.¹⁶ They act as “energy vampires,” sucking resources away from valid initiatives.¹⁷
• Zombie Assets: Similarly, “Zombie Assets” (servers, licenses) persist because no one knows who owns them or what they do. Fear of breaking an unknown dependency (entanglement) prevents decommissioning.¹⁷

5.3 The Cost of “Undoing”

In the physical world, demolition is relatively cheap compared to construction. In software, “undoing” (refactoring, decommissioning) can be more expensive than the original build due to entanglement.¹⁵ This “negative work” is rarely budgeted for, leading to a continuous accumulation of digital detritus that slows down all future work.⁵⁸

Part VI: The Lean Illusion (Critique of Modern PPM)

Recognizing the failures of the project portfolio model, the industry has shifted toward Lean Portfolio Management (LPM) and the Project-to-Product movement. However, these frameworks often face resistance from the entrenched financial orthodoxy and can become “Agile in name only.”

6.1 The Promise and Pitfalls of Lean Portfolio Management (LPM)

LPM attempts to align strategy with execution by funding Value Streams rather than discrete projects.⁵⁹

• The Shift: Instead of “bringing people to the work” (project staffing), LPM “brings work to the people” (stable value stream teams).³²
• The Goal: To maximize flow and reduce the “batch size” of investment, allowing for faster feedback loops and “safe-to-fail” experiments.⁴²

However, the implementation of LPM often collides with reality.

• The Reallocation Illusion: SAFe (Scaled Agile Framework) promotes the idea of dynamically adjusting budgets between value streams.⁵⁹ However, as established in Part II, you cannot simply move budget (and therefore developers) from a “declining” stream to a “growing” stream without incurring massive cognitive re-teaming costs. The “liquidity” of the budget does not translate to the “liquidity” of the capability.⁶¹
• Undefined Streams: Many organizations struggle to correctly identify their value streams, often mapping them to existing organizational silos rather than the actual customer journey, reinforcing the very walls they meant to break down.⁶²

6.2 The Flow Framework and the Disconnect

Mik Kersten’s “Project to Product” thesis argues that the core problem is the disconnect between the “business” (strategy) and “IT” (execution).¹⁸

• Proxy Metrics: Traditional portfolios measure “on time, on budget” (proxy metrics). The Flow Framework measures Flow Velocity, Flow Time, Flow Efficiency, and Flow Load.⁶³
• The Black Box: Business leaders see IT as a “black box” into which requirements go and features come out. They do not see the “Flow Distribution”—the necessary balance between features, defects, risks, and technical debt.⁶³

A major critique of traditional portfolio management is that it fails to account for Flow Distribution. It typically incentivizes 100% feature work (value generation) and 0% debt reduction (asset protection). This inevitably leads to a “tipping point” where the technical debt becomes so high that feature delivery stalls completely—the “entanglement” chokes the flow.⁶⁴

Part VII: Toward a New Orthodoxy (The Un-Portfolio)

To break free from the liquidity illusion, enterprise leaders must adopt a new strategic orthodoxy that aligns with the physics of software and the psychology of teams. This requires a fundamental shift from managing assets to managing capabilities.

7.1 From Managing Assets to Managing Capabilities

The goal of the portfolio should not be to “manage IT assets” but to cultivate business capabilities.

• Stable Teams as the Unit of Value: Acknowledge that the high-performing, domain-expert team is the true asset. Funding should flow to these teams to maintain their health and responsiveness, not to transient “projects”.¹⁸
• Cognitive Liquidity: Instead of trying to make people fungible, organizations should invest in Platform Engineering and Developer Experience (DevEx) to reduce the cognitive load required to build and deploy. This increases the effective liquidity of the organization by making it easier for teams to build new things without being bogged down by infrastructure “entanglement”.³⁹

7.2 The “Two-Way Door” Strategy

To combat the illiquidity of software decisions, strategy must prioritize reversibility.

• Reversibility as a First-Class Citizen: The portfolio governance process should be heavy for One-Way doors (requiring deep analysis) and lightweight for Two-Way doors (encouraging speed). Currently, most organizations apply the same heavy bureaucracy to both, stifling innovation.⁴³
• Experimentation: Adopt a “VC-style” funding model where funding is metered by validated learning outcomes (Two-Way Doors), not by milestone completion (One-Way Doors).⁴²

7.3 Decommissioning as a Core Competence

Organizations must develop a muscular capability for divestiture and decommissioning.

• The “Undoing” Competence: Just as P&G manages the lifecycle of a brand, IT must manage the death of software. This requires budgeting for “negative work”—removing code, retiring servers, and disentangling data.⁵⁸
• Fighting Zombies: Implement rigorous “Zombie Audits” for infrastructure and contracts.¹⁷ Automate the identification of unused assets and create a “safe-to-fail” environment for turning them off (e.g., the “scream test”).

7.4 The Un-Portfolio

The future of enterprise technology strategy lies not in better portfolio management—better spreadsheets, better capitalization rules, better resource leveling—but in Product Flow Management. It requires an acceptance of the messiness of cognitive work, a rejection of the “asset” delusion, and a relentless focus on decoupling, simplification, and the flow of value. We must stop trying to trade our intelligence like a commodity and start nurturing it like a living system.

Table 2: The Orthodoxy vs. The Reality

Geciteerd werk

1. Evolution of Portfolio, Program, and Project Management – Threws, geopend op januari 9, 2026, https://threws.com/evolution-of-portfolio-program-and-project-management/
2. IT portfolio management – Wikipedia, geopend op januari 9, 2026, https://en.wikipedia.org/wiki/IT_portfolio_management
3. A Tampa CPA Explains the Difference Between Fungibility and Liquidity, geopend op januari 9, 2026, https://www.reliancecpa.com/fungibility-liquidity
4. Fungibility – Wikipedia, geopend op januari 9, 2026, https://en.wikipedia.org/wiki/Fungibility
5. What Is Financial Liquidity? Definition, Ratios & Examples – Ramp, geopend op januari 9, 2026, https://ramp.com/blog/business-banking/what-is-liquidity
6. Understanding Liquidity and How to Measure It – Investopedia, geopend op januari 9, 2026, https://www.investopedia.com/terms/l/liquidity.asp
7. Understanding Fungibility in Finance and Its Importance – Investopedia, geopend op januari 9, 2026, https://www.investopedia.com/terms/f/fungibility.asp
8. The value of domain knowledge. : r/ExperiencedDevs – Reddit, geopend op januari 9, 2026, https://www.reddit.com/r/ExperiencedDevs/comments/1hcme1w/the_value_of_domain_knowledge/
9. Hidden Technical Debt in Machine Learning Systems – NIPS papers, geopend op januari 9, 2026, https://papers.neurips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems.pdf
10. Code is a liability (not an asset) | by Cory Doctorow | Jan, 2026 – Medium, geopend op januari 9, 2026, https://doctorow.medium.com/https-pluralistic-net-2026-01-06-1000x-liability-graceful-failure-modes-d69f384af9e4
11. What is Technical Debt? | IBM, geopend op januari 9, 2026, https://www.ibm.com/think/topics/technical-debt
12. Overcoming the challenges of IT separation for M&A success – KPMG International, geopend op januari 9, 2026, https://kpmg.com/ch/en/insights/deals/it-separation-challenges-mergers-acquistitions.html
13. Top 10 Questions about the eBay-PayPal Separation, geopend op januari 9, 2026, https://www.ebayinc.com/stories/news/top-10-questions-about-the-ebay-paypal-separation/
14. HP Milestones: A Look Back, As Tech Giant Splits In Two | InformationWeek, geopend op januari 9, 2026, https://www.informationweek.com/it-infrastructure/hp-milestones-a-look-back-as-tech-giant-splits-in-two
15. Ops and Tactics Core Rulebook 6th Edition | PDF | Shotgun | Marksman – Scribd, geopend op januari 9, 2026, https://www.scribd.com/document/502426477/Ops-and-Tactics-Core-Rulebook-6th-Edition
16. Untrapping Capital: Build A Value Management System with ServiceNow, SAFe, and Agentic AI, geopend op januari 9, 2026, https://www.servicenow.com/community/spm-blog/untrapping-capital-build-a-value-management-system-with/ba-p/3424710
17. Beware of the Zombies in Your Data Center – Nlyte Software, geopend op januari 9, 2026, https://www.nlyte.com/blog/beware-of-the-zombies-in-your-data-center/
18. Project to Product – IT Revolution, geopend op januari 9, 2026, https://itrevolution.com/product/project-to-product/
19. 2024 – eferro’s random stuff, geopend op januari 9, 2026, https://www.eferro.net/2024/
20. The Origins of Portfolio Theory | The American College of Financial Services, geopend op januari 9, 2026, https://www.theamericancollege.edu/knowledge-hub/insights/the-origins-of-portfolio-theory
21. Origins Of Brand Management – Branding Strategy Insider, geopend op januari 9, 2026, https://brandingstrategyinsider.com/origins-of-brand-management/
22. The History of Procter & Gamble’s Brand Strategy – LiveAbout, geopend op januari 9, 2026, https://www.liveabout.com/market-research-history-brand-management-at-pandg-2297141
23. Evolution of Brand Management to Cohort Management: A Critical Study – imanager, geopend op januari 9, 2026, https://imanagerpublications.com/assets/htmlfiles/JMGT4(4)Mar-May20101157.html
24. P&G Brand Management Strategies: Building Brand Equity – Desklib, geopend op januari 9, 2026, https://desklib.com/study-documents/pg-brand-management-2/
25. Cross-Functional Org Models Boost Innovation And Operational Efficiency – Forrester, geopend op januari 9, 2026, https://www.forrester.com/blogs/cross-functional-org-models-boost-innovation-and-operational-efficiency/
26. Striking a Balance: How to Preserve the Benefits of a Decentralized Model When Shifting to Shared Services – Kotter International Inc, geopend op januari 9, 2026, https://www.kotterinc.com/striking-a-balance-how-to-preserve-the-benefits-of-a-decentralized-model-when-shifting-to-shared-services/
27. Centralization versus decentralization: what’s right for you? – AlixPartners, geopend op januari 9, 2026, https://www.alixpartners.com/media/17046/ap_centralization_versus_decentralization_apr_2016.pdf
28. Centralized vs. Decentralized IT Organizational Structures – IT Executives Council, geopend op januari 9, 2026, https://itexecutivescouncil.org/centralized-vs-decentralized-it-organizational-structures/
29. The Hidden Cost of Context Switching – BasicOps, geopend op januari 9, 2026, https://www.basicops.com/blog/the-hidden-cost-of-context-switching
30. Context Switching in Software Engineering: How Developers Lose Productivity – Trunk.io, geopend op januari 9, 2026, https://trunk.io/learn/context-switching-in-software-engineering-how-developers-lose-productivity
31. The Hidden Cost of Context Switching: Why Your Most Productive Hours Are Disappearing | by Dennis Peter Munyao | Medium, geopend op januari 9, 2026, https://medium.com/@codewithmunyao/the-hidden-cost-of-context-switching-why-your-most-productive-hours-are-disappearing-43c5b501de19
32. Is It Time to Rethink Traditional Portfolio Management? [Infographic] – Planview Blog, geopend op januari 9, 2026, https://blog.planview.com/is-it-time-to-rethink-traditional-portfolio-management/
33. Software Development Cost: A Guide to Legacy Systems, Rewrites, and Microservices, geopend op januari 9, 2026, https://www.iteratorshq.com/blog/software-development-cost-a-guide-to-legacy-systems-rewrites-and-microservices/
34. Rework is Costing Your Company Millions — It’s Time to Cut Back – Code Climate Blog, geopend op januari 9, 2026, https://codeclimate.com/blog/rework-costs-millions
35. Building High-Performing Teams with Team Topologies – IT Revolution, geopend op januari 9, 2026, https://itrevolution.com/articles/building-high-performing-teams-with-team-topologies/
36. Newsletter (MAY 2025): When Teams Grow Too Large: Solving Cognitive Load Issues, geopend op januari 9, 2026, https://teamtopologies.com/news-blogs-newsletters/when-teams-grow-too-large-solving-cognitive-load-issues
37. Team Cognitive Load — Industry Examples — Team Topologies – Organizing for fast flow of value, geopend op januari 9, 2026, https://teamtopologies.com/industry-examples/tag/Team+Cognitive+Load
38. Newsletter (July 2024): Mastering Team Effectiveness: The Power of Managing Cognitive Load, geopend op januari 9, 2026, https://teamtopologies.com/news-blogs-newsletters/2024/7/23/newsletter-july-mastering-team-effectiveness-the-power-of-managing-cognitive-load
39. How Platform Teams Reduce Cognitive Load: Insights from Team Topologies, geopend op januari 9, 2026, https://teamtopologies.com/news-blogs-newsletters/2024/6/10/newsletter-june-2024-how-platform-teams-reduce-cognitive-load
40. One-way vs Two-way door decisions – Thoughtbot, geopend op januari 9, 2026, https://thoughtbot.com/blog/one-way-vs-two-way-door-decisions
41. One-way & Two-way Door Decisions – Medium, geopend op januari 9, 2026, https://medium.com/one-to-n/one-way-two-way-door-decisions-a0e29029e200
42. Lean Portfolio Manifesto: A conversation-starter – Work Life by Atlassian, geopend op januari 9, 2026, https://www.atlassian.com/blog/jira-align/lean-portfolio-manifesto
43. Decision Making in the Era of Growing Constraints (Part 1) – Planview Blog, geopend op januari 9, 2026, https://blog.planview.com/decision-making-in-the-era-of-growing-constraints-part-1/
44. The IT strategy behind PayPal’s spinoff from eBay – CIO, geopend op januari 9, 2026, https://www.cio.com/article/243063/the-it-strategy-behind-paypals-spinoff-from-ebay.html
45. HP and the Case for Corporate Spinoffs – Knowledge at Wharton, geopend op januari 9, 2026, https://knowledge.wharton.upenn.edu/article/hp-and-the-case-for-corporate-spinoffs/
46. Corporate divestitures: Considering stranded costs | McKinsey, geopend op januari 9, 2026, https://www.mckinsey.com/capabilities/strategy-and-corporate-finance/our-insights/the-cost-of-undoing-business
47. Managing Divestitures of Entangled Business Assets – Insurance Thought Leadership, geopend op januari 9, 2026, https://www.insurancethoughtleadership.com/operational-efficiency/managing-divestitures-entangled-business-assets
48. Capitalize vs. Expense | Cost Accounting Rules + Examples – Wall Street Prep, geopend op januari 9, 2026, https://www.wallstreetprep.com/knowledge/capitalize-vs-expense/
49. How to Capitalize Your Company’s Internal-Use Software Costs | Cohen & Co, geopend op januari 9, 2026, https://www.cohenco.com/knowledge-center/insights/september-2024/how-to-capitalize-your-company-internal-use-software-costs
50. Software Capitalization Tax Rules & Costs Explained – Jellyfish.co, geopend op januari 9, 2026, https://jellyfish.co/library/software-capitalization/
51. Accounting for Software – Finance & Business – UC Davis, geopend op januari 9, 2026, https://financeandbusiness.ucdavis.edu/finance/accounting-financial-reporting/cap-asset/software
52. Decommissioning and asset valuation: a complex relationship – Blog | Barnett Waddingham, geopend op januari 9, 2026, https://www.barnett-waddingham.co.uk/comment-insight/blog/decommissioning-and-asset-valuation/
53. Accounting for decommissioning, restoration and similar provisions to make good (RMG 114) | Department of Finance, geopend op januari 9, 2026, https://www.finance.gov.au/publications/resource-management-guides/accounting-decommissioning-restoration-and-similar-provisions-make-good-rmg-114
54. Sunk costs and the sunk cost fallacy: A business decision-making guide – Volopay, geopend op januari 9, 2026, https://www.volopay.com/blog/sunk-costs-and-sunk-cost-fallacy/
55. Sunk Cost Fallacy and Failing Initiatives – Profit.co, geopend op januari 9, 2026, https://www.profit.co/blog/behavioral-economics/sunk-cost-fallacy-and-failing-initiatives/
56. Sunk cost – Wikipedia, geopend op januari 9, 2026, https://en.wikipedia.org/wiki/Sunk_cost
57. 5 ways technology can mitigate the risks of ghost and zombie assets – Sage, geopend op januari 9, 2026, https://www.sage.com/en-us/blog/technology-mitigate-risks-ghost-zombie-assets/
58. THE IMPORTANCE OF DECOMMISSIONING IN ASSET INTENSIVE INDUSTRIES – Oracle, geopend op januari 9, 2026, https://www.oracle.com/webfolder/s/delivery_production/docs/FY15h1/doc8/The-importance-of-decommissioning.pdf
59. Flow-Based Lean Portfolio Management (LPM) in SAFe | Agile Seekers, geopend op januari 9, 2026, https://agileseekers.com/blog/flow-based-lean-portfolio-management-in-safe
60. Implementing SAFe: Lean Budgets – Agility at Scale, geopend op januari 9, 2026, https://agility-at-scale.com/safe/lean-budgets/
61. Are Your “Value Streams” Keeping You Stuck in the Past? – InfoQ, geopend op januari 9, 2026, https://www.infoq.com/articles/value-streams-stuck-past/
62. Lean Portfolio Management Blog Series Part 1: An Overview, geopend op januari 9, 2026, https://www.cprime.com/resources/blog/lean-portfolio-management-overview/
63. Book notes: Project to Product – Daniel Lebrero, geopend op januari 9, 2026, https://danlebrero.com/2021/02/10/project-to-product-flow-framework-summary/
64. The Flow Framework®: A Prescriptive Approach for Transitioning from Project to Product, geopend op januari 9, 2026, https://www.planview.com/resources/articles/flow-framework-a-prescriptive-approach-for-transitioning-from-project-to-product/
65. Beware of zombie contracts: A terrifying tale of auto-renewals – Agiloft, geopend op januari 9, 2026, https://www.agiloft.com/blog/beware-of-zombie-contracts-a-terrifying-tale-of-auto-renewals/