If you’re leading software-intensive product development without a software background, you’ve likely experienced the frustration of teams missing commitments despite clear expectations. You’ve defended delayed projects to executives, scrambled to reallocate resources, or watched initiatives stall for opaque technical reasons. Maybe you’ve sat through status meetings where “technical debt” gets blamed for everything, or listened to architects explain why a “simple” feature request will take six months or longer.
There is something you might be missing. Once you understand it, you’ll be better positioned to design organizations that consistently outperform others. It’s intuitive and easy to remember:
Knowledge flows, like heat.
When knowledge flows freely, teams innovate faster. When it is blocked or moves slowly, even simple innovations stall. Building or replacing accumulated domain knowledge takes significantly more time and energy than most executives anticipate. Realizing the underlying dynamics helps explain why certain team structures consistently succeed while others struggle, why frequent reorganizations reduce innovation capability, and why adding people to underperforming projects burns money without improving outcomes. Your organization has knowledge generators and consumers, where knowledge ‘cools down’ at each handover. Understanding how knowledge moves through organizations, like heat moves through materials, enables better decisions at every level.
The Speed Paradox
Business leaders know that being first to market is the key to success. Under competitive pressure, they may trade quality for short-term product delivery, justifying this by the need to move fast or meet investor timelines. However, this mindset can erode a more valuable capability: the sustained ability to learn, adapt and provide a high-quality customer experience. The next version of the product will be based on this lower quality foundation, slowing the team on the second release.
What is actually being traded is not quality but learning velocity—the rate at which teams discover what customers need and the sustainable ability to deliver that value. Rushing through development with low-quality approaches often slows down the build-measure-learn cycle. As product strategist John Cutler put it recently:
Are you shipping faster than you learn, or learning faster than you ship?
Like poorly insulated systems that lose heat faster than they can generate it, teams that take quality shortcuts spend more time repairing damage than creating value. When your teams are busy repairing quality:
- Market feedback takes longer to incorporate
- Customer needs evolve faster than teams can respond
- Competitors catch up
Luckily, informed CEOs and executives don’t have to choose anymore between quality and speed. The belief in a simple speed-versus-quality tradeoff is outdated. Research conducted by Adam Tornhill at CodeScene has shown that quality is a precondition for speed. There is not even a short-term trade-off. Check out the business costs of of low code quality.
CEOs can make a difference by building a culture of commitment to quality right from the start. It’s also important that investors take notice:
Are you investing in businesses that are ‘chopping down the orchard for firewood,’ or tending it to bear fruit for sustained success?
The “Physics” of Software
Just as physical inventory occupies warehouse space, your product portfolio occupies conceptual space and requires energy to maintain. Software systems carry “weight”. The larger and more complex the system, the more energy it takes to change. Every configuration file, line of code, and supported product adds resistance to change. (see the hidden costs of software inventory).
Large codebases behave like massive iron blocks, where the effort to make changes grows exponentially with complexity. This explains why minor changes in older systems can take weeks or even months.
The thermal model offers a mathematical explanation of Brooks’ Law: adding people to a late project often delays it further, because experienced team members must spend their energy training newcomers instead of writing code. Its like pouring cold water in a warm bath. It also helps explain why offshore teams may struggle with productivity due to high attrition (constant replacement of ‘warm’ bodies with ‘cold’) and distance (loss off heat transmission), and why modernization efforts stretch into multi-year projects when systems have accumulated years of features and dependencies. (temperature resistance)
The model aligns closely with the principles in Team Topologies. Stream-aligned teams optimise knowledge conversion flows by owning entire customer journeys. Platform teams can act as thermal catalysts when they’re well-designed; accelerating knowledge flow by providing high-quality, self-service capabilities that stream-aligned teams can adapt to their needs. But poorly designed platforms become thermal barriers, slowing knowledge cycles through low quality, misaligned roadmaps, and forced dependencies. Enabling teams improve the efficiency of knowledge transfer. Complicated-subsystem teams are ‘heat centres’ concentrate specialized expertise in complex domains
Let’s explore how this plays out in some reality inspired cases. You must have your own examples too!
Case Study: The Offshore Cost Trap
A technology company attempted to reduce development costs by 40 percent through offshore outsourcing. To do so, they downsized their domestic team, which held the institutional knowledge for a complex codebase developed over many years.
In thermal terms, the company tried to move a large, dense body of knowledge across a high-resistance boundary to a team with high turnover and little context. The offshoring team was more than twice as big as the original domestic team. The domestic engineers ended up spending their time coaching offshore developers rather than building value. Development was slowed down.
The initiative failed: while finance hit a short-term optical cost target with ‘more people for less money’, customer satisfaction dropped as response times slowed and defects multiplied.
Lessons:
- Turnover kills knowledge transfer, learning capability cannot build when people leave every year or move to new roles.
- Complex systems do not transfer well across team boundaries
- Cost savings are not real if offshore teams are up to 2.5-3 times the original size.
Better approach: Assign offshore teams complete products or decompose into components with well-defined interfaces (isolation). Ownership encourages accountability and builds context over time.
Case Study: The Acquisition Integration Trap
An enterprise acquired a fast-moving startup for its ability to deliver with high frequency. The goal was to integrate the startup’s agility into the parent company.
Thermally, this meant merging two systems with very different architecture and technologies. The startup’s codebase was not in good shape. It lacked documentation and depended on a few key developers. The enterprise expected the startup to comply with established processes that didn’t fit the faster-moving business model.
The startup’s core developers left within months. Without them, the code was hard to change. Meanwhile, enterprise processes overwhelmed the smaller team. The integration stalled, and ultimately resulted an expensive multi-year rewrite.
Lessons:
- Cultural differences can undermine knowledge sharing and knowledge retention
- Rapid release cycles may hide accumulation of technical debt
- Merging incompatible systems add significant cost rather than delivering value
Better approach: Conduct thorough due diligence. Measure the size and complexity of the codebase, and measure cultural attributes (retention, company loyalty, tenure in role). Initially, keep acquired teams operationally isolated with clear interfaces. The value of an acquisition always lies more in the people and culture than the code.
Case Study: Decomposing the Monolith
A bank’s VP of Engineering committed to breaking a decades-old financial platform into microservices within 18 months. The monolith contained millions of lines of code and embedded business logic known only to long-tenured engineers close to their pension.
The VP significantly underestimated both the cost of recreating decades of accumulated knowledge and the cost of maintaining the old system while developing the new one. The new team, hired from outside the domain, lacked the knowledge to extract logic correctly. Meanwhile, the original team continued changing the monolith to support customer needs. Progress slowed, and costs increased. After several years, only a small subset of functionality had been migrated.
Lessons:
- Breaking systems apart adds coordination complexity
- Legacy platforms hold critical, undocumented knowledge
- Running parallel systems doubles maintenance effort
- Domain expertise takes years to build and cannot be replaced easily
Better approach: Start by modernizing clearly bounded, high-value services. Improve the flexibility of the existing system first. Train experienced developers in new technologies. Replace components incrementally, guided by real customer value.
A note for CFOs:
Treat knowledge as CAPEX, not OPEX
Recognizing the value of accumulated knowledge has implications for how executives should think about talent investments and organizational design.
Engineering talent is often treated as operating expense. In reality, building and retaining a high-functioning R&D team is more like accumulating capital.
Deep domain knowledge compounds over time and experienced engineers are strategic assets.
In high-complexity environments, attrition can cost hundreds of thousands of dollars per engineer, factoring in recruiting, onboarding, and lost momentum. Investments in high-churn teams are effectively knowledge leases rather than building knowledge assets. You pay for the cost of expertise but don’t build long-term capability.
Organizations that treat knowledge workers as capital investments can build enduring competitive advantage. Their most experienced innovators are not just employees, but critical to long-term value creation. The real asset is not just the code itself, but the people who understand the domain and can adapt it quickly to meet customer needs.
Summary and Conclusions
Knowledge flows like heat. It moves through people and systems, slows at departmental and geographical boundaries, and needs energy to maintain. Large systems carry “thermal mass” and resist change. High trust teams with strong knowledge flow can learn, adapt, and innovate faster.
The thermal model helps reveal the speed paradox. Systems built for short-term delivery reduce future ability to learn and respond, predicting declining NPS.
Common strategies like hiring aggressively to meet a deadline, outsourcing or offshoring to optically lower costs, or acquiring startups can backfire when knowledge flow is not carefully managed. Offshore teams often have lower capability to retain knowledge due to higher attrition and cultural factors. Acquisitions can lose value when culture and context are erased. Replacing a monolith with microservices often introduces doubled costs for years.
Understanding knowledge “thermodynamics” may change how you think about team structure, firing and rehiring cycles, and organizational design. By asking “what strategic knowledge do I need to protect?” or “what critical knowledge is at risk in this restructuring decision?”, you will get better outcomes.
In summary: understanding your knowledge assets and flows helps predict which organizational changes will create value, and which will quietly erode it.
Take the temperature of your organization today. The Buffadoo Innovation Amplifier benchmarks your environment, process, code health, and team capability. We benchmark organization giving them insights in their “heat loss” and helped produce practical plans to improve innovation speed and delivery performance. Schedule a conversation at calendly.com/buffadoo/30min