Helping business leaders and technologists to speak the same language is a key purpose of Project to Product and the goal of the Flow Framework™. After all, both IT leaders and business executives share the same objective; to bring more value to the internal and external customers that we serve. Given the massive investment that organizations are making in software, we need a common understanding of the key concepts that define whether software platforms will succeed or fail. In my experience, one of the concepts that has the least shared understanding is one of the most fundamental to software delivery, and that is the concept of tech debt.
Developers understand tech debt because they make daily decisions that require them to continually strike a balance between taking multiple shortcuts to get a feature completed, or investing time in generalizing the concepts of that feature to make features of that sort easier to build in the future. Due to customer pull for features, the shortcuts often win, and tech debt builds up. The challenge is that the pressure from the customer and the business rarely prioritizes tech debt reduction. Some forward-looking tech companies apply coarse principles, such as assigning 20 percent of work from each release to tech debt reduction. But nobody seems quite sure whether that number is what will deliver the most customer value at the end of the day.
Frameworks such as SAFe try to elevate the concept of tech debt through Refactor story types to ensure that these get first class visibility on backlog prioritization. But what I learned through the research that led up to Project to Product is that not even that is enough. For companies to avoid the fate of the Nokia story told in the book, the concept of tech debt needs to be elevated right to the top level of the business and the executive team. Without the understanding of tech debt in strategic planning, the executive team cannot direct and protect the company through the Age of Software. That was the motivation of making Debt items a first-class part of the Flow Framework™.
We need to fill this gap. A CEO should care, or at least be shown why they should care. Whether the boardroom likes it or not, tech debt can be just as lethal to a company’s success as financial debt and should be assessed and treated accordingly. In my article How to budget for your company’s technical debt, I explain how technical debt impacts the business, how we can make it visible to improve the flow of business value across the software delivery process, and why we should budget for it to achieve the business and customer outcomes that we seek.
To learn more, grab yourself a copy of Project to Product (available in print, digital and audio).
Project to Product is available in print, digital and audio. Order a copy today by clicking on the front cover:
