Managing Technical Debt is critical: About the Technical Balance Sheet and the Technical Profit / Loss Statement

Most companies have limited resources and need to optimize them regularly. Technical debt is a resource that influences time-to-market, productivity, employee satisfaction, etc., but it is often not managed well.

This article will discuss an innovative way of managing technical debts efficiently and aligning among non-technical stakeholders. We will do so by answering the following questions:

• What is Technical debt? Why is managing Technical Debt critical?
• How to visualize and manage Technical Assets and Debts?
• How can I create my Technical Balance Sheet (TBS) and the Technical Profit & Loss Statement (TPL)?

What is Technical debt? Why is managing Technical Debt critical?

Technical debt is comparable to financial debt. Considering the analogy of buying a house, one can take on debts to gain more buying power. However, each debt comes with interest rates and payback schedules. In addition, financial wealth influences the type and amount of debt we can/should take on and the interest rate until we pay everything back. Over-taking debt creates an inability to enjoy other parts of life. Under-taking debt means we might miss out on optimizing our finances (tax benefits, hedging against inflation, etc.).

Software development is very similar. When we create a new product functionality, a new process, hire new people, etc. (i.e., creating an Asset), “delivery, quality, and cost” have to be prioritized against each other. That is where technical debt becomes useful. To decrease the time to market, hire people faster, increase revenue, and grow the business as quickly as possible, we create new Assets while taking on Debts, i.e., accepting “intentional” shortcuts and imperfections. Each Technical debt has its interest rate (i.e., lost productivity).

The accumulation of Technical debts and not managing a healthy payback can cause various issues: longer development and delivery time, more working hours, key people leaving because of stress, etc. It can even threaten a business’s existence when high-priority compliance or security risks are — or can — not be addressed.

How to visualize and manage Technical Assets and Debts?

There are different methods to manage Technical debt, but most focus only on the system and are difficult to understand for non-engineers.

The Balance Sheet and the Profit & Loss statement are widely used tools in finance for providing a picture of the health of a company and prioritizing investments. Therefore, similarly visualizing Technical assets and debts is an effective way to align all stakeholders, which is critical to managing debt holistically. The goals of the Technical Balance Sheet (hereafter TBS) and the Technical Profit & Loss Statement (hereafter TBL) are the following:

• Monitor and optimize overall value creation
• Evaluate and optimize the efficiency/productivity of the organization
• Manage and reduce risk
• Communicate effectively among all stakeholders

Technical Balance Sheet (TBS)

The TBS contains a holistic visualization of all categories relevant to Software development: product (or system), process, people, and other tangible and non-tangibles, including compliance/security/risk aspects.

Each item is calculated in a common unit to visualize and compare the order of magnitude of Assets and Debts. A good unit could be “the man-hours (or velocity) consumed or to be consumed to create/address X”. For example:

• Code Debt = Amount of man/hours needed to repay the whole code debt
• People Debt = Amount of man/hours required to fill the necessary skills (incl. hire and onboarding for positions X)

Hint

Money can also be used as a common unit. This might be easier to understand for non-technical stakeholders but can create confusion or tensions with engineers. Therefore, I suggest using “man-hours” or “velocity” and considering it as the unit of production that can be linked to the financial balance sheet.

Technical Profit & Loss Statement (TPL)

The TPL summarizes the created value and expenses incurred during a specified period, usually a quarter or fiscal year. It provides information about the ability or inability to efficiently generate value and manage Technical debt.

Inspired by traditional financial ratios, here are some example metrics that can be used to monitor, optimize and prioritize based on the TBS and the TPL:

• Debt-to-Equity Ratio (D/E) (formula: Liabilities/Equity)
  This ratio indicates how much of the work performed in total is technical debt. The smaller the ratio, the more “value work” has been completed without taking on debt. Overleverage (>100%) means that the company is not managing debt sufficiently and has a risk of decreasing productivity further in the mid-to-long term.
• Expenses-to-Income Ratio (formula: Total Expenses/Total Income)
  This ratio measures how much of the work performed for a specific period is technical debt. It also indicates the ability to repay existing debt. A low ratio suggests that little additional debt is created and that there is a sufficient ability to repay existing debt. Increasing the ratio means creating faster value in the short term, but the created debt must be repaid mid-to-long term. In most cases, a ratio of less than 25% is recommended.
• Return on Equity (ROE) (formula: Net income/Equity)
  This ratio measures the ability to create value by managing efficiency and productivity. A high or growing ROE means the company is more efficient and productive. Less than 10% indicates low productivity. Productivity should be increased for early ventures since the product is less complex and has less debt.

How can I create my Technical Balance Sheet (TBS) and the Technical Profit & Loss Statement (TPL)?

This paragraph illustrates the TBS and TPL based on an example use case.

Context of Example Company

• The engineering organization grew in 5 years to 50 engineers. 20 engineers have been hired in the last year.
• In the beginning, time-to-market was crucial. Therefore many functionalities have been developed as fast as possible. The absence of documentation of critical business flows makes planning new developments increasingly complex and time-consuming for engineering and non-engineers.
• The first engineers were “rockstar”-like engineers. The code is written well, and the architecture is solid, but the technology used has a steep learning curve, especially without an appropriate onboarding process. Also, the technological environment has changed, and hiring skilled engineers has become more difficult.
• Compliance and regulation checklists show some significant data privacy risks. Also, a recent security check discovered high-security risks in external libraries that are not current.
• The above situation impacts the engineers’ morale, and the management feels that the time-to-market is too slow.

Visualization in a TBS and TPL

Since the company didn’t manage technical debt in a balance sheet, it created the initial TBS in the following way:

To have accurate numbers, the company created an estimated inventory of all items containing work — without using past or fake numbers.

• List all working tasks (exhaustivity was more critical than equal item size)
• Estimate all items (in a rough estimation)
• Label the items as Equity/Debt (Equity are items that produce assets when completed; Debt are items reducing tech debt)
• Label all items according to the Technical Debt Ontology
• Report the numbers to the TBS and make sure that Assets = Debt + Equity

Hint

If the organization follows Scrum, the above process should be included into the Backlog Refinement.

Technical Balance Sheet

Hint

People debt can occur when a role is filled by someone not matching the required skills (e.g., when hiring a software engineer instead of a Data Scientist). That leads to training, additional supervision, help from team members, etc., for a given time. The difference between the required skill and the actual skills is considered debt. People debt can generate interest in the form of team productivity loss.

Process debt can, for example, occur when an early venture decides not to implement a necessary process but to “postpone” the implementation to a later growth stage (e.g., before IPO).

Not all type of debt generates interest. Interest is the loss of productivity, overhead, etc., when repaying the debt later instead of now.

Technical Profit & Loss Statement for the upcoming quarter

Based on the TBS, the company decided to manage and repay debt rigorously. The following target TPL (period: half a year) highlights this.

We can see that the Return on Equity ratio is 55% (33 / 60), and the Expense-to-Income Ratio is 18% (7 / 40). Both ratios are in a healthy range. If this P/L can be achieved, the expected Debt-to-Equity Ratio (formula: (Current Debt + Expenses)/(Current Equity + Net Profit)) will be 94% (80+7)/(60+33), which is an improvement of 39% and leads the company to a healthier situation.

Further considerations

We didn’t discuss the " risk " aspect for simplicity in this article. However, risk management is crucial in finance, project management, and software development. Risk management can, for example, be achieved by creating different scenarios to “stress-test” the TBS or introducing an “Insurance” category.

Conclusion

Managing technical debt is a critical resource that influences time-to-market, productivity, employee satisfaction, etc., but it is often not managed well.

There are different methods to manage Technical debt. However, most of them focus only on the system and are difficult to understand for non-engineers. Therefore, this article discusses how to visualize and manage Technical assets and debts using a Technical Balance Sheet and Technical Profit/Loss Statement. The explained process facilitates managing technical debts efficiently and aligning with non-technical stakeholders.

References

1. ARMELIN, Bill. “A FINANCIAL ANALOGY FOR TECHNICAL DEBT”, AKF Partners, 12 October 2018, https://akfpartners.com/growth-blog/understanding-techical-debt
2. N. S. R. Alves, L. F. Ribeiro, V. Caires, T. S. Mendes and R. O. Spínola, “Towards an Ontology of Terms on Technical Debt,” 2014 Sixth International Workshop on Managing Technical Debt, Victoria, BC, Canada, 2014, pp. 1–7, https://www.researchgate.net/profile/Rodrigo-Spinola-2/publication/286010286_Towards_an_Ontology_of_Terms_on_Technical_Debt/links/5e83390f299bf130796af5c4/Towards-an-Ontology-of-Terms-on-Technical-Debt.pdf
3. TAEKUCHI, Shin. “CTOの頭の中：技術を財務で表現する”, 6 February 2020, https://note.com/singtacks/n/nb7a63ad40c17