Shared context, sustainable delivery: what the business needs to understand about building software
This article is authored by Matthew Skelton, CEO/CTO of Conflux and co-author of ‘Team Topologies’ and ‘Adapt Together’.
A recent post on LinkedIn by Nick Selby brilliantly highlights a troubling and familiar dynamic in our industry: executive leadership teams unsettlingly conflate feature delivery with "engineering velocity," implicitly trading away long-term stability just to keep feature releases moving.
This observation cuts to the heart of a problem I see time and time again. There is a widening misunderstanding between business and technology because executives often lack an accurate understanding of the dynamics of how software is actually built. While engineering-first organizations like AWS and Google have reached massive scale by addressing exactly this issue, other organizations suffer from leaders who make invalid assumptions about what is needed to sustainably evolve digital products.
The ‘feature factory’ and the ‘technical debt’ impasse
The friction typically starts with misaligned incentives. As Nick Selby points out, sales leaders often view the engineering department as simply the function that ships features to close deals. Often, they do not understand the underlying dependencies required for software evolution; they view internal Platforms and Enabling teams as irrelevant - an exercise in "gilding the lily" rather than essential infrastructure.
When the business prioritizes immediate feature delivery over systemic health, it initiates a negative spiral that drives up the cost of change and slows down software evolution over time. This is where the infamous impasse around ‘technical debt’ usually rears its head.
Originally coined by Ward Cunningham, technical debt was meant to describe a deliberate strategy of trading perfect understanding for speed, with the intention of correcting the code later as the domain is better understood. Today, however, the term is misused as a catch-all excuse for engineering friction caused by rushed deadlines, lack of context, and tight coupling.
This misuse creates a frustrating stalemate. Business executives ask, "Why can't we go faster?" and engineers reply, "Technical debt". The conversation stops there. When executives ask how to fix it, engineers might suggest they need two months of downtime - a non-starter for any business leader. When leaders don't understand the technical friction, they see it as purely an engineering problem rather than an organizational one. In reality, the organization has failed to establish the right incentives and shared context to build software cost-effectively.
Reframing the conversation: Targeted investments and risk reduction
To break this impasse, we must change how we communicate technical realities to business leaders. We need tools that translate technical debt into executive-relevant metrics, specifically focusing on the cost of change.
I recently sat down for lunch with the CEO of a high-technology company in Central Europe. He expressed his deep frustration with ‘technical debt,’ viewing it almost as a persistent excuse used by his engineering teams. I introduced him to the concept of viewing codebase health through the lens of human team boundaries and code evolution risk, specifically using a tool called CodeScene.
CodeScene doesn't just look at syntax; it highlights where the bugs are likely to appear, who has contributed to the code, and how risky a piece of code is to evolve. It can point directly to areas where the cost of change is highest, allowing executives to focus technical debt removal efforts on specific, high-risk parts of the codebase. When I explained this, the CEO's reaction was immediate: "That's exactly the conversation that I need to hear". He was willing to invest to fix the systems, but he refused to do so without knowing the investment was targeted.
I experienced a very similar breakthrough during a recent meeting with the COO of an insurance company in Asia. They already had a trial license for CodeScene but weren't fully utilizing it. When we shifted the conversation to using the tool to identify proxy metrics for the cost of change and pinpoint opportunities for focused investment, the COO agreed that this was exactly what he needed to make better, data-driven investment decisions. Executives are happy to fund remediation efforts when they can see clear, targeted business value in risk reduction and friction removal.
Understanding the hidden complexities of digital services
One of the greatest challenges in software is its invisibility. You cannot simply walk into a data center and see the dependencies at work. To help non-technical stakeholders grasp the hidden complexities of digital services, I often use the metaphor of a large-scale fruit or flower farm.
Imagine the massive, highly automated greenhouses in the Netherlands. Salespeople in the agricultural business know you cannot demand high volumes of new tomato varieties or tulips without investing heavily in the underlying growing environment. In software, we must foster that exact same understanding.
The concepts of a modern automated greenhouse map to the key concepts in software delivery:
| Greenhouse Concept | Software Delivery Concept | Description |
|---|---|---|
| Flowers / Fruits | Software Features | The final produce that the sales team wants to sell and deliver to customers. |
| Soil / Growth Medium | The Codebase | The foundational environment from which digital products are grown. If its health and quality are poor, sustainable delivery is impossible. |
| Greenhouses, Watering Systems, & Fertilizer | IT / Cloud Infrastructure | The underlying platforms and support systems that keep the environment running and ensure the code has what it needs to function. |
| Layout of Growing Beds (Enabling Robot Harvesters) | Software / Systems Architecture | The system's structural design dictates how efficiently work gets done, enabling automated harvesting and smooth operations. |
While digital systems are fundamentally different from farming, this analogy illustrates why maintaining the "growth medium" and infrastructure is a prerequisite for delivering the "produce" that sales teams want.
We can no longer afford the widening gap between business and technology. The executives who take the time to deeply understand these dynamics, who learn to see the greenhouse and soil that surrounds and feeds the development of their digital products, will be the ones who successfully govern and scale the AI-native organizations of the future.
If you’d like to discuss how to enable shared context and sustainable delivery in your organization, get in touch today.
