What Is Technical Debt?
Technical debt exists in any software offering and, if not managed, can have a significant impact on the go-to-market speed, ability to add new features, team productivity, morale, and cost-efficiency.
Aside from unsuitable software architecture, technical debt is the second-highest reason for acquisition deals falling through in technical due diligence. It can and has brought companies down to their knees under competitive pressures or down-right to extinction.
Ward Cunningham used an analogy comparing technical debt to financial debt. It essentially prevents a business from growing profits. The possibilities of growth when you have high-interest debt are limited, and the options available are scarce.
Another common analogy is about building structures and maintenance. This one is interesting as it combines the physical maintenance required to allow a structure to stay useful and evolve. The bridge in the picture is one of many on top of River Khwae Yai in Thailand. Most people will not see a path forward on it. Few customers may decide to cross it, and even fewer companies would sign-up for a job to maintain or repair that bridge - the ROI is just not there. I was there and decided to turn back after 10 feet as the reality of an imminent swim in a fast-moving river was closer to reality. Luckily my need was minimal to embark on that journey. I took my business elsewhere and used a nearby bridge.
Technical debt is not just about code and architecture but applies across the board. Everything from test cases, automation, unit test, integrations, code complexity, or even operational debt can be added to the technical debt backlog.
How Does Technical Debt Accumulate?
Technical debt generally accumulates due to one of those six factors or a combination.
It is rare to see reckless neglect cases. It is observed in businesses designed to generate extreme short-term profits with no intended infrastructure or business models to scale. The intention is often to package and sell. Oftentimes, those hidden jewels are found during a technical due diligence exercise. It’s sad, but they do exist.
Most of the time, technical debt is an honest result of other factors such as lack of know-how, inability to organize, lack of ownership, competitive pressures, and a tech-enabled company culture not acquainted with technology enough.
It can also result from too weak or too controlling product management, sales, or technology leadership.
For example, organizations that are not balanced and are completely driven by one dominating discipline (e.g., sales, product) often have excessive technical debt.
Image Source: VincentDNL Drawings
Technical Debt Based On Company Size
The company stage and situations also matter, so there is no panacea or one glove that fits all.
There are, at times, good reasons for technical debt accumulation. For example, a start-up or a growth company that is seeking to get to market quickly for competitive or revenue pressures may take shortcuts, at least temporarily. Nothing is wrong with that as long as they are tracking it, prioritizing it, and making decisions about it.
Another example is a large company that has multiple products, of which one product is in maintenance mode as a cash cow. Outside fixing a few bugs as a minbar, there is no return on investment in addressing the technical debt.
Impact of Technical Debt
Having a little technical debt or ignoring it for a bit is not a major problem in small doses. Like anything else, the problem manifests itself when it becomes a repeated habit, then it hurts. Unmanaged technical debt is organizational cancer.
An outlier case study: Years ago, I advised a company that, at some point, stopped developing new features, and most of their R&D efforts went towards reactive maintenance addressing client complaints, and fixing bugs. They started shedding clients in double digits numbers to their competition, who offered faster, more scalable, and more modern products. Their employee attrition was also accelerated, with people jumping ship as the writing on the wall became more visible. The combination was a vicious cycle that led to the shuttering of the business within two years. Their technical debt was never prioritized, and when they realized the root causes, it was too late, and the options were limited, with shrinking revenue to invest and no talent to implement.
Technical debt does have a significant psychological impact as well as an economic one. Talented engineers would not want to be stuck maintaining legacy technologies and technical debt - it doesn’t help their careers!
Source: Thanks, We're too busy cartoon
Six Strategies to Avoid and Manage Technical Debt
Ownership Of The Architecture
Continuous Balance and Timely Decisions
Upstream Quality and Healthy Software Development Lifecycle
Strong Product, Sales, And Engineering Collaboration
Excellent Agile Roadmap and Backlog Prioritization
You Must Evolve
1. Ownership Of The Architecture
The software or solution architectures must have an owner to look after it, evolve it, and represent clear articulation about its needs for other non-technical stakeholders in the organization. Without ownership, it cannot evolve, and technical debt will accumulate.
2. Continuous Balance and Timely Decisions
A company cannot be entirely driven by one discipline, such as engineering, product, or sales. There has to be an ongoing balance that is continuously being evaluated with prioritization and decisions.
Sometimes, you must decide not to address a technical debt to meet a strategic release deadline. While other times, you may decide to take on and address much more technical debt and reduce that backlog. What’s most important is the average balanced investment between business needs and technology needs and considering the past, present, and future needs.
The level of investment changes all the time, but the overall average is important indicating the existence of a balanced process and awareness.
3. Upstream Quality and Healthy Software Development Lifecycle
Describing a healthy quality approach or a mature SDLC can take volume. What’s most important, though, is to ensure there are enough quality gates to keep the team honest about the quality of the code and architecture throughout the development lifecycle. Using automation and tools such as SonarQube, CAST, Blackduck, or WhiteSource as part of the build system can help uncover hot spots.
Perhaps the most important aspect is a mature quality mindset prioritizing where to invest to help surface issues earlier and reduce the overall manual error-prone quality testing. For example, if a team has 100 tests, 90% should be upstream unit tests.
4. Strong Product, Sales, And Engineering Collaboration
A company led by a single discipline, regardless of which one lacks balance and faces risks. In start-ups or very small companies, all disciplines can be combined in one individual wearing multiple hats and this is a temporary exception.
In larger companies, the disciplines may be too distant and lack efficient collaboration, and forcing functions such as SAFe help to align priorities across large teams. In average size organizations, these roles are typically distinct and assigned to individuals.
Regardless of the situation, what’s important is that those disciplines collaborate and have a seat around the table without combining roles to avoid conflict of interest.
“Building The Right Thing” is typically the responsibility of the product team, and “Building Things Right” is the responsibility of engineering. A balance must be continuously maintained and achieved to minimize waste and ensure investments achieve what’s intended. Is it easy? Absolutely not. This requires healthy collaboration, leadership, and sound governance with checks and balances.
5. Excellent Agile Roadmap and Backlog Prioritization
The approach and mechanics of product planning and having a sharp and agile requirements process is a critical muscles for successful organizations. These provide guard rails to ensure the collaboration works and the prioritization is effective.
At the individual level, we spend most of our time trying to understand what others are trying to express or attempting to articulate our thoughts to be understood. In collaborating groups, those dynamics are magnified and directly proportional to the size of the group. It's no wonder the Dunbar 150 number became the essence of how efficiently companies and governments organize their teams. Establishing the collaboration needed for efficient agility requires time to be built-in in order to get requirements right.
6. You Must Evolve
“Evolve or perish” stories are numerous, but a personal favorite has been the Guy Kawasaki story of ice told so eloquently. Every product and service has to continuously evolve to accommodate changes in consumption, competitive forces, and technology. Technical debt presence gets in the way of the ability for the architecture to evolve.
Do We Have To Fix All Technical Debt?
Absolutely not! Continuously evaluating the backlog and technical debt items for relevancy is important. Use cases, products, requirements, and technology change constantly. Within each release and sprint planning, careful prioritization should be conducted and aligned with the product strategy.
Spotting Technical Debt Symptoms and Diligence Red Flags
Spotting technical debt may not be a big challenge in and of itself, even when attempts are made to hide it. It’s nice when things are transparent and when companies are aware of the shortcomings and have plans to address shortcomings in place. Some of the common symptoms include:
The inability of senior engineering team members to articulate it clearly
Lack of presence of technical debt artifacts in the product backlog
Lack of any mention in the roadmap
Immature prioritization process
Lack of ownership in architecture
Three Steps Determine The Cost and Address Technical Debt
This is the tough part and requires assessing the situation and understanding the root causes of the technical debt in reverse engineering mode. Organizations that are successful employ four steps to tackle.
Step 1 - Assess to understand the root causes and make a plan to eliminate
Step 2 - Understand the extent of the technical debt, identify and quantify it
Step 3 - Conduct prioritization sessions and estimate the rough size of each item
Step 4 - Include the items in the roadmap and a breakdown of the backlog
Take-Aways
Technical Debt is a real threat to businesses and especially tech-enabled companies, due to the lack of software development discipline and limited know-how. There are clear best practices and strategies to manage technical debt promptly before it becomes a threat to the business.
Download the technical due diligence definitive guide all you need to Know infographic.
#duediligence #techduediligence #technicalduediligence #technologyduediligence #diligencechecklist #softwarediligence #ringstoneduediligence #vddduediligence #vdd #valuecreation
About the Author
Hazem has been in the software and M&A industry for over 26 years. As a managing partner at RingStone, he works with private equity firms globally in an advisory capacity. Before RingStone, Hazem built and managed a global consultancy, coached high-profile executives, and conducted technical due diligence in hundreds of deals and transformation strategies. He spent 18 years at Microsoft in software development, incubations, M&A, and cross-company transformation initiatives. Before Microsoft, Hazem built several businesses with successful exits, namely in e-commerce, software, hospitality, and manufacturing. A multidisciplinary background in computer engineering, biological sciences, and business with a career spanning a global stage in the US, UK, and broadly across Europe, Russia, and Africa. He is a sought-after public speaker and mentor in software, M&A, innovation, and transformations. Contact Hazem at hazem@ringstonetech.com.