Four Executives. Four Problems. One Backlog.
Why Nobody Owns the Outcome.
VISIT MY SUBSTACK FOR FREE ARTICLES, VIDEOS & PODCASTS >>
I’ve watched the same meeting happen inside different companies more times than I can count. The CEO asks why engineering cannot deliver. The CTO explains technical constraints. The CFO questions the budget. The CPO argues about priorities. Everyone leaves frustrated. Nothing changes.
Six months later, they are having the same conversation about the same backlog with bigger numbers and fewer options.
The problem is not that any of these executives is wrong. The problem is that they are all right. And the reason nothing gets resolved is that nobody in the room owns the outcome. They each own a piece. The piece they own makes complete sense from their perspective. But the system that produces the backlog, and the structural gap between having leaders and having delivery accountability, sits in the space between all four of them. That space has no name on the org chart.
That is the Ownership Gap. And it is the root cause of every backlog crisis I have ever seen.
What Each Executive Sees
The CEO sees opportunity cost. Every quarter spent maintaining legacy systems instead of building new capabilities represents market share that will not come back. The CEO approved the digital transformation, funded the cloud migration, signed off on the customer portal rebuild. Engineering said six months. That was a year and a half ago. The CEO starts making promises with no confidence they will be kept. That is when credibility erodes, with the board, with customers, and eventually with themselves.
The CTO sees technical debt. They are living with years of shipping features on architecture that was never designed to support them. Every simple request turns complex. “Just add an export button” requires pulling data from three incompatible databases, formatting it in ways the system does not support, and integrating with third party APIs that might change without notice. The CTO knows the current architecture physically cannot support the company’s three year strategy. But translating that into language the CFO will fund and the CEO will prioritize is a different problem entirely.
The CPO sees broken promises. Every backlog item represents a commitment the company made and has not kept. Sales lost a $500,000 deal to a competitor who had the integration feature that has been sitting in the backlog for fourteen months. Meanwhile, engineering ships capabilities that customers never adopt. The company measures activity instead of outcomes, celebrates velocity instead of value, and calls it progress.
The CFO sees waste. Duplicate systems, cloud resources that do not deliver value, development work that never ships. Five years ago, a new feature cost $50,000 to build. Today, with architectural complexity, integration requirements, and testing overhead, that same feature costs $200,000. The unit economics of software development have collapsed. And here is the paradox: every dollar spent on engineering hits the income statement, creating pressure to minimize spending, which perpetuates the cycle of underinvestment.
Four executives. Four legitimate problems. Four different solutions. And not one of them addresses the structural issue underneath all of it.
The Backlog Illusion in Four Stages
What makes the backlog crisis particularly dangerous is that it sneaks up on you. I have seen enough organizations go through this cycle that I can describe the stages from memory.
At 100 items, it feels normal. Every company has work they have not gotten to yet. The team can still remember what most items are about. Stakeholders can track what matters. The backlog feels like a planning tool, not a problem.
At 400 items, friction starts. People disagree about priorities because there is no clear framework for making tradeoffs. Estimates keep slipping. But the company is still functional. The dysfunction feels manageable. Everyone agrees they just need better prioritization.
At 800 items, the backlog becomes toxic. Nobody believes the estimates anymore. Promises stop being credible. Engineering teams start hiding work from the official tracking system because if something is not in Jira, leadership cannot demand status updates about it. The conversation shifts from solving problems to questioning basic competence.
Past 1,200 items, the backlog creates its own gravity. Every new initiative gets sucked in. The backlog grows faster than engineering can reduce it. Everyone knows the trajectory is unsustainable, but nobody knows how to reverse it because the problem is not the backlog itself. It is the system that creates the backlog.
That progression is the Backlog Illusion in its purest form. Tickets are being worked. Velocity metrics look reasonable. Sprint reviews happen on schedule. But the actual delivery of business outcomes has stalled. The organization is busy without being productive. The backlog is not shrinking. It is shapeshifting.
Why Adding Engineers Makes It Worse
The instinctive response is to hire. The CFO sees the delivery gap and approves headcount. The company adds 30% more engineers. The backlog grows 50%.
This is the Coordination Tax at work. Every engineer added to a misaligned model increases overhead 15 to 25% while increasing output only 5 to 10%. More people means more coordination overhead, more work in progress that never finishes, more handoffs, more meetings, and more alignment sessions that consume the very time the new hires were supposed to create.
The system that produces the backlog remains unchanged. You have more people feeding it, more stakeholders requesting from it, and more complexity making every item harder to execute. Headcount is not the problem. The operating model is the problem.
What the Companies That Figure It Out Actually Do
The companies that solve this do not just reduce their backlogs. They change the system that creates the backlog in the first place.
They stop adding every idea that gets mentioned. They build clear ownership into the delivery model so that every critical decision has a name attached to it, not a committee. They restructure around small, autonomous teams that own a full slice of the product instead of distributing ownership across functional silos. They measure outcomes instead of velocity. They invest in the architectural work the CTO has been asking for, even when it does not produce visible features in the next sprint.
The result is that features ship complete instead of accumulating as half finished work. The engineering organization becomes a source of competitive advantage instead of a bottleneck that limits growth. The backlog shrinks not because the team works harder, but because the system stops generating waste.
The companies that do not figure it out face a different trajectory. Their backlogs grow until they cannot deliver anything meaningful. Their best engineers leave for organizations that are not dysfunctional. Their customers defect to competitors who actually ship. The technical debt compounds until the codebase becomes unmaintainable.
Every CTO I talk to on the podcast recognizes this pattern. Most of them are living inside it right now. The question is not whether they see the problem. It is whether they have the organizational authority and the structural framework to solve it before the backlog becomes the business.
____________________________________
Steve Taplin is the CEO of Sonatafy Technology, host of the Software Leaders Uncensored podcast (180+ episodes), and author of Fail Hard, Win Big. He writes about the decisions technology leaders actually face at thetechdilemma.com.
