Over the past two decades, software engineers have coined phrases like “technical debt” and “design debt” to represent various aspects of a software system that, with neglect and over time, can result in progress being crippled under the burden of the debt load.  Ward Cunningham, a prominent computer programmer, described the concept well in 1992:

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation,object-oriented or otherwise.

This analogy’s message crosses disciplines quite well and very much applies to organizations and teams.  The notion of “organizational debt” is one we can all relate to seeing in the corporate world.  Here are examples of such debt:

• Duplication Debt: Over time, individual teams decide to build specialized roles to meet gaps in their workflow so as to remain independent of other teams.  E.g., everyone needs an ‘analyst’ so each creates that roles in their organization.
• Ambiguity Debt: Over time, with departments merging and splitting, some organizations are left with substantial ambiguity in roles and responsibilities of the people in them.
• “Should’ve-Fired-A-Long-Time-Ago” Debt: I’ve long said, “buying (a house, a car, …) is so much more fun than selling.”  Likewise, hiring a candidate is so much easier than firing an employee.  For that reason, without proactive, diligent management of talent, over time, organizations can be filled with people who really shouldn’t be there but who are perpetually on “verbal warnings/plans” and “will have to be dealt with at some point.”

Organizations do all of these things unconsciously and thus build an ever-mounting organizational debt obligation that slowly brings it to its knees:

1. Ambiguity & duplication lessen performance & efficiency: tensions between organizations are frequently a result of organizational ambiguity that creates “gray areas” of responsibility where both teams are somewhat but not completely responsible with no black line delineating between the two.  Duplication of roles across organizations can also result in similar competition between analogs and, aside from the ineffective use of payroll dollars, and ultimately cause depleted operational performance.  The only solution is to constantly “refactor” (another software engineering term) organizations to ensure rationale and clarity.  The trick is to do this on an on-going basis to constantly ensure that duplication debt and ambiguity debt never gets too overwhelming.
2. Weak leaders drive even weaker individual contributors: we frequently forget that allowing less-than-capable or less-than-engaged leaders to exist has a compounding downstream effect on the teams those leaders lead.  What’s worse is under-performers also impact the motivation and productivity of their colleagues who are frustrated that their hard work, in their minds, isn’t perceived any differently than the under-performer who is allowed to continue being part of a team.  Clearly, not dealing with this sort of debt is crippling to organizational effectiveness and engagement. 
3. Trust in senior management is inversely proportional to the amount of organizational debt that exists: our teams expect us as senior managers to manage the tensions and dysfunction that result from organizational debt.  Their trust in management is very much a function of their belief that their leaders not only see the debt, but are able to swiftly, objectively, and fairly deal with eliminating it.

As leaders, we must ensure our companies remain “organizationally solvent” paying off organizational debt as we incur it.  While organizational solvency doesn’t guarantee company success, not having it makes success implausible.