Abstract
Digital transformation is important for organizations to stay competitive. Yet, incumbents face challenges from technical debt accrued from legacy information systems. The big bang approach—aiming for a rapid replacement of legacy systems—often falls short. This failure largely results from treating technical debt as a purely technical issue, while overlooking its managerial implications. What is needed is a gradual approach that redefines IT’s role from debt custodian to strategic enabler, focusing on generating business value rather than solely eliminating technical debt. This article offers four recommendations for managers to handle technical debt amid digital transformation.
Keywords
The current strategy discourse has devoted significant space to digital transformation, a process of strategic renewal through the novel use of digital technology to transform business. 1 Digital transformation is important for many organizations across industries, including ones traditionally not thought to be digital-intensive. Successful digital transformation brings greater operational efficiency, enhances customer experience, and increases the ability to innovate. 2 Market intelligence firm IDC estimates that global spending on digital transformation will reach a record $2.8 trillion in 2025. 3 The majority of executives believe that digital transformation is the most critical growth driver that will require significant investments in the coming years. 4
Alongside the digital transformation trend, a less positive development is underway—the looming issue of technical debt. Technical debt, associated with legacy information systems, is an inherent challenge to successful digital transformation. 5 Technical debt is an accumulation of software maintenance obligations, originating from shortcuts and temporary solutions in the development process. 6 Information systems gradually accumulate technical debt as they are developed to adapt to the emerging needs of the organization. Maintenance of debt-ridden legacy systems can take the lion’s share of an IT budget by increasing the cost of development. 7 This creates a vicious cycle where CIOs cannot allocate significant resources to resolve technical debt, 8 exacerbating the problem over time. The cycle leads to reduced development effectiveness, which suffocates digital transformation efforts.
Managing technical debt requires a two-pronged approach where managers need to consider both the technical and social aspects of the problem. Resolving the technical debt by simply replacing legacy systems is complicated beyond the questions of technical know-how. Many legacy systems, for all their faults, tend to be reliable linchpins of core operations. Decommissioning of such systems can be extremely disruptive to an organization, even if they are to be replaced by supposedly superior and more cost-effective systems. This situation encourages an organizational climate where the adage “if it ain’t broke, don’t fix it” carries a lot of power. Consequently, one encounters inertia. There is an understanding that legacy systems need to be replaced to gain new capabilities, but the organization is entrenched in existing routines that encourage it to keep using these systems for as long as possible. 9
Thus, we argue that technical debt is as much of a strategic managerial issue as an engineering problem. Managers need to simultaneously combat the social and technical aspects that reinforce each other to both address technical debt and cultivate new digital options. However, this connection between the technical and social aspects of the problem is often lost in both practice and academic discourse. This article presents a balanced view that integrates both sides of the technical debt problem and shows how the combination of social change and new technology can help organizations leave the vicious cycle of technical debt-induced inertia and set themselves on the path to success. We illustrate this through a case study at the Swedish railway logistics company Green Cargo, an organization that wrestled with the challenges of technical debt (see Appendix for a brief summary of data collection).
The Two Sides of Technical Debt
Organizations engaged in technological change have always faced the dual challenge of managing both technical and social aspects. This includes both achieving a successful technical deployment of new systems and navigating the more complex issues of process adaptation and employee engagement. Technical debt can make the pursuit of digital transformation challenging. Technical debt increases the rigidity of IT architecture, decreases development efficiency, and adds further maintenance obligations, all of which hinder new digital transformation initiatives. 10 The challenge of managing technical debt is sociotechnical in nature. On the one hand, technical debt accumulates from the processes of IT development and maintenance. On the other hand, technical debt is socially rooted in insufficient organizational adaptation.
From the technical side, years of building digital capabilities leave organizations with sizable IT infrastructures to maintain. These infrastructures are rife with technical debt stemming from obsolete software and a lack of disciplined IT management. Technical debt can accrue through generating poorly designed code, failing to document changes made into systems, conducting excessive customization of commercial off-the-shelf systems, and creating technological gaps by integrating new systems into obsolete technical architecture. Owing to their age and evolutionary development logic, many legacy systems are ridden with technical debt. 11 If technical debt is not resolved, it will eventually generate “interest” in the form of increased efforts and costs consumed by system maintenance, for instance, additional time spent testing software updates due to complex dependencies between different systems. Technical debt can be managed through rewriting and optimizing code, producing documentation on system design, and simplifying the system architecture. 12 The latter can be achieved by decommissioning or replacing legacy systems. Unfortunately, technical debt that has accrued in the past hinders such attempts as dependencies are hard to detect and are costly and risky to remove or modify. 13
From the social side, technical debt is amplified by people’s entrenched perceptions and behaviors related to legacy systems. Legacy systems usage is routine; they are well-integrated and supported within the organizational framework, and employees have become proficient in their use and have aligned their work processes to these systems. This entrenched familiarity is not a problem as long as the legacy work processes remain relevant and serve the purpose. However, it poses a significant challenge when transitioning to new systems that may not align as closely with existing workflows and employee expertise. 14 This is a typical situation in organizations striving to revamp the incumbent organizational identity and value proposition through digital transformation. The resistance within the organization can manifest into managers’ reluctance to embrace change, concerns over disrupting business continuity, or subtle resistance from end-users. Such resistance typically calls for significant change in management efforts.
Unfortunately, total elimination of technical debt is rarely feasible, because there is a tradeoff between technical debt and digital options. 15 Adding new digital options, such as new system functionalities, necessarily introduces ongoing maintenance responsibilities that contribute to technical debt. On the other hand, relinquishing options usually lowers debt as there is less functionality that needs maintenance. Failure to manage this tradeoff can lead to situations where the burden of technical debt from an organization’s stock of digital options is so heavy that it paralyzes the organization. 16 This is the result of counterproductive but seemingly safe managerial decisions that incur further technical debt while limiting digital options. Technical debt is often invisible to business managers, 17 who tend to be more focused on pursuing digital options and less incentivized to spend resources on managing something they cannot see. For instance, managers might choose to customize new systems to fit outdated operations. 18 Thus, organizations may find themselves trapped in a cycle where achieving genuine digital transformation remains an elusive goal.
Addressing technical debt demands coordinated efforts, which is particularly challenging in large organizations with entrenched systems and practices. Based on the case of Green Cargo, we demonstrate how organizations can navigate a severe technical debt problem to clear the way for a much-needed digital transformation.
Case: Green Cargo
Green Cargo, a Swedish state-owned railway logistics company headquartered in Solna, experienced an impasse with technical debt but managed to prevail. The company was formed in 2001 as a spin-off from the Swedish State Railways (SJ). Green Cargo holds about 60% of the Swedish rail freight market. The company employed around 1,800 people and had a turnover of $377 million by the start of 2023. The company positions itself as a more sustainable alternative to truck-based cargo transportation. Green Cargo runs a large and complex operation that involves more than 400 daily train departures that reach Sweden, Norway, and Denmark. 19
A train logistics company requires a sophisticated and highly reliable IT infrastructure to run operations 24/7. A disruption in normal operations or a failure to coordinate not only leads to cascading delays that have ripple effects across the rail traffic of a whole country, but also multi-million-dollar financial losses for customers as well as accidents. Green Cargo had a state-of-the-art infrastructure dating back to the 1980s, capable of providing a highly reliable backbone to its operations. Mainframe systems served as a foundation, on top of which the company gradually deployed various applications and services, including, among others, bespoke industry-specific systems for train maintenance, traffic management, and order processing. This made the IT department at Green Cargo an important enabler of operations and business development.
Already by the mid-1990s, it was becoming clear that certain core systems were due for an upgrade. Providers of Green Cargo’s original software and hardware were ending their system support, and new out-of-the-box software was becoming incompatible with the existing systems. Despite the obvious concerns with system obsolescence, the existing systems were operating without incidents. The core requirements of business operations were fulfilled, and the existing infrastructure had proven to be highly reliable. Replacing these systems would have been associated with significant costs and would have likely decreased reliability in the short to medium term. It was also extremely difficult, if not impossible, to replace some industry-specific bespoke systems, as there were no alternatives on the market. Many of these systems were specifically created to work with Green Cargo’s systems and with other systems run by organizations associated with the Swedish rail network. Replacing the mainframe that provided the foundation of these bespoke systems meant recreating these systems from scratch. This created inertia. There was no immediate pressure to pay off the technical debt. As a result, no compelling business case was made, no big changes were initiated, and technical debt was allowed to accumulate interest.
This interest came due when Green Cargo implemented SAP software in the mid-2000s. It was the first major platform integration in many years, and it turned out to be surprisingly difficult. The legacy systems’ limitations became apparent and revealed that technical debt had become a strategic problem. Infrastructure debt in particular caused issues as some systems on the old mainframe lacked SAP-compatible interfaces. In response, Green Cargo’s developers devised complex integration solutions that contributed to architecture debt, making it difficult to change the system features without breaking some functionality. Moreover, the SAP system failed to significantly streamline Green Cargo’s internal processes. Limitations of legacy systems just carried over into the new systems, as the company discovered that SAP could not fully replace some old systems, leaving infrastructure debt unresolved.
Maintaining such a debt-infested systems portfolio started to soak up most of the IT budget, leaving little money for investments in business development. The negative experience with SAP implementation and decreasing resources for development reinforced the unwillingness to change—any attempts to develop the IT architecture seemed only to increase complexity without yielding much reward. The failure to resolve any past technical debt and the introduction of even further debt meant that the IT department kept busy with maintaining the reliability and resilience of the existing infrastructure. In other words, the department was caught up in paying interest on the growing debt.
The worsening situation sent Green Cargo’s IT department into a downward spiral consisting of benchmarking reports by external consultants, failed attempts to resolve the debt via expensive big bang system replacement projects, and outsourcing of more and more IT functions as internal capabilities diminished. The company was operating in a high-reliability environment that could not afford disruptions, which made its industry-specific legacy systems difficult to decommission. The outsourcing decisions ensured that there was a growing shortage of competencies needed for change. Reflecting on what he inherited upon arrival to the company, the CIO, Ingo Paas, identified the problem as a mismatch between the industry best practices promoted by external consultants and the reality at Green Cargo: [External consulting company] gave Green Cargo 150 PowerPoint slides, and they had all the data, but you cannot replace those systems in a company that has no competencies, no skills, no resources. And it’s not investing in the development of the company. You cannot stop for another five years to take care of an IT problem, that really does not help anyone.
Constant instability and staff turnover in the upper management and the IT department also led to faltering decision-making capacity. At times, people felt they did not have a mandate or political capital to make bigger decisions. At other times, big decisions were delegated to the external management consultants who proposed inviable paths of action.
The negative dynamic eventually resulted in the gutting of the IT department. Most of the development tasks were outsourced, and the IT department was reduced to a maintenance function. Instead of developing digital options and resolving technical debt, the IT department’s main function was to pay off the debt’s interest. This exacerbated requirements debt, as the business moved on and its needs evolved, the IT systems were standing still. Over time, the rest of the organization started to perceive the IT department as a burden to progress, as it was incapable of offering solutions to emerging business needs. It became increasingly difficult to attract new talent when existing staff retired or switched jobs, leading to the accumulation of competence debt.
Outsourcing partners who took over the core IT tasks were struggling to deliver any significant improvements to existing legacy systems. Documentation debt contributed to this as knowledge about the old systems had gone undocumented over the years, being mostly confined to individuals who worked on those systems, most of whom were no longer with the company. Documentation that did exist in the form of code comments and manuals was written in Swedish, which made it impossible for outsourced developers to understand, as they did not speak any Swedish.
The situation represented an existential threat to the company. Green Cargo was bleeding money and gradually losing its market share. Truck-based cargo transportation providers offered more modern digital services for managing and tracking cargo. Green Cargo’s ordering process still relied on sending an attached order form by email. While the government was helping to keep the company afloat financially, there were signs that this could end if the company did not show a clear path to profitability. A full-blown digital transformation represented a potential way out of this plight, but such effort seemed to be blocked by the accumulated technical debt. There was now plenty of pressure to change, but the organization was short of options.
New Management Turns to Technical Debt
In January 2019, Green Cargo’s board appointed a new executive team to address the company’s problems. The new leadership developed a strategy. The objective was to become a profitable, self-sufficient company, and the safest and most punctual cargo train operator in the world. To achieve this objective, Green Cargo required digital transformation—and digital transformation required resolving technical debt. However, new CIO Paas realized that focusing on legacy systems replacement would likely fail yet again. Green Cargo simply did not have enough resources, time, or know-how for such a major undertaking. Then there was the organizational inertia that had grown deep roots by that time.
The IT department required a major change of its own, not just in terms of technological infrastructure, but in terms of its strategic role within Green Cargo. Paas believed he needed to change how the IT department was seen within Green Cargo. The IT department needed to be about business, not about support and maintenance. The IT department was to become a digital one, which required both a social and technical makeover. First, the IT department needed to find a practical way to encapsulate the existing technical debt and work around it to create new digital options. Second, over time, the IT department needed to be able to work on gradually resolving the encapsulated debt, without undermining the newly acquired digital options. This plan involved the gradual replacement of legacy systems in a way that would complement and strengthen new digital capabilities. In other words, Green Cargo would start building a new house on an old and shaky foundation, upgrading the foundation as the house was built.
Technical Change
Green Cargo needed to get out of the technological cul-de-sac. The IT department could not fix the technical debt quickly, but it needed some tools to improve work and add flexibility to its technology. Three core decisions were made to address this dilemma: creating agile digital foundations; bringing IT control in-house; and adopting principles of composable architecture.
Agile Digital Foundations
The IT department required modern digital platforms to develop solutions for the business. These tools needed to be fast and easy to develop and deploy. First, the department implemented Microsoft Azure, a cloud-based platform that offers a range of capabilities for application deployment and database services. 20 The idea behind adopting Azure was to create a digital middle layer between legacy systems and business applications. Green Cargo was able to connect Azure to its legacy systems to extract the necessary data and develop applications that offered up-to-date features and capabilities. These applications could also perform well, as they run on Azure’s modern infrastructure, rather than on Green Cargo’s own outdated systems. The mainframe still presented a bottleneck for certain applications, but it was a marked improvement over the status quo.
Green Cargo’s business units had an urgent need for new applications. To satisfy this need, the IT department adopted the OutSystems low-code platform.
21
Such platforms allow software development primarily via graphical user interfaces, enabling more people to engage in development. The low-code platform offered the department an environment for creating applications with minimal coding requirements, helping the IT department close the gap between the demand and its resources. These applications were easy to integrate with the Azure platform. The Head of Architecture explained the rationale behind adopting the low-code platform: When I started, Green Cargo had an IT organization that was basically service owners and maybe a handful of specialists. We didn’t have the technical know-how. And given this fact, we didn’t really think that just bringing in, you know .NET developers or C# or any other language for that matter, would do the trick. We needed some help. So, that was key in the decision [to adopt the low-code platform]. And of course, speed.
In-House IT Control
Green Cargo started insourcing its IT systems development. The biggest of them was mainframe development, which was provided by an outsourced provider located abroad. While the provider was able to deliver maintenance updates, it could not cope with the development that was required for Green Cargo to address its debt. Such a development required a rapid pace and intimate knowledge of the mainframe that was only available inside Green Cargo. Even if this knowledge was not exhaustive, Green Cargo balanced it out by hiring experts with relevant local knowledge. This insourcing decision paid off promptly as the IT department was able to drastically accelerate system development cycles to address emerging needs. CIO Paas: We are building things in the mainframe, we are taking control, we are reducing code, we are looking into the business logic, and we are getting things right. And suddenly, we are controlling the mainframe. [Service Owner] was quite happy when he saw that we moved from four releases a year to, in the “worst” case, sixteen a week. In the mainframe, when you go from four a year to sixteen a week, it’s quite a big change.
Composable Architecture
Green Cargo started building a composable IT architecture. 22 The existing debt-ridden architecture was monolithic, as was a common practice at the time these systems were implemented. In a monolithic architecture, all components are unified and interdependent, making it hard to change one component without changing the whole system. A composable architecture, on the other hand, consists of replaceable modules that can be configured and reconfigured to fit the needs of an organization. Composable architecture was expected to help Green Cargo reduce the new digital platforms’ dependence on the old legacy systems, possibly enabling the company to avoid another technical debt crisis down the road. As the IT department started to clear out the technical debt and gradually replace the legacy systems, this process needed to avoid breaking new applications that might have depended on these systems. The IT department also wanted the flexibility to experiment and to replace and redevelop applications for business as requirements changed, and the department acquired more technical know-how.
As one IT Architect pointed out, composability should enable the company to gradually update its IT architecture without needing to negotiate big bang transformations in the future to resolve massive technical debt: Okay, we have some super modern things right now, but in two years they aren’t. Therefore, it’s really important that we build it modular and scalable so that we can work with the technical debt along the way, all the time. Otherwise, you will end up with the same debt in 20 years, right?
Social Change
Action was also needed in social structures. Paas needed to break the inertia that had taken root over years of accumulating technical debt and weakening IT capabilities. Otherwise, the company would not be able to capitalize on the opportunity to create digital options carved by technical changes. Paas initiated three key changes to tackle the issue: reprioritize technical debt, reinvigorate the culture of the IT department, and trigger structural evolution at the IT department.
Technical Debt Reprioritized
Technical debt had been the top issue to resolve on the IT department’s agenda for a very long time. Yet, these efforts only resulted in repeated failure. The IT department saw technical debt as an IT problem that needed to be resolved by paying off the debt. Given the scale of the problem, the only decisive way to resolve the debt seemed to be replacing legacy systems. The IT department devoted all its remaining resources to maintaining and working around the debt-ridden systems, deprioritizing new development.
When Paas arrived at Green Cargo, he inquired about successfully completed projects in the IT department. He found there were barely any in the recent decade. Undoubtedly, technical debt presented significant technological limitations. Yet, the way the IT department approached the problem and potential solutions limited Green Cargo’s capabilities even further. Creating something new was simply not a possibility.
Paas wanted to shift the focus to generating digital options, and this required a major rethinking of priorities. He wanted to show the IT department—and the organization—that the core of the problem was the inability to deliver value through IT, not the technical debt or the size of it. The strategic job of the IT department was to enable the success of Green Cargo. Replacing legacy systems should have taken priority only when they stood in the way of addressing specific business development issues. Technical debt needed to be addressed, but not at the expense of everything else. Such a framing targeted a widespread cognitive entrenchment within the organization in which the IT department was seen as a technical support function whose only job was to keep negative consequences of technical debt at bay, instead of being a key strategic capability. Yet, there had been no meaningful progress in paying off technical debt, which had forestalled business development for years.
To trigger the change, Paas needed a clear objective and a simple-to-understand strategy for the IT department. The new strategy stated that the technical aspects of technical debt were an internal operational issue for the IT department, but the strategic task of the department was business development. Therefore, Green Cargo should see resources directed to IT as an investment, not as an expense to prop up legacy systems.
Change of priorities opened the door for the IT department to focus on business development and make an impact. While the change was approved, there was internal resistance in the process stemming from inertia. Some voices within the IT department pushed against changing priorities and taking responsibility for business development, advocating instead for continued focus on technical debt and replacing legacy systems with off-the-shelf services provided by outsourcing suppliers. These disagreements resulted in employees departing the IT department.
Cultural Reinvigoration of IT
The new change narrative had to be backed up by action. One piece of the puzzle was technical tools that would enable the IT department to create value, despite the hurdle of technical debt. However, the department also needed a strong signal of support and a model for action. The new leadership gave IT the mandate and responsibility to act autonomously while promising financial and political support. The CIO communicated to IT staff that they were instrumental to the new strategy’s success and could act based on what they believed was necessary to realize the strategy, without worrying about perceived or real bureaucratic barriers within the organization.
Encouragement inside the IT department was paired with outreach to other parts of Green Cargo to bring its business problems to IT. The prevailing perception of the IT department was that it was a nay-sayer, incapable of taking on projects that helped solve specific problems within business functions. Moreover, some units no longer acknowledged that their problems could be resolved through IT. This led to business units not interacting with the IT department. Now, management actively pushed each unit to work closely with the IT department and bring forth business problems. However, enthusiasm levels varied across business units, as many still did not perceive the IT department as a partner that could create value. As a result, IT had to start with the most enthusiastic units such as customer service, the director of which was proactive from the start.
And here I see the difference. I see that my department [has] just come much further because we’re willing to change how we work to suit IT and how IT wants to work going forward. We’re thinking in terms of: “This is what we want to do, IT, this is the plan, this is the roadmap, now we need to get some resources to go to the room and start battling it out.”
Paas’s goal was to get the business to identify areas where the IT department could create the most value. The IT department made sure that such requests were answered, working with the willing units to design new solutions using new tools. A couple of successful projects had a snowball effect wherein more units began to get involved, and more ideas started to flow in. This created a positive problem where the IT department had to start prioritizing and selecting only the best and most impactful projects that generated relatively low new debt. Units such as customer service, fleet management, and accounting became proactive in offering project suggestions. An IT Integration Architect said having to prioritize requests to the reinvigorated IT department was met with a “can do” attitude: People are starting to see the capabilities that can be grasped. “Oh, we can do that? Then I want to do that!” A couple of projects showed what could be done. I think, now the issue is us not having resources to implement all these ideas that are bouncing around, I would say.
Structural Evolution
The third piece of the puzzle was increasing investment in IT to provide resources to create digital options and navigate technical debt problems. Increased control over IT infrastructure was coupled with translating operational expenses to capital expenses. Green Cargo did not necessarily have extra money to pour into IT, but the new management identified that funds could be obtained through insourcing or changing existing outsourcing contracts to ones with better terms.
The new investments allowed for hiring more skilled people, which, in turn, made it possible to have a new department structure fit for the new reality. The old IT department included units for Applications, Infrastructure, Support, and Project Management Office. In the new structure, Green Cargo abolished the Support unit and instead introduced two new units: Operations and Development, both named to signal the new direction of the department. Since the IT department was severely understaffed before, a lot of structural changes came together with new hiring rounds, meaning there was less resistance than there would have been to a complete IT department overhaul.
Now the department was able to dedicate specific teams for creating digital options and others to focus on clearing technical debt. The hiring process became more strategic. The organization started to reflect on its own needs and think about recruitment in the long term, said an HR Business Partner: We must become more efficient, we must have more control, etc. But now we are trying to get insight into digital transformation. “What does it mean for me and my department?” It’s starting to crystallize a bit more now. . . . When I get involved in recruitment now, we ask: “What kind of IT skills do we have today and what kind of IT skills do we need tomorrow?” So that you think perhaps a little more long-term.
Outcomes of the Change
IT operations underwent a noticeable change three years after the company’s direction changed under new management. The change could be seen clearly in key strategic indicators for the IT department (see Table 1). Reprioritization of technical debt and the greater focus on developments resulted in a sustained and gradual funding increase during the years 2019-2022. This increase came from moving outsourced functions in-house (i.e., procurement expenditure was redirected to the IT development budget), and additional funds were reallocated to the IT department from the company budget. As the IT department showed signs of activity, the leadership team became more willing to find extra funding. IT capital expenditure (CAPEX) grew by 470% (from $0.76M to $4.4M), while IT operating expenses (OPEX) grew by 41% (from $18.5M to $26.1M). During the same period, Green Cargo increased its IT spending from 4.3% to 5.7% of annual revenues, clearly showing a shift in strategy.
Key Strategic Indicators for the Green Cargo IT Department.
Notably, investments in development grew disproportionately (from 10% to 39%), a clear indicator of the changing approach to IT. This was accompanied by Green Cargo regaining control over its systems. The growth of the investment rate had a drastic effect on development indicators. There was a dramatic increase in development initiatives and new application releases going from 13 to 1,076, and from 0 to 25, respectively. This helped Green Cargo acquire a range of new digital options and bring improvements to the operations of various units.
Despite the growing focus on new development, the IT department was able to bring more tangible improvements to legacy systems, thus reducing technical debt. The IT department went from four mainframe update releases per year in 2019 to more than 200 a year in 2022. These improvements in legacy systems led to greater integration possibilities between new and old systems. Also, this allowed Green Cargo to start migrating data and functionality to modern systems and commence the gradual phasing out of SAP. Thus, Green Cargo upgraded the shaky foundations under the new structure. All this was achieved by the combination of greater control over the legacy systems, evolved governance structures, and composable architecture.
The expansion of new development initiatives translated into tangible digital options, some of which Green Cargo was able to realize promptly. The new Azure middle layer enabled IT to create new, more user-friendly, and functional applications for various units at Green Cargo. These applications utilized the data pulled from legacy systems, but they were built on new technical foundations. For example, in the accounting function, IT delivered a modern application with advanced tools for budgeting and financial analytics that enabled real-time access to the same financial data across different units. This improved the efficiency of the budgeting process, according to the Financial Controller: When I joined, we did budgeting in Excel, it was terrible. Now, we have implemented a new tool, which has helped us a lot. Now we have this tool that everyone has access to, they can go in there whenever they want and analyze their numbers and ask questions to controllers. And we have a dialogue, and we see errors much faster, and we’re more proactive, we have a better understanding of our cost structure.
Combining these newfound development capabilities with a low-code platform enabled the IT department to develop new mobile applications for its workers in the field. Such development is time- and cost-efficient, as developers can create and deploy applications with minimal coding effort. For instance, the IT department was able to deliver a mobile application to its technicians to document train inspections, something that was done with pen and paper before. While low-code applications were not appropriate for applications with a larger scope, the IT department was now able to respond to specific local business problems that made a favorable impact on efficiency and employee well-being.
Green Cargo also applied the principle of composable architecture to all new developments. The main goal was to make sure that each application could work with others across the enterprise, while also being a separate unit that could be unplugged without major impacts. This approach should help Green Cargo avoid a similar technical debt deadlock that emerged from monolithic legacy systems. It also gave Green Cargo options to experiment with various digital artifacts without impacting the whole IT architecture, making the organization more agile.
The Interplay of Social and Technical
The case of Green Cargo demonstrates how organizations can overcome technical debt entrenchment on the path to digital transformation. The case reveals that while resolving debt may not always be feasible, managers can navigate around it in a way that yields digital options while keeping further debt accumulation in check. Such navigation requires careful management of debt’s technical and social roots. However, understanding how Green Cargo succeeded requires going beyond the simple social vs. technical dichotomy outlined earlier. The change was inherently sociotechnical—its social elements intertwined tightly with the technical ones in that neither alone could have enabled deployment of digital options and reduction of technical debt.
Sociotechnical Adaptation of the Design Moves Framework 23
A design moves analysis is inherently technical in nature in that it tracks the effects of modifying the organization’s technological designs (e.g., implementing new systems or customizing standard systems) on its technical debt and digital option value. We augment this analysis by considering the interactions between (technical) design moves and (social) organizational changes, demonstrating how each one’s success depended on the other.
Green Cargo started its journey from a vulnerable state with high technical debt and few digital options. First, to navigate technical debt, Green Cargo had to understand it. The organization realized the gravity of the problem through a difficult experience of multiple failed system replacement projects that had increased the complexity of its IT architecture to the point that it posed a direct threat to the continuity of business operations. The IT department’s ability to manage technical debt and digital options had been severely constrained by the organization’s centralized IT governance model, 24 which leveraged centrally managed shared services with most of IT development outsourced. In this environment, any development initiatives came from the top down, allowing little flexibility. The new leadership set out to change this model, and it started by focusing on the technical and social roots of the technical-debt problem rather than stubbornly trying to resolve all debt at once. We describe this sociotechnical change through four design moves tracing Green Cargo’s journey from a high-debt/low-options position to a relatively low-debt/high-option position (see Figure 1).
Move 1—Adopting Agile Digital Platforms: Green Cargo implemented agile digital platforms, which inevitably created more technical debt in the form of additional IT maintenance obligations. These platforms, however, provided Green Cargo an avenue for developing new solutions, reflecting a substantial increase in its stock of digital options. This technical change was made possible by Green Cargo’s decision to reprioritize technical debt (social change), as its new strategy set aside the goal of resolving technical debt for the moment and focused on creating new digital platforms instead. The changes are interconnected. Without gaining the organizational buy-in to reprioritize debt, the idea of introducing new platforms would have been discarded immediately as an unaffordable and irresponsible increase of debt. At the same time, the idea of reprioritization would not have gotten traction if the leadership had not tied it to tangible short-term benefits. Such benefits manifested as business value delivered by the new digital platforms’ technical capabilities. For the organization, the change meant moving out of its vulnerable state into a more option-rich but still debt-constrained state.
Move 2—Reclaiming In-House Development: Green Cargo insourced its mainframe development. This resolved some technical debt as it brought system development back into the hands of the organization, allowing visibility to the mainframe’s technical design that had been previously obscured by the lack of internal talent and missing system documentation. However, for the insourcing (technical change) to succeed, the organization required resources to hire the necessary expertise, and the department needed to be restructured to use these resources effectively (social change). This was achieved through the structural evolution of the IT department wherein savings from the discontinued or revised outsourcing contracts were funneled into boosting the department’s technical capability. The IT department’s renewed capability created the technical foundations for its cultural reinvigoration, as it enabled them to make fast changes to the mainframe in response to development needs. Again, social and technical action are intertwined. Before the change, outsourcing was seen as a cost-effective way to access any required mainframe-development capabilities. Therefore, leadership needed to simultaneously show the technical superiority of in-house development and the IT department’s ability to reinvent and restructure itself as an effective and efficient organizational unit capable of delivering better service at a lower cost. This approach stood in stark contrast with the IT department’s previous standing at Green Cargo.
Move 3—Developing Value-Generating Solutions: Green Cargo started to develop new solutions for various business purposes, unlocking additional digital options. This was a result of the coordinated sociotechnical change. Technically, this was feasible thanks to the composable architecture of the new digital platforms, which helped maintain development agility (Move 1) while keeping the inevitable increase in technical debt under control. From the social standpoint, the demand for these solutions was facilitated by the cultural reinvigoration of the IT department, which elevated it from a mere maintenance function to a driver of business development. An organization-wide cultural change made the IT department the epicenter of solving the organization’s business problems, backing up the department’s mandate to focus on digital options. Without this cultural shift and management’s push to break the social barriers, the IT department may have remained a technology-focused outcast to the rest of the organization, albeit with better tools. Instead, the IT department leveraged the enthusiastic units within Green Cargo to showcase its new capabilities to deliver solutions to real business problems. Having more responsibility and agency around Green Cargo’s core business, the IT department could now exercise discretion regarding when and how to accumulate technical debt. Now, the department could strategically evaluate the impact of any newly proposed solutions on digital options and technical debt and make decisions accordingly. The successes created a virtuous cycle where the IT department gained more confidence in its ability to create value, and other departments became incentivized to bring their problems to the IT department, further reducing the social mechanisms that had earlier contributed to debt accrual and undermined the department’s ability to create impact. This cycle, in turn, strengthened the technical capabilities of the department as it could continue developing more solutions.
Move 4—Gradual Phase-Out of Legacy Systems: Since a big bang approach to digital transformation was not feasible, Green Cargo found a more evolutionary way of controlled disassembly and transition. With the fourth move, Green Cargo decommissioned legacy solutions that had become redundant after the deployment of new ones. While this reduced options by forgoing some legacy functionality (people could no longer choose to do these things in “the old way”), it resolved much more technical debt than what developing the new solutions had accrued. The possibility of pursuing this move was a result of Green Cargo’s numerous sociotechnical changes. From the social perspective, the organization presented technical debt in a new light, the structural evolution of the department provided them with the funds and capacity to maneuver, and the department’s culture became more proactive and confident. With this foundation, the department could direct the newly acquired technical capabilities to methodically work on phasing out legacy systems that seemed irreplaceable before. In-house IT control and the composable architecture supported doing such a piece-by-piece system replacement effectively and safely. In many cases, the new modules enabled Green Cargo to decommission obsolete legacy processes and functionalities that fed into old ways of working.
These design moves helped Green Cargo drag itself out of the debt-constrained state toward agility. A crucial lubricant for the moves was the significant social change that took place in the organization, ultimately steering Green Cargo away from its centralized IT governance model toward a decentralized model that allowed the IT department to take initiative on development rather than waiting for upper management to push action from the top down.
Navigating interconnected technical and social aspects to resolve technical debt and create options.
Recommendations for Managers
The story of Green Cargo showcases an approach to responding to the challenge of significant technical debt—a strategic problem faced by many managers today. Based on our research, we offer four recommendations to help managers navigate these challenges. While our recommendations are centered around specific actions for managers, we want to re-emphasize the key takeaway from the previous section on the interplay of social and technical. Our main message is that the severe technical debt cannot be resolved through technical means alone. Social and technical changes are tightly interconnected, and they reinforce each other. Managers should not consider these changes as a linear process or a precise roadmap, but as recursive dynamics that need to be managed simultaneously.
Understand the Debt
There are two important aspects of the technical debt problem that managers need to understand to navigate successfully. First, the case of Green Cargo reveals the dangers of out-of-control debt accumulation. Organizations should implement systematic debt monitoring through concrete metrics such as system maintenance costs, development cycle times, and incident rates. 25 IT departments should regularly review technical debt, mapping legacy systems’ interdependencies. Development practices should also include technical debt assessment for new projects, evaluating both immediate and long-term maintenance implications.
Second, while the above is true, it is impossible to pay off technical debt definitively, and thus being debt-free should not be the goal. Managers should recognize that technical debt is not necessarily a problem in itself; it becomes such only once it begins to constrain the organization’s ability to transform and generate value. Therefore, organizations should cultivate the practice of evaluating the impact of the debt on business capabilities. Debt is a bigger problem that goes beyond the confines of the technical dimension. As such, narrowly focusing on paying off technical debt is unlikely to solve the core business problems that allowed the debt to become a problem in the first place.
Reframe the Problem of Technical Debt
Once managers understand the extent and origins of technical debt, they should reframe the problem by bringing the business needs back to the core and moving technical aspects to the background. As Green Cargo discovered, the problem was not the existence of the debt but rather what it meant for its ability to create digital options and develop business. This requires establishing close collaboration between IT and business units, establishing cross-functional teams that discuss strategic initiatives and how they may be impacted by barriers created by technical debt, as well as creating conditions for removing these barriers and cultivating new digital options. These collaborations should help to determine how specific legacy systems are enabling or constraining new business capabilities and help to prioritize debt reduction efforts according to strategic priorities.
However, managers cannot shift the focus of the entire organization single-handedly. This reframing needs to be accompanied by a change of culture and mentality around the technical debt. Green Cargo was stuck in the status quo not only because of technical limitations caused by the debt but also because of social implications on the IT department and how the rest of the organization viewed IT. Therefore, managers need to create concrete incentive structures that reward prioritizing value creation and collaboration between IT and business units. For instance, organizations could include relevant objectives on performance evaluations for both IT and business unit leaders.
Encapsulate the Debt and Bring IT to the Core of the Business
Once the groundwork is done, the debt should be encapsulated. This means breaking down the traditional silos where the IT department’s role is restricted to being the custodian of technical debt. By equipping the IT department with the ability to develop business solutions across the organization, Green Cargo was able to create a social interface for managing technical debt, isolating the technical complexity of the debt from options creation and digital transformation. Organizations should reorganize the IT department to include innovation—or development—focused units that prioritize generating new capabilities, separate from legacy system maintenance teams. IT departments could also reshape product owner roles to push employees to spend more time embedded in business units to better understand operational needs and opportunities.
The leadership should empower the unit responsible for technical debt (e.g., the IT department) by providing both resources and a mandate. This would mean establishing clear decision-making authority for the IT department regarding technical architecture. It would also be wise to provide extra resources that would allow the department to take alternative actions, rather than be focused exclusively on the immediate short-term challenges. This would allow the IT department to own the complexity of technical debt and open the space for strategic conversations. As IT takes a greater role in creating business value, business units should become more aware of their role in debt management (social aspects). This will enable the possibility of developing digital options that are normally avoided in high-debt contexts due to the lack of resources and fear of generating even more technical debt. 26
Embrace Composability
Our case suggests that the deep entrenchment of out-of-control technical debt could make the often-recommended big bang approach to digital transformation unfeasible. Instead, leadership should implement a staged approach to composable architecture, starting by working with supportive business units for projects that can bring quick wins and demonstrate the value of modular systems and composable architecture at large. Leveraging these successes, the IT department should share early wins and build momentum for engaging more units.
Composable architecture can provide a lifeline to organizations riddled with technical debt, enabling the creation of value-generating artifacts around legacy systems. It offers the benefits of rapid experimentation, stepwise upgrades of the IT architecture, and confinement of the debt to specific modules. Still, organizations should create clear guidelines and establish governance frameworks that ensure new systems adhere to modular design principles. Combined with organizational changes necessary to combat technical debt, modular technologies can be the key to revitalizing the generative digital capabilities of the organization while maintaining operational stability and gradually modernizing legacy systems.
Footnotes
Appendix
Notes
Author Biographies
Aleksandre Asatiani is an Associate Professor of Information Systems at the University of Gothenburg (
Jacob Torell is a Research Coordinator at the Department of Applied IT at the University of Gothenburg (
Tapani Rinta-Kahila is a Senior Research Fellow at the University of Queensland School of Business (
Johan Magnusson is a Professor of Information Systems and Director of the Swedish Center for Digital Innovation at the University of Gothenburg (