Samuli Hokkanen

My first business card years ago read “Web Developer”. Over time, my job has shifted through commercial roles to business development and later to management and C-level roles, but I still find myself frequently revisiting certain software development paradigms and basic concepts in my daily life. I decided to introduce a few such concepts used by developers, which I keep returning to and believe should be more widely utilized in organizational management. First and foremost, it’s necessary to write about technical debt.

Technical Debt

In software development, the concept of technical debt is used. Technical debt is incurred whenever a quick and “temporary” fix is made, something is left undocumented, testing is not thorough, or savings are made in planning. Technical debt also accumulates over time as the surrounding technology evolves. Technical debt always comes due at some point and must be paid down if the whole is to remain viable. If technical debt has grown too large, costly comprehensive reforms are often on the horizon. Recognizing and managing technical debt is sensible.

Justifying the reduction of technical debt amidst all development is challenging: why spend time or money right now on renovation work or code refactoring that doesn’t immediately translate into fresh revenue?

“Organizational Debt” is the Flip Side of Technical Debt

Borrowing concepts from software development, I think management work should talk about organizational debt. Organizational debt also grows whenever:

A quick fix or exception is made for some work community-related issue. The organization’s next steps are not systematically planned or its architecture’s suitability for current or future operations is not assessed. Continuous maintenance and development of the organization are neglected. Organizational debt also inevitably comes due – at its worst, it manifests beforehand as unprofitability, high turnover, and just plain bad morale.

The challenge of paying off organizational debt is the same as with technical debt – why spend time and money right now on something that doesn’t immediately increase revenue or profitability?

Thermodynamics, Thermodynamics!

The solution to willingness to pay, both for technical and organizational debt, lies, I believe, in realizing the same fact: the disorder of a closed system increases (physics nerds in the back row already recognized the second law of thermodynamics!).

Organizational debt and technical debt are disorder and are managed by maintaining the system. Debt must be paid and, above all, managed. If nothing is done, things will surely deteriorate.

So, what lessons would I plunder from software development to manage organizational debt and disorder?

At least the following:

• Organizations, like software, have a lifecycle that can be planned and influenced. What size community can the current structure support? What is needed for us to grow? Can I already identify future bottlenecks?
  
• Architecture matters, but execution is key. An organizational chart is meaningless if it doesn’t translate into practice.
  
• Often, small reforms are sufficient. Neglecting reforms erodes operational capacity, making future reforms more difficult.
  
• Sometimes comprehensive reforms are needed.
  
• It’s best to forget about quick fixes and exceptions.
  
• (And it’s not advisable to deploy anything into production on fridays – be it technical or organizational)