Beyond Technical Debt Unravelling Organisational Debt Concept

The development of software and systems is a complex task that involves social, technical and organisational factors. Technical debt is a well-known concept that refers to the negative consequences of taking shortcuts in software development. However, organisational debt (OD) is a less well-known phenomenon that arises due to shortcuts in the organisational structure and processes of a software organisation. The lack of a clearly defined OD makes it difficult to identify and manage this type of debt. This study presents a multi-vocabulary literature review that consolidates an understanding of the nature of OD and its impact on software organisations. OD encompasses a set of attributes, precedents and outcomes. In addition, this study highlights the five causes and mitigation strategies of OD. The results of this study indicate that software companies are facing a major issue with OD. Future research should include empirical studies to validate techniques that can assist software professionals in managing OD to address this issue.


INTRODUCTION
The field of software engineering is constantly developing, new paradigms and methodologies are often emerging and dominate the research agenda.This rapid development is a challenge for businesses and software professionals, but it also provides many opportunities for learning and continuous improvement.This constant change can be attributed to the inherent nature of the software [1].The development and maintenance of software based on traditional software engineering methods is becoming more and more difficult as the software continues to evolve.New paradigms and practices to address these challenges are constantly emerging [1][2][3] [47] [48].
First-generation agile methods are very developer-centric.The development team implemented agile practices to ensure frequent delivery of deployable software, which was then passed to the quality assurance (QA) team for testing and validation.At present, several organisations are moving towards a holistic team approach [44].The software development process should therefore involve cross-functional teams consisting of development, quality assurance and operations departments.It reduces hand-offs between teams and may lead to faster development cycles and a greater sense of ownership of the product [44].However, when working under tight deadlines, features are prioritized over quality, and lack of documentation creates a software debt [3][4][5][6][7][8][9][10][11][12].Maintaining software in both technical and non-technical ways may adversely affect its reliability and efficiency [13] [11] [14].
While technical debt (TD) has received significant attention in academic literature [13], there is a lack of understanding of non-technical debt (NTD) [11] [14] [45].NTD comprises process, social, and people debt types [13].Whereas Liu et al [45] define organisational debt (OD) as social and process debt.The ambiguous definition of OD complicates its identification and development of mitigation strategies.Therefore, there is a need to define OD to help practitioners and academics understand how OD is affecting organisations.
This study aims to consolidate the understanding of the nature of OD, its impact on software companies, and to facilitate the future research agenda on OD.The research will address the following questions: -What is organisational debt?-What are the causes and consequences of OD? -How OD can be identified and managed? - In what ways can future research explore and develop our understanding of OD?This is the first multi-vocal literature review conducted on this topic.The results of this review will provide insights into the nature of OD in the software industry, offer OD mitigation strategies and future research directions.
The structure of the study is as follows: Section 2 provides the background information, Section 3 describes the design of our MLR, Section 4 presents the results of the study, Section 5 addresses potential limitations and threats to validity, and Section 6 provides a discussion and concluding remarks.

BACKGROUND
The software development process is a complex process.Its complexity arises from the relationships and interactions among a large number of stakeholders, which have to unpredictable behaviour.Additionally, each project is unique, with specific challenges stemming from the diverse backgrounds of individuals involved and the problem domain.In view of the fact that technology and organisational processes are constantly evolving, these factors interact in unpredictable ways.
Agile and Lean processes prioritize frequent delivery of value to customers by eliminating waste that hinders productivity and quality [3] [47] [48].Treating team members as interchangeable 'resources' and constantly swapping them in and out of projects is ineffective.Enforcing a rigid and inflexible process may lead to complacency between management, who may assume that the process solves all problems.In addition, they often blame the team for not following the process when problems occur.The "Just get it done" approach is the primary driver of debt in software development.
In 1992, Cunningham [4] introduced the concept of TD and described how "Shipping first-time code is like going into debt.A small debt accelerates development as long as it is promptly paid back with a rewrite...The danger occurs when the debt is not repaid.Every minute spent on a not-quite-right code counts as interest on the debt.Entire engineering organizations can be brought to a standstill under the debt load of an unconsolidated implementation."Avgeriou et al. [5] elaborated on this definition: 'TD is a collection of design or implementation constructs that are expedient in the short term, but set up a technical context that can make future changes more costly or impossible.TD represents an actual or contingent liability whose impact is limited to internal system qualities, primarily maintainability and evolvability.Other types of TD include architectural debt, code debt, and test debt [11] [13].
Extensive research has been carried out on technical debt (TD) from a wide range of perspectives, including efforts, tools, types, management strategies, architectural aspects, agile development and prioritisation [12] [13] [15] [18-21].Rios et al. [15] reported 78 causes and 66 effects of TD.The main reported causes were deadlines, obsolete or incomplete documentation, lack of technical knowledge, inappropriate planning, lack of knowledge of technology, a focus on higher production at the expense of quality, and lack of a well-defined process.Avgeriou et al. [18] conducted comparisons of tools used for measuring TD, assessing their features, popularity, and empirical validity, and found that TD results in reduced maintainability and quality, amplified project costs, financial losses, bad code refactoring, team overload, difficulties in implementing the system and stakeholder dissatisfaction.Khomyakov et al. [21] specifically explored TD measurement and analysis tools, focusing on quantitative methods that could be automated.Besker et al. [20] address architectural TD and combined research efforts to produce new insights with a specific interest in the topic.The findings indicate a lack of efficient management principles for architectural debt.In agile software development, Behutiye et al. [19] stress the significance of timely delivery and design matters, which may precipitate TD pitfalls.The adverse outcomes of TD in agile software development comprise reduced output, system quality, and escalated maintenance costs.Lenarduzzi et al. [13] found that code debt and architectural debt are the most common types of TD studied.Nevertheless, research into other types of TD, including test debt and requirement debt, was limited.
The CISQ 2020 report assessed the cost of poor software quality in the US to be $2.08 trillion, with an additional $1.31 trillion required for the correction of severe defects [6].The Danish government faced challenges as a third of its critical IT systems were inadequate, lacking proper documentation, security, and requiring software and hardware upgrades [8].Sweden's government agencies also struggled with outdated IT systems, affecting 70% of their setups [9].
According to Klinger et al. [10] "the decision to acquire TD is not made by technical architects, but rather by non-technical stakeholders who cause the project to acquire new technical debt or discover existing TD that wasn't previously visible" (p.35).Software project success or failure depends on both technical and non-technical factors.TD has received more attention in research and practice compared to NTD in software development [11].
NTD refer to a range of debt types that can arise in software companies, including process, social, people, cultural and OD [11] [14].NTD stems from suboptimal decisions that prioritise short-term gains over long-term sustainability, which can impede software development activities.
Process debt is a "suboptimal action or event with short-term advantages but long-term detrimental effects" [17].Teams incur process debt when conducting stand-up meetings solely for status updates to leaders, limiting the meetings' full potential.The leading causes of process debt are lack of process competencies, process divergence, and external dependencies (i.e.technology, tools and external trends) [11].
People debt refers to "people issues that, if present in the software organization, can delay or hinder some development activities", for example, expertise focussed on a few personnel, as an effect of delayed training and hiring [11] [14].People's debt causes examples are lack of knowledge, experience, commitment and lack of psychological safety, inadequate management decisions and low developer morale [11].
"Cultural debt is a technical decision that borrows against the organization's culture.Such decisions can introduce team divisions, deteriorate communication or even weaken leadership effectiveness" [14].The leading causes of cultural debt include hiring the wrong people, dismissing complaints, charging discrepancies, and giving unequal rewards [14].
Social debt refers to "the presence of sub-optimality in the development community, which causes a negative effect on software development" [16].The example of social debt is community smells which include lone wolf, and radio silence/bottleneck [11].Social debt causes are gender bias, communication, collaboration and coordination challenges, and community smells [11].
Introducing new policies for hybrid work can expose managers to the potential of incurring OD [45].These policies have the power to shape the norms that develop among employees.If managers fail to address unfavourable norms promptly, they will be faced with the consequences of this OD in future.Liu et al [45] research identified 23 mechanisms, grouped into eight general coordination categories, and assessed their impact on aspects such as shared mental models, team coordination, team cohesion, and team learning.

RESEARCH METHOD
Multivocal literature review (MLR) is a research method that uses both grey and scientific literature to examine a wider range of software engineering challenges [7].Typically MLR comprises readily accessible writings in a range of forms.Since it contains views of diverse writers and incorporates nonscientific material, it is critical to develop a clear goal before conducting MLR.Thus, the overall goal of our MLR was to understand how software practitioners describe the "organisational debt" phenomenon.We follow Garousi and Mantyla [7] MLR guidelines.To search for relevant literature Google search engine was chosen over more academic databases (e.g.SpringerLink, ACM, IEEE eXplore etc.) because "organisational debt" is a very new topic and very little academic research is available.Google search engines could effectively locate grey literature.In June 2023, the Google search engine was used to locate literature, using the query ("organizational debt" OR "organisational debt" AND "software").The search string was developed based on the scope of our study, which included the search terms "population" and "intervention".The rationale for using the term "software" was that this study would cover studies that discussed software, software development, software engineering, or software-intensive products, services, and systems.The term ("organizational debt" OR "organisational debt") was used to include all OD papers.We selected the first 120 sources of our search results.According to Haddaway et al [2] in grey literature, researchers commonly chose the first 50 search results.Each link was checked and relevant records were saved in a Microsoft Excel sheet.All other sources were excluded that were not in English, videos, ads, catalogues, duplicates, research profiles, or outside of the software engineering domain.In total, 22 blog posts out of 120 sources were included, which are cited in the reference list from [22] to [43].The search strategy didn't capture any scientific relevant articles.The data analysis phase involved using thematic analysis techniques to look for four themes: OD definitions, OD causes, consequences and mitigation strategies.Inside each theme, we openly analyse the data.There were no pre-defined themes or code for causes, effects and mitigation strategies.These were emerged from the data.MLR results are compiled section 4.

RESULTS
In this section, we first provide the grey literature publication trend and compile the list of various OD definitions.Secondly, OD causes and effects are discussed.Thirdly, discuss OD identification and mitigation strategies.

OD concept trend and definition
Our MLR captured 22 OD blogposts published by software industry professionals.The majority of these articles were published after 2018.In 2015 Steve Blank extended the technical debt metaphor and defined the OD in start-ups [34] and published it as "Organizational debt is like TD but worse."This idea can be traced back to 2012, as Ben Horowitz had written it as "management debt" [33].Dignan elaborated that OD is so much bigger than just a start-up phenomenon [31].The MLR results show several OD definitions.Organisational debt is a networked concept that fosters the blame-free identification of cross-functional and crossdepartment weak points" [42].
In software companies, OD refers to the difference between a company's strategic plans and its actual ability to implement them in view of the ever-changing market needs.If a software company does not keep pace with a rapidly evolving market and customers' expectations, it starts to accumulate OD.This debt is a burden that weighs on the company and makes it less agile and responsive to changes in the market.The wider the gap between a company's strategies and its capabilities, the more debt it accumulates.As the debt grows, the company's ability to adapt to market conditions slows down, creating a vicious cycle.The more unresponsive the company the more debt it accumulates.Dragan [25] exemplifies the OD of large companies that lags behind transformative market shifts.Notable examples include Kodak's inability to foresee the advent of digital photography, Blockbuster's obsolescence due to the rise of movie streaming and smart TVs, and Nokia's struggle to adapt to iPhone's revolutionary user experience.These examples remind us of the criticality of foresight, adaptability, and innovation in sustaining organizational success in an evolving industry landscape.
Considering the above discussion and definitions, OD in software companies denotes the gradual build-up of unresolved decisions and unimplemented actions that should have been undertaken by leaders.This accumulation results in structures, policies, and processes that no longer align with the organisation's objectives, ultimately impeding its progress and adaptability in the face of changing circumstances.Consequently, an organisation's ability to achieve optimal performance, agility, and responsiveness is hindered as it struggles to bridge the gap between its intended strategic plans and the practical capacity to meet evolving market demands.

OD Causes and Consequences
OD can be found in any organization and root cause is the pressure to "just get it done" [34] [43].This pressure can come either from within the organisation or from an external competitive business environment.As organisations grow and evolve, they encounter a multitude of challenges also known as "Organizational Debt Syndrome", which arises due to the gradual build-up of compromises and shortcuts made in aspects (i.e.personnel, culture, and leadership practices [41]."The "interest" comes in the form of reduced speed, capacity, engagement, flexibility, and innovation that ultimately undermine the macro objectives of the firm: to survive, thrive, and achieve its purpose" [31].Figure 1, summarises the OD causes, consequences and mitigation strategies.
In most organisations, OD is not frequently measured, nor valued because it's extremely expensive [24].Organisations that are not responsive to change accumulate OD: decreased agility, reduced competitiveness, negative effect on employee morale and increased resistance to change, and eventually lead to inefficiency and bureaucracy [24] [33][40] [41].At a higher level, OD manifests itself in two ways [23] [32] [33]:

Figure1: OD Causes, Consequences, & Mitigation Strategies
Obsolescence occurs when structures and policies become unfit for purpose.While rules and structures may have initially served the organisation well, they can become entrenched and inflexible, impeding adaptability and innovation.


Accumulation occurs when policies and procedures are constantly added but never removed.When employees are unsure of their responsibilities and accountabilities, it leads to confusion and inefficiency.Overcompensating some employees while neglecting others can create perceptions of unfairness, leading to demotivated teams and reduced overall productivity.

Leadership decision aiming to avoid ruckus:
In various companies leading causes of OD are that leaders are hesitant to address underperforming employees directly [32] or complex decision-making processes within bureaucratic organisational structures [30].Instead of addressing performance issues head-on, they may reassign or isolate underperforming employees to avoid confrontation.This culture of avoiding difficult conversations can lead to mediocrity and underperformance becoming accepted norms within the organization [32].Similarly, the fear of causing disruptions or resistance may deter leaders from making necessary changes, especially when the organization is already functioning adequately."Don't fix it if it isn't broke becomes the law of the land" [32].Additionally organisations with excessive management layers, decision-making lead times are prolonged, hindering agility and responsiveness to market changes [30].

OD Identification & Mitigation Strategies
It is important to accept that an organisation accumulates OD over time, so it is important to remain vigilant [42].This is crucial because hidden debt is often the most risky form.
Leaders in an organisation can spot the symptoms of OD by regularly monitoring the company's performance, collecting employee feedback, and conducting regular audits of their work processes.
OD can be identified in two ways.Firstly, a quick examination of the organisational chart can reveal multiple problems, including "redundant organisational structures, side-line projects that attract resources, premature structures, and disorders" [37].Identifying these issues early on allows leaders to address them proactively and prevent the accumulation of further debt.Secondly, conducting a more comprehensive evaluation that encompasses various design components can provide a deeper understanding of OD.This evaluation may involve examining processes, data architecture, talent management, social dynamics, and security [39].Such evaluation helps leaders to gain insights into potential sources of debt and prioritise areas for improvement.Addressing OD involves "refactoring" the team, which means that the innovation team responsible for building the prototype might not be the most suitable team to scale it up [43].It is more beneficial for the innovation team to start the next innovation initiative.There is no silver bullet to handle OD, however, our MLR compiled the following mitigation strategies.

Design workflow for value creation.
Leaders need to design organisational workflows for value creation.This involves avoiding rigid organisational charts and focusing on creating projects with clear purposes along with work-in-progress limits, cadences, and quick and frequent feedback loops [29].A work needs to apply a basic principle of Kanban -limiting work in progress which helps to increase flow and overall productivity thus minimising the risk of OD accumulation.Additionally, transparency is needed in quality information flow, which helps to identify and reduce OD before it grows and becomes unmanageable [42].

4.3.2.
Enable job-crafting and flexible work environment.Allowing individual workers to engage in job-crafting and tailoring their roles empowers them to be more flexible and adaptive.The best way to ensure the organisation keeps flexible while enabling energy flourishing across individuals and teams."[23].Leaders should foster a work environment that encourages such job-crafting and empowers employees to make meaningful contributions.4.3.3Establish a feedback culture and build trust.Nurturing internal trust, and encouraging open and constructive feedback from employees helps identify inefficiencies, bottlenecks, and areas that require improvement [23].A feedback-driven culture fosters continuous improvement and prevents the build-up of debt over time.A steady contact with customers helps to identify weaknesses in a product which is an indicator of OD [42].Involving employees, customers, and other relevant stakeholders from the outset not only provides valuable insights but also fosters a sense of ownership and commitment to the change process [35].4.3.4Practice continuous participatory governance.Involving people in the co-design of roles, structures, and policies can be a powerful way to escape the accumulation of OD [23].Leaders should encourage participatory decision-making and gather insights from various stakeholders to design effective and efficient organizational systems."Don't rush to a policy and process for everything" [31].Continuous participatory governance ensures ongoing alignment with changing needs and prevents the entrenchment of debt."Constantly keep questioning assumptions behind organisational choice" [23].By doing so, they can identify and rectify potential sources of debt arising from outdated or misguided decisions.Questioning assumptions helps create a culture of critical thinking and adaptability.4.3.5 Performance, behavioural, and innovation metrics.Stefan Lindegaard offers three metrics to handle OD [41].Pay attention to performance metrics such as delivery time, employee turnover, productivity, operational cost, sales and revenue, market share and profit margins.Behavioural metrics include employee feedback and satisfaction, meeting dynamics, collaboration and communication patterns.The innovation metrics are customer satisfaction with new products, developers and other employees' engagement in innovation, adoption of new technologies, methods and processes, and several new ideas generation.4.3.6.Launch a bounty program.Some software companies have "bug bounty" and "process bounty" programs to discover errors in their code and process [31].Process bounty is the idea of encouraging employees to highlight a policy or process which hinders their ability to deliver value.Bug bounty comes with a modest monetary reward, to individuals who discover errors in their code.

OD future research directions
We propose a number of areas that further shed light on the OD phenomenon.One of the biggest challenges in managing OD is the difficulty in quantifying it.No single metric can accurately measure the amount of OD in an organisation.However, several metrics can be used to get a more complete picture of the problem.Performance, behavioural, and innovation metrics are a few examples [41].The MLR proposed a number of OD mitigation strategies, but further investigations are needed to confirm or refute its validity.In addition, strategies should be adapted to the specific needs of the organisation, but some general principles include: prioritising debt reduction, investing in continuous improvement, creating a culture of accountability and a psychologically safe environment and empowering employees to make decisions.
A few specific future research directions include investigating (a) the impact of OD on employee morale and productivity, (b) the relationship between OD and customer satisfaction, (c) the role of OD in the success and failure of software projects, (d) the economic impact of OD on businesses, and (e) whether OD can be tackled in the same way as TD.Conducting investigations on these topics would be valuable to the software industry because it would provide better insights into the effective understanding and management of OD.This research can help software companies make informed decisions, optimise processes and improve overall organisational performance by effectively addressing OD.

VALIDITY THREATS AND LIMITATIONS
This MLR follows the guidelines of Garousi and Mantyla [7] to check validity threats.Internal validity was assessed by considering the risk of bias.To ensure repeatability, our MLR source selection process follows a systematic approach with a search engine, search terms and inclusion and exclusion criteria.Threats related to limitations reside in search terms, the use of a single search engine, and bias in the application of inclusion and exclusion criteria.In order to address this problem, a formal search using defined keywords was carried out to reduce the risk of missing relevant studies.The study was conducted by two software engineering researchers.Their experience in the field, along with their educational background, have partially mitigated this threat.
The lack of empirical evidence in primary studies poses a threat to construct validity.Our blog posts' grey literature consists of opinions or experience-based information from practitioners.While this information can be valuable as it reflects real industrial settings, the specific contexts discussed are not always mentioned.This ambiguity raises an epistemological problem as the source of knowledge is unclear [7] and as this limitation cannot be fixed, it doesn't necessarily invalidate our results.If the same individuals providing their opinions and experiences in the grey literature were interviewed or surveyed using a structured questionnaire on the same topic, the results would likely be consistent.The only difference would be a more rigorous research method to collect information from the practitioners.
Another limitation of this study is the lack of peer review literature, making the results potentially anecdotal and less rigorous.However, this study's replicability is ensured by following a systematic approach and a well-defined procedure.Results from replication studies are likely to align with our findings.In addition, the MLR included primary sources written in English, excluding literature written in other languages.This raises the question of whether our selection adequately represents all types of literature in this field.However, it is reasonable to argue that this MLR still contains sufficient information that represent the knowledge of TD and NTD professionals.

DISCUSSION AND CONCLUSION
This study aimed to explore OD in software development contexts, its causes and consequences, and mitigation strategies.While software engineering research tends to focus on TD, relatively little research has been conducted on NTD phenomena such as OD.OD is a multifaceted issue that can be influenced by factors such as corporate culture, leadership, collaboration, process design, decision-making, and organizational structures.This literature review has identified 13 distinct OD definitions.Combining the essence of these definitions, we present a single OD definition: "OD is the result of leaders failing to make necessary decisions and take appropriate actions, leading to structures, policies and processes that are obsolete and no longer beneficial for the organisation.As a result, OD hinders the progress of the organisation's and its ability to adapt to changing circumstances, and ultimately hinders its potential for excellence".
OD arises from due to obsolescence and accumulation and share resemblances with process debt [11] [17].OD presence negative impact on employee morale and performance.Developers may feel disengaged, as they find it challenging to focus on innovation and creative problem-solving when slowed down by legacy issues caused by OD.To enhance agility, it is essential to integrate the Agile Manifesto's philosophy from its core.Prioritise flexibility and adaptation over rigid adherence to outdated processes.Fake agile can lead to increased costs, delays, and frustration.
Mitigating OD necessitates a comprehensive approach.This study has identified six key approaches to mitigate OD.Proactively identifying and mitigating sources of OD enhances adaptability, efficiency, and long-term success.The important point is to accept that every organisation will accumulate debt when it starts growing.Leaders must engage in diagnosis of issues and identify areas where obsolescence or accumulation is causing challenges [23] [32] [33].To effectively address these issues, leaders should continually evaluate and fine-tune the organisational structure, ensuring alignment with strategic objectives and adaptability.
By embracing an agile mindset, leaders foster a resilient and innovative organisation capable of navigating the challenges posed by the constantly evolving business landscape.Understanding these pain points serves as the foundation for formulating effective strategies.Creating a work environment that is flexible and adaptive is vital in dealing with OD.This involves fostering a culture that values innovation, encourages experimentation, and embraces change as an opportunity rather than a threat.A work culture that promotes continuous improvement and learning enables employees to adapt swiftly.Fostering culture of continuous feedback and inclusive decision-making empowers employees across all levels to contribute innovative ideas.This not only harnesses the collective intelligence of organisation but also enhances its agility, enabling more responsive stance in the face of market dynamics.While there are performance, behavioural, and innovation metrics for OD [41], it's essential to recognise that these metrics alone cannot be indicators of success or failure.Agile practitioners need to emphasise the importance of considering their specific organisational context in evaluating progress.
In the agile realm, embracing technological advancements is a fundamental strategy for addressing and mitigating OD.Companies that actively stay up-to-date on cutting-edge technologies and leverage them to streamline processes and boost efficiency are better positioned to meet the everchanging demands of the market.This proactive approach aligns with the agile ethos of adapting quickly to emerging tools and methodologies to drive continuous improvement.Optimising organisational structures is essential to prevent the accumulation of unnecessary complexities.In essence, fostering a culture of continuous improvement, treating change as an opportunity for growth, and fine-tuning processes and structures are foundational steps in shaping a more agile and robust software company.By effectively managing OD, companies can position themselves for sustained success amidst the ever-changing dynamics of the business world.This aligns seamlessly with the agile ethos, emphasizing adaptability and continuous enhancement as core principles for thriving in a dynamic environment.
This first study of OD using MLR sheds light on its causes and effects on software products and professionals.Overcoming these challenges requires joint efforts from academia and software organisations, in line with the agile principle of cross-functional teamwork.We suggest that adopting established technical debt practices [12][13][14][15][16][17][18][19][20][21] could form a basis for addressing OD.However, despite the challenges posed by OD, it is necessary to develop new approaches to address them effectively.We see this study as the first step in a community-driven initiative aimed at addressing these challenges collectively, with an agile ethos of collaboration, adaptability and continuous improvement.
[26] us, but we do not really want to give him or her the power to implement the changes" [28].9."Organisational debt is sibling of technical debt, for example a toxic culture, struggling leader etc"[26].
[27]OD is all the people/culture compromises made to "just get it done" in the early stages of a start-up"[34].7."Organisational debt is the baggage that prevents people from delivering astonishing results"[27].8. "Organisational debt -our organizations are also a good excuse to avoid changes, as we often look for someone who is going to Change.Poorly managed change could be considered of two types.(1) An organisation doesn't adopt changes according to the market.
[36] organisation that doesn't change as fast as the world around it and its customers' needs and expectations will accumulate organisational debt"[25].(2)Anorganisational is unable to manage the change properly when transformation is initiated."Ifanorganizationisnot managing change, it probably cannot manage debt"[35].The need to stay competitive or adopt new technologies, can result in poorly managed changes within the organisation.When new tools, structures and processes are introduced with good intentions but later have limited use contribute to the reduction of individuals' and teams' ability to focus on what matters[36].Further lack of employee training can lead