From Technical Debt to Organizational Wealth
Why technical debt exists, and how to reach organizational wealth instead
Why technical debt exists, and how to reach organizational wealth instead
Overview
Technical debt is a term coined by Ward Cunningham, who explained internal quality issues in software as a debt paid later with interest when building new features, for example. I can think of other types of debt an organization has that are not financial — in risk, security, work process, tools, and knowledge.
In this post, I will discuss technical debt, the forms it can take, what organizational wealth looks like, and recommendations on how to reach there. I will use the term tech debt and org debt interchangeably to amplify the different forms such debt can take in an organization.
What is organizational debt?
Broadly, organizational debt delays the delivery of value to customers. It can be anything from inefficient processes to obsolete software or unused space.
If you feel the burden of manual work, unstable systems, unclear processes, too many meetings and clarifications required, and insufficient knowledge — these are all possible signs of tech debt.
The lifecycle of debt can look like this -
The company introduces a new “feature” — like a new policy for time off.
The procedure is documented in the HR manual and explained to the employees.
With time and after getting feedback, adjustments are made to the policy.
At some point, the owners stop documenting the changes, and the HR manual becomes outdated.
As changes grow, employees lose trust in the manual and start asking more questions.
As the original policy creator leaves the company, the process relies heavily on informal knowledge that only a few have.
The company wants to revamp the time-off policy and needs to know where to start.
While it doesn’t clarify what tech debt exactly is, the example helps us understand its implications. Much like debt, if kept unmanaged, it grows and accumulates the impact on the ability to deliver value.
Is debt a bad thing?
No! If you could take a loan with a 4% interest rate and invest it in a project that yields a 10% profit rate, would you take it? You probably would, even if it means you increase your debt.
However, here lies the catch, increasing org debt is for future ROI. Here are some examples -
Work in a small open space and shift to work from home to move to a larger area later.
Accept a known security vulnerability to focus on infrastructure updates that will allow mitigating the risk in the future.
Keep an acquisition deal at risk still open to attract public interest and leverage the exposure.
Update internal procedures online without keeping documents updated so the team can invest time in building new manuals.
Add a new feature to the system to capture growth and revenue that will allow investment back in the system improvements.
Invest manual work in financial reporting alignment until a new financial ERP is purchased.
In other words, tech debt is something that an organization decides to increase to achieve short-term goals, with the expectation to invest the benefits in the long-term goals.
Focus on organizational wealth
It is a common practice in Product Management to start at the end — what is our end goal? What is the victory picture of what we’re doing? One famous way of practicing it is Amazon’s internal press release — written before product development starts.
Applied to tech debt, start with where you want to get. Let’s take another look at the example above -
Move to a larger area where everyone has a place and shared space.
Have the appropriate infrastructure to mitigate upcoming risks.
Gain public exposure to support the growth strategy.
Have up-to-date manuals on company procedures.
Have clean, reliable, and sustainable working software.
Adapt a new financial ERP that eliminated most of the manual work.
That’s organizational wealth; that’s where you want to be. It also allows you to deliver value faster to your customers — which is the end goal.
When the “debt” question comes, we need to weigh the options — should I increase the debt and impact my capabilities for this new opportunity? Is the ROI worth it?
Practical bits of advice
With the end goal in mind, here are a few ways to reach there. First and foremost, gain buy-in. Talk about the benefits of org wealth and how to decide carefully on tech debt accumulation.
Second, keep it managed. We agreed that debt is not harmful unless left unmanaged. When accumulating or dealing with existing debt, we must set the time to pay for it. For example, release the “quick-and-dirty” feature but set the plan to refactor it one month from now.
Third, measure it. How much time will be lost on manual work? How much code will need to be refactored? What expenses will we have, and for how much time? What are the possible risks and their occurrence rate? If we can automate 20 hours of manual tasks a month, which costs $1000, with a tool that costs $3000 a year — the ROI is clear and realized after three months.
Last is doubt. Always look for a better alternatives, ways to improve efficiency, and reduce debt. Doubt the process, tools, expenses, processes, and more. Sometimes the debt is unnoticed, and it needs to be uncovered.
Conclusions
A company’s goal is to deliver value to its customers. Tech debt might come in the way of that but is expected to have a higher ROI later. To deal with it, focus on the desired state — the organizational wealth — and lead the way to this state.