This study doesn't show a $300B opportunity, it shows a $300B optics issue. What it highlights is that there's roughly a $300B gap between the recognized costs

This study doesn't show a $300B opportunity, it shows a $300B optics issue. What it highlights is that there's roughly a $300B gap between the recognized costs of technical projects and the fully burdened cost of technical projects. Every single business function suffers from process inefficiency, rework needs, upkeep/maintenance needs, incremental changes/adaptations over time, and quality differences between deliverables/execution from senior vs. junior staff. The only difference between those functions and IT is that: 1. IT (and developers in particular) are incredibly expensive resources. Even junior employees here can cost more than seasoned professionals in other departments. This amplifies the scrutiny it receives. 2. IT work tends to get "projectized" more than other business units. This puts a higher level of visibility into time usage, allowing more granular accounting of where people are spending time. 3. Developers (as opposed to most business users[1]) have more exposure to "the right way"[2] to do things. This allows a level of self-awareness of process debt that leads to dissatisfaction and grumbling whenever they have to do things that wouldn't have been required if the process debt hadn't existed. Which translates into telling management that they could have done more if they had done things "the right way"[2], which management then interprets as lost productivity. But doing things differently would have necessitated a different cost outlay and timeframe to the original project, so in reality it's just shifting costs back to the project itself (or diffusing it into operational support) rather than post-project maintenance costs. -- Process debt accumulates everywhere. Everyone knows it's harder to get things done in an enterprise company than a small, scrappy startup. That's not just because the technical systems are newer and unencumbered by legacy systems. It's because the entire business is newer and unencumbered by legacy processes, calcified skillsets and policies, or what "normal" is. You can assimilate best practices and newer approaches to things because there's no internal inertia yet on anything, which includes but is not exclusive to the technical components. You can shift around those $300B in costs, and it's mostly an optics issue. Mitigating technical debt isn't free, and has no silver bullet. The cost is just shifted to the front end instead of the back end, in the form of operational support resources, process changes, automation, and hiring better skilled employees. It could well have ancillary benefits in the form of more execution agility over time, but from a cost perspective that $300B is just going to shift elsewhere, not go away. Developers do themselves a disservice by derisively speaking about technical debt to managers, and pointing out that if they could have only done things differently, that technical debt wouldn't exist. It paints the perspective that the technical debt is the result of individual developers decisions/actions, rather than a symptom of operating within the existing operational and organizational processes. If your company runs projects with a high level of rework needs and maintenance afterward, that's the result of organizational issues beyond a single developer and should be viewed as an expected outcome that rolls up into the cost of executing projects in the existing environment. It's a separate conversation about whether to invest in process and operational improvements to reduce those types of project costs. [1] I've set up entire drip marketing programs for companies for ~$5k before, with minimal ongoing costs for maintaining it and passing through email platform costs. I've also seen instances where companies have paid $40-50k to have an agency create a single "thanks for signing up" email, and pay $40-50k to create and send a single quarterly newsletter email to less than 10k recipients. And they didn't consider that a waste, because after accounting for their accumulated internal process debt, a three month lead time and $40-50k in costs was a competitively bid rate to execute the work for them. [2] I put it in quotes because "the right way" is usually not, in fact, an objectively correct way to do thing. But rather an ideal best practice or a following-the-bandwagon approach, without any critical thought or evaluation on whether it truly makes sense to apply to their environment.