Stakeholder influence on technical debt management in the public sector: An embedded case study

Technical debt (TD) entails the shortcuts and unsuitable choices made during the development or maintenance of an IT system, which can result in negative consequences such as inefficiency and instability of the IT system. Digitalizing the government has led to the development of numerous IT systems which must be maintained to prevent decay, standstill, additional costs, and a decline in software quality. Previous studies on TD have primarily focused on the private sector, while TD in the public sector has largely been ignored. Therefore, this case study investigated TD management in relation to two IT systems in a Danish agency. Through participant observations and in-situ interviews we studied actual TD behavior, while stakeholder theory combined with a categorization of TD types and activities served as our theoretical lens. Thus, our study (1) identifies the stakeholders influencing an agency's TD management, (2) maps stakeholders' actions, and (3) identifies stake-holders' influence on TD. We found that TD extends beyond the influence of software developers and is also influenced by the behavior of several non-technical stakeholders, e.g., the European Parliament. We offer practical recommendations for TD management based on these findings.


Introduction
Technical debt (TD) was introduced as a concept by Cunningham (1992) to explain the impact of suboptimal solutions made during the development of IT systems to cut costs or time. TD can make it more time-consuming for software developers to perform maintenance and further develop an IT system. Furthermore, TD can affect an IT system's performance by making it slower or by causing breakdowns (Rios, de Mendonça Neto, & Spínola, 2018). Therefore, TD management (TDM) is essential to reduce TD's potential negative impact on IT systems' efficiency, stability, and costs (Alves et al., 2016;Ribeiro, de Freitas Farias, Mendonça, & Spínola, 2016).
We follow Rios et al.'s (2018) definition of TD: "The concept of Technical Debt (TD) contextualizes problems faced during software evolution considering the tasks that are not carried out adequately during software development" (p. 117). TD fulfills all the requirements of a theory (Gregor, 2006). The TD literature describes TD types and how it is visible (Rios et al., 2018), as well as explains and predicts why and how TD is created. Moreover, it briefly prescribes that if TD is repaid, the potential negative consequences will not occur. The concept of TDM is defined by Griffith, Taffahi, Izurieta, andClaudio (2014, p. 1016) as comprising "the actions of identification, assessment, and remediation of TD throughout a software system." TD is a relevant research topic for the digital government field because digital government research focuses on how the public sector delivers services to citizens and businesses further innovates and develops government services using emergent technologies (Lindgren, Madsen, Hofmann, & Melin, 2019;Lindgren, Melin, & Saebø, 2021). TD management is required to deliver digital services and ensure that the emergent technologies work as they build upon existing IT systems. Without proper TD management, government organizations cannot provide and develop digital services for citizens and businesses. TD is a structural barrier to digital government (Wilson & Mergel, 2022). Lack of TD management can be critical for digital government transformation (Eom & Lee, 2022;Omar, Weerakkody, & Daowd, 2020) and implementation of new technologies such as big data (Guenduez, Mettler, & Schedler, 2020), Internet of Things (Janssen & Helbig, 2018), AI and Machine Learning (Mikalef et al., 2021), and blockchain (Ølnes, Ubacht, & Janssen, 2017).
This rapid digitalization has resulted in increased TD in the public sector. For instance, a study by the Danish Ministry of Finance found that a third of societal or business-critical IT systems in the Danish government were in inadequate condition (Danish Ministry of Finance: Regeringens kasseeftersyn på it-området. Copenhagen, Denmark, 2017). Examples of TD from the report include out-of-date or non-existing documentation, lack of IT security, and the need to upgrade outdated software and hardware. Similarly, the The Swedish National Audit: Föråldrade it-system-Hinder för en effektiv digitalisering. Stockholm (2019) found that 70% of the IT systems in Sweden's government agencies were outdated. TD is thus an important topic for digital government research because it can prevent public organizations from benefiting from digitalization (Nielsen, Madsen, & Lungu, 2020).
One of the goals of Digital Government is to increase efficiency, which makes TD particularly relevant for Digital Government research because TD can hinder efficiency gains and increase costs (Eom & Lee, 2022;Omar et al., 2020;Panagiotopoulos, Klievink, & Cordella, 2019). Despite TD's relevance to the public sector, most TD studies have been conducted outside of the digital government field, with researchers from software engineering and information systems focusing instead on IT systems in the private sector (Nielsen et al., 2020). However, the theory of TD enables and encourages researchers to examine the processes surrounding IT systems rather than focusing on an isolated IT system (Berenguer et al., 2021;Nielsen & Skaarup, 2021).
Therefore, we conduct a case study in a Danish agency analyzing TD and TDM in relation to two IT systems. To capture the surrounding processes, we employ observation, in-situ interviews, and document analysis (Blomberg & Burrell, 2012;Brannan & Oultram, 2012;Kvale, 1997). We apply stakeholder theory (Freeman, 1984;Scholl, 2001) combined with TD (Rios et al., 2018) as a theoretical lens through which to interpret and analyze our case data. We chose this theoretical frame during our analysis because the case data was closely associated with the organizational values (Rose, Flak, & Saebø, 2018), stakeholder behavior, stakeholder stance (Freeman, 1984;Blair & Whitehead, 1988), TD types, and TDM activities of the agency in question (Rios et al., 2018). Our study is guided by the following research question: How do stakeholders influence technical debt and technical debt management in a public agency?
By combining ST and TD, we follow Janssen and Janowski's (2015) recommendation for digital government researchers to offer both theoretical contributions and practical recommendations. Our study offers insights into how stakeholders affect TD. (1) We employ research methods suitable for problem-solving and the public sector (section 4); (2) advance knowledge in the field (section 6.1); and (3) make recommendations for practitioners on how to prevent TD (section 6.2).
The remainder of the paper is organized as follows. First, we present related work on TD and identify the gaps that this paper addresses. Secondly, we introduce our theoretical lens. Third, we describe the case setting and the methodological approach. Fourth, we present our findings on how stakeholders influence TD and TDM. Fifth, we discuss the implications for research and practice. Finally, we present our conclusions, outline the limitations of the study, and offer suggestions for future work.

Related work
TD as a concept was introduced by Cunningham in 1992. He sought to communicate the consequences of TD to managers in the financial sector. Cunningham explained the effects of TD: "Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite" (Cunningham, 1992, p. 30). Left outstanding, TD may lead to inefficiency in maintaining and developing IT systems, decreased performance, and increased risk of breakdowns. Unmanaged, it can bring entire engineering organizations to a standstill as accumulated TD makes it challenging to develop and maintain IT. Therefore, organizations must manage their TD (Cunningham, 1992).
The TD literature is growing rapidly, and researchers have made significant contributions in identifying and measuring TD. However, several knowledge gaps remain with regard to the management of TD. Nielsen et al. (2020) conducted a systematic literature review of 49 primary TDM studies published between 2017 and 2020. They found that TDM studies tend to reinvent the wheel; previous TD studies are limited as they mostly confirm TD's negative effects on IT development and inventing tools and models that can measure specific types of TD (Nielsen et al., 2020). Nielsen et al. (2020) also identified a knowledge gap: researchers have studied TDM indirectly through interviews, surveys, code comments, and source code but have not observed the actual behavior surrounding TDM. Furthermore, previous TD research has primarily focused on the private sector, leaving TD in the public sector unexplored (Nielsen et al., 2020). Avgeriou, Ernst, Nord, and Kruchten (2016) argued that those in management are responsible for the decisions that incur TD in IT systems: what "the software technical-debt community has not discussed is that of technical debt crossing multiple [work] disciplines. In the sense, technical debt is incurred in one discipline, but it is burdened and has to be repaid in another discipline" (Avgeriou et al., 2016, p. 40). While managers may cause TD, it is the responsibility of developers to solve the problems it creates. Yli-Huumo, Maglyas, and Smolander (2016) used ST to identify TD stakeholder groups. They concluded that addressing TD requires that the developers first increase awareness of TD and then apply more advanced TDM techniques. Rios et al. (2018) observed a lack of applied theory in a tertiary literature review of TD research encompassing 185 primary and 13 secondary studies. They identified three research directions: TD identification, the concept of TD, and TDM. Moreover, they synthesized the literature into a TD landscape, mapping out TDM activities, strategies, tools, and 15 different TD types. These TD types identified by Rios et al. (2018) include the following: design debt, code debt, architecture debt, test debt, documentation debt, defect debt, infrastructure debt, requirement debt, people debt, build debt, process debt, automation test debt, usability debt, service debt, and versioning debt. The macro TDM activities were (1) those designed to prevent TD; (2) those designed to identify TD; (3) those designed to monitor TD during the evolution of a project/ IT system; and (4) those designed to pay TD promptly (i.e., eliminate it). We will apply and extend this categorization by Rios et al. (2018) in our analysis. Previous TD research has applied TD types and categorization to map TD types with TD causes, TD effects, and preventive and payment actions (Freire et al., 2020;Pérez et al., 2021;Ramač et al., 2022;. Klinger, Tarr, Wagstrom, and Williams (2011), meanwhile, conducted a study with IT architects and found that "the decision to acquire technical debt is not made by technical architects, but rather by nontechnical stakeholders who cause the project to acquire new technical debt or discover existing technical debt that wasn't previously visible" (p. 35). Klinger et al. (2011) also state that future studies should focus on TD stakeholders. Furthermore, stakeholders are important in digital government studies as they influence the IT development in the government, e.g., digital government implementation (Ashaye and Irani, 2019). To the best of our knowledge, previous research has not investigated stakeholders' influence on TD in the public sector.
To summarize this section, Table 1 displays the three identified knowledge gaps in the extant TD literature, their importance, and how we will address these gaps in our study. Freeman (1984) developed ST to increase company revenue in the private sector. He argued that organizational profits are higher when stakeholders are satisfied. An essential part of ST is the definition of a stakeholder: "A stakeholder in an organization is (by its definition) any group or individual who can affect or is affected by the achievement of the organization's objective" (p. 25). ST focuses on the firm's internal stakeholders (e.g., employees and managers) and external stakeholders (e.g., customers and suppliers). Freeman argued that "you must take your stakeholders into account in a systematic fashion" (p. 48)-identifying them, their actions, and their influence-to manage effectively. Stakeholders have different interests and goals that can be difficult to navigate when developing and maintaining IT systems. These competing priorities can lead to shortcuts, abandoned development, and similar problems that are likely to result in TD. Blair and Whitehead (1988) operationalized stakeholder theory for analytical purposes by distinguishing the stakeholders' stance (Scholl, Fidel, Liua, Paulsmeyer, & Unsworth, 2007) as displayed in Fig. 1. They developed a diagnostic typology of stakeholders' potential to either cooperate with or threaten the organization. The typology comprises four distinct stakeholder categories: (1) mixed-blessing (high cooperation and high threat), (2) supportive (high cooperation and low threat), (3) non-supportive (low cooperation and high threat), and (4) marginal (low cooperation and low threat) (Blair & Whitehead, 1988). Scholl (2001) introduced ST to the digital government field and identified how the theory could benefit "public-sector managerial decision-making" (Scholl, 2001, p. 745). Flak and Rose (2005) further explored the implications of applying ST in digital government studies. They highlighted an issue that results from transferring the theory from a private-to a public-sector context. Increasing profit is an important private-sector value, but does not apply in the public sector. Rose et al. (2018) contributed to the research on ST in digital government by identifying four values relevant to the public sector: professionalism, efficiency, service, and engagement. Although previous research had mapped stakeholder roles within digital government (Axelsson, Melin, & Lindgren, 2013;Reinwald & Kraemmergaard, 2012), Rose et al. (2018) recommended future studies to better define "the specific roles of various stakeholders" (p. 372).

Theoretical lens: Stakeholder Theory (ST)
ST has been used to study TD and TDM, but only in a private-sector context. Yli-Huumo et al. (2016) and Klinger et al. (2011) applied it in examining how a software team manages TD. They distinguished between technical and non-technical stakeholders and found that both these groups may influence TD. Yli-Huumo et al. (2016) contributed to the literature on TD by mapping stakeholders to specific TD activities.
We seek to build on this knowledge of TD by exploring stakeholders' influence on TD in a public-sector setting. To do this, we combine core concepts from ST with Rios et al.'s (2018) TDM activities in our analytical framework.

Method
Our study employed a qualitative and explorative approach. We conducted an embedded case study, which is suitable when the researcher seeks to explain how a social phenomenon works (Yin, 2018). An embedded case study is a case study that "may involve units of analysis at more than one level. This occurs when, within a single-case (the first level), attention is also given to a subunit or subunits (second level)" (p. 51). Specifically, we conducted an embedded case study with two subunits to explore TD on both an individual IT systems level and a holistic IT development level (Yin, 2018). The following section contains a description of the case setting, data collection, and data analysis.

Case description
Agency X is a mature IT organization, considered to be among the best government organizations in Denmark in terms of the development and operation of IT systems. The agency does not have its own developers. Instead, application development is carried out through a partnership between the agency and the software companies' developers placed on-site. Agency X also develops IT systems for other authorities. These authorities cover the costs, define the needs of the system, and are responsible for the underlying legislation, while Agency X sets the requirements for, develops, and maintains the IT system. In this way, these external systems become part of Agency X's IT landscape and use its back-end systems.
Internally developed IT systems can more easily be altered compared to off-the-shelf applications (Al-Ibraheem & Ruël, 2011). Hence,

Table 1
Gaps in the TD literature.

Gap
Why is it important? How do we address it?
(1) Lack of knowledge on non-technical stakeholders Klinger et al. (2011) find that non-technical stakeholders influence TD, but do not classify this group further.
We extend Klinger et al.'s (2011) study by identifying additional stakeholder groups, their actions, and the consequences on TD.
(2) Lack of TD research from the public sector While TD exists in the public sector, it has mostly been studied in the private sector. Findings and recommendations from the private sector may not be applicable in the public sector.
We explore TD in the public sector in order to identify TDM strategies suitable for this specific context.
(3) Lack of knowledge on actual TD behavior The existing knowledge on TD is based on interviews, experiments, and code analysis. Actual TD behavior may differ from what is stated in interviews.
We combine observations and in-situ interviews to gain insights into stakeholders' actual TD behavior (Blomberg & Burrell, 2012 stakeholders are more likely to influence TD on these IT systems. We applied critical sampling to identify the two IT systems where the stakeholders' influence was the most evident (Yin, 2018). We chose the IT systems that we refer to as TEXT and REPORT. TEXT serves as a content management system (CMS) for the other IT systems, while REPORT offers a platform where citizens can report specific activities; the casework is handled by other authorities. An application manager and external developers are assigned to each of the two systems.

Data collection
We wanted to explore how stakeholders influenced TD. The first author gathered empirical data on-site from August to December 2019. Conducting case studies using multiple sources of evidence ensures that the research is of a high quality (Yin, 2018). Previous studies on TD have not studied actual TD behavior (Nielsen et al., 2020). Therefore, we conducted on-site interviews, in-situ interviews, and participant observations, as displayed in Table 2.
We conducted 15 semi-structured interviews at Agency X. We applied a purposeful sampling and interviewed only the employees that were part of the daily management of the IT systems (Kvale, 1997). The interviews were framed around the processes that the employees used to collaborate with others in maintaining and managing the IT system. From the interviews, we gained insights into the employees' perceptions of and reflections on the maintenance processes. The two in-situ interviews were conducted with a user and a user representative of the IT systems (Blomberg & Burrell, 2012). The interviewees performed their routine tasks on the IT system while the interviewer asked them about their actions and reflections. This gave us insights into the challenges that IT systems pose to their users and the users' reactions to these challenges.
The participant observations were conducted by the first author, who was present at the organization three days a week for five months. Additionally, she attended three of the agency's quarterly meetings, during which the following months of IT development were coordinated. She had been acquainted with Agency X before data collection began and therefore was able to blend in and take on the role of the participant as an observer (Brannan & Oultram, 2012). This also meant employees who were not interviewed initiated casual conversations with her on the research topic. They shared their experiences, thoughts, and concerns. This led to valuable insights on how other authorities and the Parliament influenced IT development. Both the observations and these conversations were captured as field notes observations (Blomberg & Burrell, 2012). The interviews were transcribed and, together with the field notes and the documents detailing tasks and system documentation, imported to MAXQDA 2020 (VERBI Software, 2019), where the coding took place.

Data analysis
Initially, we wanted to explore how and why TD arises. Our understanding of the phenomenon was sharpened through an open analysis, on-site data collection, and discussions with academic colleagues, before we conducted an open-ended exploration of the main themes and patterns of the interview transcripts, field notes, and documents (Glaser & Strauss, 1967). During the initial coding of the empirical material, we detected a pattern in how responsibility for prioritizing TD tasks was taken by or delegated to specific employees in Agency X. Moreover, we identified both internal and external stakeholders who wielded influence over TD management activities (Rios et al., 2018). Therefore, we chose to combine TD with ST as a theoretical lens to capture how stakeholders influence TD. We recorded the material using the new analytical lens of ST and through Rios et al.'s categorization of TDM macro activities. However, we added the category create TD to cover activities involved in creating TD (Tom, Aurum, & Vidgen, 2013) because Rios et al.'s (2018) categories encompass the management of TD rather than the entire TD lifecycle. Furthermore, during our iterative coding, we expanded the monitor TD category to include the creation of workarounds and the postponement of dealing with TD (Glaser & Strauss, 1967).
We incorporated three dimensions of ST in our analytical strategy. First, we identified the stakeholders in IT systems, working holistically and including the external and internal stakeholders that we encountered (Freeman, 1984). Second, we explored the stakeholders' actions or interactions relating to the selected IT systems (Freeman, 1984). Third, we highlighted the TD consequences of stakeholders' actions using Rios et al.'s (2018) categories (prevent TD, identify TD, monitor TD, and pay TD), along with our new category, create TD.

Findings
In this section, we present the results of our analysis of stakeholders' influence on TD. First, we identify the stakeholders in the TEXT and REPORT systems related to TD. Next, we map them, their actions, and their influence on TD. Then we compare the stakeholders of the TEXT and REPORT systems and explore how the differences in stakeholders in the two systems affected TD. Lastly, we provide a high-level overview of the stakeholders and their influence on TD.

Stakeholder analysis of TEXT
The following section describes TEXT and its TD stakeholders. The Appendix contains a general stakeholder description.

System description of the TEXT system
The TEXT system is a content management system (CMS) that was built in 2012 as part of a new type of IT system. The vision was to have several IT systems instead of one large mainframe. Back-end IT systems like TEXT were introduced to reuse as many of the existing functionalities of the IT systems as possible. Thus, when the front-end IT system needs specific general functionality, it uses the back-end systems-in this instance, to pull text. This setup allows the users to quickly edit the text without the assistance of developers. The developer inserted a reference to the actual text in the TEXT system instead of hardcoding the text in the front-end system. Should the TEXT system have a breakdown, all the IT systems using the TEXT system would be filled with these references instead of actual text. A breakdown would therefore be critical for Agency X, although fortunately the TEXT system appears to run without such difficulties. We analyzed the TD types in the TEXT system and found seven of them (Rios et al., 2018). Additionally, we found that incorrect usage of the system blocked some of its functions. Table 3 shows how TEXT's TD challenges lie in over-complex code, insufficient processes, and disappointing usability, and offers examples of the potential negative consequences of each of these TD types.

Stakeholder mapping of the TEXT system
We identified seven internal stakeholders and two external stakeholders that influenced TEXT's TD (Fig. 2). The internal stakeholders were as follows: (1) other IT systems' teams; (2) IT projects' teams that were integrated into the TEXT system to store the text snippets there; (3) the expert users that work with the TEXT system and ensure that it is comprehensible and actionable; (4) application managers who manage the maintenance of the organization's IT systems and their further development; (5) the IT architects who plan the overall architecture of the systems and ensure that future solutions fit the framework; (6) the IT operations staff who maintain the servers on which the IT systems run; and (7) the board of directors that prioritizes projects and resources. The two external stakeholders, meanwhile, are (1) the software companies that develop IT systems with the agency and (2) the Digitization Agency, which sends quality requirements for the board of directors to address.
We further analyzed the stakeholders' stance in terms of whether they posed a threat to the accumulation of TD and in terms of their cooperation level (Fig. 3) (Blair & Whitehead, 1988). Two of the stakeholders are considered a mixed blessing while three are considered supportive. We classify the teams working on other IT projects and other IT systems as non-supportive because their use of the TEXT system makes it more challenging to maintain the system. Only IT operation is identified as a marginal stakeholder. We find that stakeholder actions can lead to a cascade of TD types. Some stakeholders can cause both TD creation and reduction, but this is not necessarily limited to a specific TD type, which means the TD types and stakeholders cannot be mapped directly.

Stakeholders' actions and their TD consequences in the TEXT system
We mapped the identified stakeholders, the stakeholders' actions, and the TD consequences in Table 4. For example, the application managers (column 1) perform actions (column 2) that have TD consequences (column 3). We categorized the TD consequences according to Rios et al. (2018), as described in Section 4.3.

Stakeholder consequences on TD in TEXT: an example
The following example from the TEXT system involves several stakeholders and different types of TD consequences. The Digitization Agency (stakeholder) set quality requirements for the authorities (including Agency X). It required that all societal and critical applications be evaluated by the respective authorities (identify their TD). The authorities were then required to make an action plan to remediate issues identified in the evaluation (pay the TD), which included Agency X and the TEXT system. The TEXT system became a focal point of the board of directors (stakeholder). The IT architects (stakeholder) identified the different possibilities for paying TD, not only for the TEXT system but also for other CMS systems at Agency X. Consequently, the board of directors decided to centralize the CMS functionalities in one application. Thus, the TD in the TEXT system became obsolete and was thereby paid. The Digitization Agency, with its quality requirements, required Agency X to identify TD and pay TD. The TD in this case was paid as the board of directors decided to terminate the TEXT system and combine all of the CMS systems into one. Thus, this consequence ties into all of the TD types and helps to reduce TD.  Fig. 2. The Internal and External Stakeholders of the IT System TEXT. Table 5 maps the internal and external stakeholders of TEXT and their influence on TD. The most frequent consequence of stakeholder influence was the payment of TD; seven stakeholders' actions had this consequence. The least frequent consequence caused by the actions of stakeholders was the prevention of TD. Application managers and IT architects were the only stakeholders whose actions prevented TD.

Remarks on the TEXT system
In the TEXT system, we observed that the software developers were not alone in creating TD. Other stakeholders influenced which tasks software developers worked on, when they did so, and whether the work created TD. Most of the stakeholders paid TD and identified TD but only two prevented TD. After TEXT was built, further IT development was limited, although expert users were despondent towards the system. TEXT supports only text snippets, but Agency X's CMS needs exceeded this basic functionality, which is confirmed by the number of other CMS solutions in their IT landscape. Thus, TD can be created by a lack of IT development. The debt then continues to grow until a stakeholder ensures it is paid or the system is replaced. The consequences of the Digitization Agency's actions show that external quality requirements are beneficial for managing TD in public organizations.

Stakeholder analysis of REPORT
The following section describes the REPORT system and its TD stakeholders. The Appendix contains a general stakeholder description.

System description of REPORT
The REPORT system offers a platform where citizens can report specific activities, thus providing information that is then used by authorities to conduct casework. REPORT was developed on behalf of a different authority, Authority Z. Legally, Authority Z is responsible for providing the service to citizens and the authorities who need it to perform their casework. Should the legislation become obsolete, the IT system would be shut down. Because Authority Z is responsible for REPORT, Authority Z provides funding for the maintenance and development of the IT system. We analyzed the TD types in the REPORT system and found seven of them. Additionally, we found that short deadlines can lead to TD creation, because short deadlines cause fastpaced coding and low prioritization of maintenance. Table 6 illustrates how REPORT's TD challenges relate to a lack of maintenance (tests, documentation, and framework updates).

Stakeholder mapping of the REPORT system
We identified four internal stakeholders and seven external stakeholders for the REPORT system's TD (Fig. 4). The internal stakeholders were (1) application managers who maintain the IT systems and supervise their further development; (2) IT Operation responsible for maintaining the servers; (3) IT architects who plan the overall system architecture and ensure that future solutions fit the architecture; and (4) law graduates who ensure that the IT system adheres to the legislation. The seven external stakeholders were (1) software companies hired to build and maintain the IT system in collaboration with Agency X; (2) citizens using the services the authorities provide; (3) the EU Parliament, which sends out directives for governments to follow (e.g., the GDPR); (4) the Danish Parliament, which creates and changes legislation that the system supports or adheres to; (5) Authority Z, which serves as the funder and task setter; (6) authorities that act as collaborators and who contribute to and receive data from the IT system; and (7) authorities that act as users, performing casework using the IT system.
We further analyzed the stakeholders' stance regarding whether they are a threat to the accumulation of TD or whether they cooperate to reduce TD (Fig. 5). Four of the stakeholders are considered a mixed blessing, five are considered supportive, and only IT operation was considered a marginal stakeholder. We found the citizens to be nonsupportive because they test the system by inserting incorrect data, which later has to be corrected.

Relation between stakeholders' stance and TD types in the REPORT system
Some stakeholders can cause TDM activities that create or reduce TD, but their actions are not necessarily targeted to a specific TD type. For example, the short deadlines for tasks imposed by the Danish or European Parliament can cause the agency to draw up requirements too quickly, meaning that they are not properly checked, tested, or documented (requirement debt, test debt, test automation debt, and documentation debt). Furthermore, these short deadlines can postpone automizing of data extractions, which the external authorities request using a short deadline (process debt). Table 7 presents our mapping of the REPORT systems' stakeholders, their actions, and the consequences of these actions on TD. For example, law graduates (column 1) prioritize tasks, communicate other authorities' needs, and ensure compliance with legislation (column 2). These actions can prevent TD and pay TD (column 3).

Stakeholder consequences on TD on the REPORT system: an example
The following scenario involves several stakeholders and the TD consequences of their actions. The authorities (as collaborators and users) require a specific dataset. This task has a very short deadline, meaning that other tasks are deprioritized and there is insufficient time to test. Thus, this requirement creates TD.
The REPORT system does not allow previous editions of the reported information. This functionality minimizes fraud but is inconvenient when the information is incorrect. The law graduate (a stakeholder) identifies TD caused by some citizens who create TD by running test reports. In these cases, the law graduate would like to be able to delete these reports so that they do not interfere with the data, thus paying TD. The data is expected to be reliable and accurate because Agency X uses the data to generate statistics and inform collaborating authorities. Thanks to continuous development, REPORT has grown, but this growth has decreased usability for citizens. Furthermore, the EU (a stakeholder) has passed legislation that requires a new group of citizens to use the system. A new type of control must be implemented in the IT system to accommodate the citizens securely. Therefore, the law graduate argues that it is time to rethink the system and consider refactoring it. They suggest paying TD by refactoring the system and specifying the needs of the system to prevent TD.

Overview of the stakeholders and their influence on the REPORT system
In Table 8, we present the internal and external stakeholders of REPORT, their actions, and the TD consequences of those actions. The primary consequence of their actions is to pay TD; the actions of eight of the eleven stakeholders have this consequence on TD. The least frequent consequence is the monitoring of TD, which is caused by the actions of three stakeholders: application managers, IT architects, and IT operations staff.

Remarks on the REPORT system
REPORT is a political system developed on behalf of Authority Z. Therefore, its stakeholders are mostly external. The political interest and external funding result in the REPORT system being in a state of continuous development. Thus, the risk of introducing TD is high; however, we found that the external funding and continuous development also enabled the TD to be paid more promptly. This case shows the power of the external stakeholders. They (1) create TD, (2) allocate funding for this specific system, and (3) influence the priority of the IT system because it is used by external users.

Comparison of the stakeholders' consequences on TEXT and REPORT
The two IT systems have different purposes and stakeholders. TEXT has predominantly internal stakeholders, whereas REPORT's stakeholders are predominantly external. The difference in stakeholders influenced the systems' further development. TEXT accumulated TD, as   it was primarily visible to internal stakeholders, whereas REPORT appeared to pay back a large portion of its TD continually. REPORT has more external stakeholders than TEXT, and because Agency X strives for professionalism, TD affecting external stakeholders has a high priority. The external funding from Authority Z means that the board of directors cannot remove funding and create TD, and so the authority prevents TD. In contrast, TEXT lost resources because the shared funding was spent. This in turn led to the postponement of planned debt, which was meant to relieve the expert users. We identify seven TD types for the IT systems in both TEXT and REPORT. TEXT is affected by a lack of resources and development, meaning that even debt affecting the usability is not prioritized by the agency. In contrast, the development of the REPORT system is sometimes fast-paced and oriented towards the users. Here the difference between the priority of front-end and back-end systems is clear. There is greater political focus and more development on the REPORT system, whereas the TEXT system received little attention until the Digitization Agency required public organizations to map the IT systems and the systems' vulnerabilities.
The stakeholder landscape, and thus their stance, also differed across the two systems. REPORT has one non-supportive stakeholder but four supportive stakeholders. In comparison, TEXT has two non-supportive stakeholders and three supportive stakeholders. Thus, REPORT's stakeholders appear more supportive and are more prone to cause TD reduction, whereas TEXT's stakeholders appear less supportive and more prone to cause TD creation.
The REPORT system is influenced continually by legislation passed by the EU and Danish Parliaments. Agency X prioritizes TD legislation because of its organizational values. The agency ensures that REPORT supports the legislation so that citizens can report the required information. Additionally, the REPORT system must adhere to the legislation (e.g., the GDPR). More resources for IT development were directed towards REPORT than TEXT; the IT deployment increased the creation of TD. This, along with the new requirements, caused the law graduate to consider refactoring the REPORT system and paying TD. In contrast, the lack of development activity in the TEXT system prevents the system from being sufficiently improved to be able to address Agency X's CMS needs. The TEXT system works even though the usability was low; eventually, however, the system is scheduled to be replaced as it is no longer of a sufficient quality.
To summarize, REPORT is a front-end system, TEXT is a back-end system, and they have different stakeholders. This difference caused different kinds of TD consequences. One solution for addressing TD is to perform stakeholder management. However, stakeholder management must be tailored to specific IT systems because such systems have different stakeholders.

The stakeholders in Agency X who affect TD
The IT systems we analyzed were distinct and involved a range of stakeholders. However, there was some overlap among stakeholders, and the stakeholders' actions did not appear to change between the systems. We have synthesized our findings from the case study by mapping the high-level categorization of stakeholders and their consequences on TD (Table 9).
Note that all the stakeholders may contribute to paying TD. Surprisingly, we found that most of the stakeholders contributed to creating TD as well. The actions of certain stakeholders cause specific consequences (e.g., the prevention and monitoring of TD). The other authorities, legal administration, and IT department prevent TD and the internal users and IT department monitor TD. Some TD is inevitable; it occurs in both frequently and seldom developed IT systems. Agency X pays the TD on an IT system when it is held accountable by different authorities. Furthermore, software developers are not the only stakeholder groups to create and pay TD. The actions of non-technical external stakeholders may have consequences on TD. Thus, TD can occur in different types of IT systems and be generated by a range of stakeholders.

Discussion
In this section, we discuss our findings and relate them to previous TD studies (Table 8). Our mappings provide an insight into the TD types found in the IT systems and the various stakeholders' stances towards TD. Our research shows how different stakeholders influenced the TD in an agency's IT systems. It provides empirical insights on how stakeholders influence TD in the public sector. Finally, we expand on Rios et al.'s (2018) TDM overview and recommend practical TDM strategies.

Research implication
Previous TD research has focused on organizations in the private sector, leaving behind a knowledge gap on TD in the public sector (Klinger et al., 2011;Yli-Huumo et al., 2016). Public organizations adhere to different values than private companies (Rose et al., 2018). This is important to stakeholder analysis because ST is based on creating value for the stakeholders. Our study is unique in combining ST with TD to explore how stakeholders in the public setting influence TD (Table 10).
Previous studies have distinguished between technical and non-   (Klinger et al., 2011;Yli-Huumo et al., 2016). We expanded the classification of stakeholders by conducting a case study in a government agency (Axelsson et al., 2013). Most of the agency's stakeholders were non-technical, e.g., other authorities, external political entities, and the legal administration. Furthermore, our categorization enabled us to illustrate that the two IT systems have different stakeholders who have distinctive stances and helped us to stage a nuanced exploration of the stakeholders' activities and their TD consequences. This implies that TDM strategies and activities should be tailored to the specific context. Rios et al. (2018) map 15 types of TD and provide definitions and examples of these TD types. Previous TD research has identified TD types based on coding, surveys, and interviews with IT professionals (Freire et al., 2020;Pérez et al., 2021;Ramač et al., 2022;Rios et al., 2020). Furthermore, they map TD types with TD causes and TD effects (Ramač et al., 2022;Rios et al., 2020) and preventive and payment actions (Freire et al., 2020;Pérez et al., 2021). We find that mapping TD types provides an insight into an IT system's challenges and the corresponding TDM strategies that should be implemented. However, mapping TD types does not indicate exactly how extensive a threat each individual TD type poses. We gained an understanding of how each TD is perceived and which challenges TD causes on a daily basis, by interviewing and observing the technical and non-technical employees interacting with the system. Rios et al. (2018) identified TDM actions and TDM macro actions and mapped them with existing tools and strategies for TD. We have regarded TDM actions as the consequences of actions by stakeholders. Furthermore, we expand on Rios et al.'s (2018) work by mapping stakeholders to TDM macro actions. Yli-Huumo et al. (2016) propose a TDM framework for mapping TDM activities, the tools that support these activities, and those who are responsible for performing the activities. However, they do not map which stakeholders perform the activities. We found that the actions performed in two different IT systems were similar, and the actions led to the same TD consequences. Some of the stakeholders' actions overlapped; additionally, we found that different types of TD actions were performed by different stakeholders. Thus, the actions of a stakeholder are not unique, and this fact increases the robustness of TDM activities. Klinger et al. (2011) found that non-technical stakeholders can contribute to creating TD, while Yli-Huumo et al. (2016) discovered that business stakeholders may influence TDM activities. Our study confirms and elaborates on these findings. We also found that non-technical stakeholders potentially contribute to the prevention, monitoring, and payment of TD. The degree of different stakeholders' influence varied, and the same stakeholder could have several consequences on TD (e.g., both the creation and payment of TD). The consequence of stakeholders' actions on TD consequence influences how to manage and prioritize TD. Not just technical but also non-technical stakeholders influence TD. Therefore, the influence of non-technical stakeholders must be considered when managing TD.
Previous TD research has mostly focused on internal stakeholders, such as software developers, but we have also identified stakeholders external to the organization. We found that several groups of stakeholders (beyond software developers and other internal stakeholders) act in ways that have important consequences on TD. The authorities are required to collaborate to solve their tasks. Some authorities-for example, the Digitization Agency-set quality requirements that impact other authorities. Furthermore, the authorities must adhere to and support new legislation passed by the Parliament. The actions of these external stakeholders have consequences on TD. Rose et al. (2018) identify professionalism, efficiency, service, and engagement as important values in the public sector. We found that these values were central to Agency X and reflected the influence granted to its external stakeholders. As a result, the agency served the authorities quickly and risked creating TD, but also prioritized the IT system and TDM management. This is important because identifying how TD is created makes it possible to prevent or monitor the TD; thus, it constitutes a critical step in ensuring proper TDM.
We combine ST and TD to explore the relationship between stakeholders and TD activities. The two IT systems are distinctive, they have different TD challenges, and their stakeholders have different stances. Combining ST and TD enables us to explore how TD is created by the consequences of stakeholders' actions. The public organizational values have a significant impact on the prioritization of the IT systems, enabling front-end systems to gain a higher priority.

Practical implications
TD is essential for Governments to address as it can be a structural barrier to digital government (Wilson & Mergel, 2022). Our study has several implications for practitioners. We find that various stakeholders influence TD; it is, therefore, critical that the organization understands and mitigates the stakeholders' impact on TD. First, we found that the stakeholder landscape was larger than reported in previous studies. Second, we found that most of Agency X's stakeholders were nontechnical. Thus, TDM cannot be handled by the IT department alone; some non-technical stakeholders must participate as well. As a first step, the various stakeholders must agree on a definition of TD. Such an agreement can make it easier to discuss TD, the difficulties it imposes, TDM activities, and create policy documents regarding TD and TDM.
Third, we found that stakeholder mapping could serve as a tool to identify stakeholders' influence and their respective stances on the system's TD. Numerous stakeholders in the public sector are external, and hence challenging to manage. However, by identifying the risk of a given stakeholder creating TD, an agency can take some precautions or simply increase the frequency of paying TD. Furthermore, identification of the TD types could improve the strategy for improving TD payment and prevention. It is vital that organizations realize and mitigate the risk of TD creation. We, therefore, recommend that the organizations create a stakeholder map, and map TD types to take appropriate actions to manage their TD. Our findings also show that the IT systems' stakeholders differ. Therefore, it is necessary to create stakeholder maps for each of an agency's IT systems. This information can then be incorporated into strategies that address TD, and for example, be integrated into policy documents.

Concluding remarks
This study explored how stakeholders influenced the TD in a public agency. The aim was to gather empirical insights on how stakeholders influence TDM. We conducted a longitudinal case study in an agency. The observations and interviews were performed over five months. We combined ST and TD to serve as our theoretical lens to identify the stakeholders, their actions, and the influence of their actions on TD.
Our study makes empirical, practical, and theoretical contributions on stakeholders' influence on TD in the public sector. First, by mapping stakeholders, it was revealed that the relevant stakeholders differ across IT systems. Most of the stakeholders we identified were non-technical and were both internal and external to the organization. Second, the TD types and TDM categorization gave insights into the TD challenges for each IT system, and how these challenges can be addressed by practitioners. Third, ST combined with TD can be used to explore how different stakeholders influence TD. For example, users of IT systems are inclined to identify TD while task and funding providers tend to both resolve and create TD.
Finally, we offer a note on the methodological and conceptual limitations of this study and present potential avenues for future research. Nielsen et al. (2020) identify a lack of research concerning actual TD behavior, therefore we employ a qualitative approach (including interviews and observations) to capture TD behavior. To further narrow our focus on practices surrounding TD, we chose an embedded case study approach and excluded source code examination, as this was already captured by previous studies (Nielsen et al., 2020). This methodological approach enabled us to capture the underlying factors leading to practitioners' TD behavior. A source code examination might have contributed to identifying the TD types, and allowing for a comparison between code quality and how the IT systems are perceived by the stakeholders. Another methodological limitation is caused by the fact that TD can take several years to surface. Thus, a five-month study may not capture all the actions which cause TD creation, or indeed all the consequences of TD.
Further, TD is an evolving concept with its own limitations. First, there is no uniform definition of TD in the extant literature, which may create confusion on what constitutes as TD (Fairbanks, 2020). To address this conceptual limitation, we have employed a broad understanding of TD combined with specific TD types and activities in our analysis. Moreover, the existing literature has primarily revolved around source code and the technical elements of TD (Nielsen et al., 2020). Therefore, existing TD research has focused on technical stakeholders, omitting the political and administrative level and stakeholders. We mitigate this limitation and contribute to TD research by analyzing the organizational processes surrounding TD and identifying non-technical stakeholders, such as the Danish and EU parliaments, legal administration, and caseworkers.
Future studies can extend our study and combine these techniques (observation, in-situ interviews, and document analysis) with code examinations. A case study can be generalized on an analytical and theoretical level, but it cannot be generalized on a statistical level (Yin, 2018). The agency we studied might not be representative and therefore the conditions of our study may impact the use of our findings and recommendations in other settings We encourage scholars to repeat our study and expand on it. Follow-up studies could be conducted on different IT systems or in different agencies. Studies assessing systems with different IT development patterns would allow for comparison and discussion of the stakeholders' influence on TD. Such studies can contribute to the development of general management strategies for public organizations. Their results would help to reduce TD's potential negative impact, improve efficiency and stability, and reduce costs in the public sector. Finally, the long-term causes and consequences of TD would be an interesting topic for future studies.

Declaration of Competing Interest
None.
The board of directors decides which new IT projects the IT department should initiate. It determines the priority of the projects and systems, thus influencing the resources assigned to them. For example, when a project is delayed, the board of directors decides whether resources from other IT systems or projects should be moved to the delayed project.
IT department. We describe four categories within the IT department.
(1) The IT operations team maintains the servers the IT systems are deployed to and are responsible for IT security. They also ensure that the deployment process runs smoothly by monitoring the IT systems and troubleshooting malfunctions. For example, during traffic peaks, they ensure that the IT systems do not become unavailable to citizens. (2) Application managers manage IT systems, including setting priorities for maintenance and minor IT development tasks. They ensure that the business's needs are met and that incidents are handled. An application manager links the developer, the relevant business unit, and the IT architect, as well as working with the business unit to plan and prioritize tasks. (3) IT architects plan the overall architecture of IT systems and ensure that future solutions fit into the architecture. When an IT developer proposes more than one solution, the IT architect determines which is the most suitable of the available options. (4) IT project teams develop new IT solutions for existing IT systems or develop new IT systems. When they integrate solutions into existing IT systems, they often need to adjust the IT system to improve functionality.
Legal administration. Agency X has a legal team in addition to having law graduates working in the different business units. They ensure that the IT systems support legislation and that systems remain in adherence to the law when new functionality is added.
Internal users. Agency X has caseworkers and experts using the systems that we classify as internal users. The expert users gather information from the other internal users and provide feedback to the IT team that manages the system. The expert users become involved when the IT system requires further development. They clarify requirements and test new features.
Citizens. The citizens use the agency's services and thus the IT systems that the agency provides. Furthermore, they provide feedback to the agency (e. g., by contacting support). Their feedback is included when setting priorities for IT development. We spoke with a caseworker who emphasized that one of the agency's responsibilities was to be responsive to the problems and suggestions flagged by citizens.
Software companies. Agency X hires software companies to sit on-site to collaborate on developing and maintaining the IT systems. The consultancy company gives feedback on the state of the IT systems, suggests solutions, and codes the individual tasks.
Other authorities. The authorities that serve as stakeholders (including the Digitization Agency, which sets quality requirements for IT systems in public organizations) fall into one or a combination of four categories. First, there are task setters and funding providers such as Authority Z. Agency X has, on several occasions, developed an IT system on behalf of other authorities and ministries. For example, Agency X built and maintains REPORT for Authority Z, which continues to present its needs to Agency X and provide funding. Second, authorities can be users because their employees may use the system, which is seen in REPORT. Third, authorities can, and often must be, collaborators because they exchange data. For example, someone might need to be reported to the police or tax office. Fourth, authorities can set quality requirements for IT systems. For instance, the Digitization Agency required the authorities to map their critical IT systems and create action plans for the problems they encountered.
External political entities.