Organizational Debt: A nasty off-balance-sheet liability
it has been said that organizational debt is like technical debt in software but worse: “Organizational debt is all the people/culture compromises made to 'just get it done' in the early stages of a start-up.”
“Just when things should be going great, organizational debt can turn a growing company into a chaotic nightmare. Growing companies need to understand how to recognize and “refactor” organizational debt.”
That was said in the context of organizational debt incurred by startups at the time of hiring lots of people as it prepares to grow. On the other hand, big established organizations incur organizational debt throughout the course of their existence. My book has this to say in the context of technology teams but it is applicable more broadly:
“IT organization design is rarely thought out from a baseline of principles. The prevailing design is mostly a product of happenstance, mergers or acquisitions, people-retention compulsions, and the ideas of whoever is in charge at various levels in the organization. It resembles how software accumulates technical debt over time unless we periodically step back and reassess the design.” - Agile IT Organization Design
And as with all debt that isn’t repaid on time, there's a price to pay. Unaddressed organizational debt results in silos, politics, unclear accountability, slow decision making and poor responsiveness to the market in general.
Just like household debt, corporate debt and sovereign debt; software technical debt and organizational debt tend to accumulate at different levels.
This has been the subject of several books. For instance, Tom Reiger, author of the book, Breaking the Fear Barrier, calls out parochialism, territorialism and empire-building as organizational barriers to agility and innovation. Parochialism prioritizes “local needs and goals” over “broader objectives and outcomes”. Territorialism is the “hoarding or micromanaging of internal headcount, resources or decision authority in an effort to maintain control”. Empire-Building refers to “attempts to assert control over people, functions or resources in an effort to regain or enhance self-sufficiency”. Left unattended, organizational debt grows like a silent cancer. It assumes the nature of a liability that grows without a mention in the balance sheet.
“Problems in organization design do not show up promptly in financial statements. Yet, in the long run, they have the potential to hurt business outcomes.” - Agile IT Organization Design
Servicing Organizational Debt
Although organizational debt is undesirable, we cannot avoid incurring some of it because ad-hoc restructuring and reshuffling of positions happen all the time at various levels of the organization. But we need to repay it soon because organizational debt upsets the balance of autonomy, alignment and accountability, and leads to silos and general sluggishness.
“While they are unavoidable, it is essential to step back occasionally and examine whether the reorgs have gone against the principles explained so far. Have we unwittingly created positions with unbalanced autonomy and accountability? Have we diffused outcome ownership or compromised the authority of outcome owners? Have we created activity-oriented teams? If yes, then, we have taken on organizational debt. We need a round of deliberate reorganization to repay this debt.” - Agile IT Organization Design
Of course, it’d be much better if middle managers and IT leadership were aware of good principles of org design even as they make their ad-hoc changes. For example, here’s a principle with regard to structure and an explanation of how it applies:
“Organize for responsiveness over cost-efficiency.”
Change in technology and business is the order of the day. To deal effectively with change, we need a responsive organization. Responsiveness is about being time-efficient rather than cost-efficient. In times of rapid change, it makes sense to trade-off cost-efficiency for time-efficiency. Probably the biggest example of this trade-off is in moving from mono-functional, activity-oriented teams to cross-functional, outcome-oriented teams. The latter may turn out to be less cost-efficient because utilization of full-time specialists in a cross-functional team is likely to be less than that in a mono-functional setup. But they can deliver value to market with much shorter cycle times.
Cross-functional teams need autonomy and minimal dependencies with other teams in order to be responsive to external needs. The outcomes that they are responsible for thus need to independently achievable and valuable to the business. Poor allocation of outcomes will contribute to organizational debt. This is somewhat similar to the single responsibility principle of software design.
On the other hand, runaway autonomy can lead to silos, which are another type of organizational debt. To guard against this, we need robust mechanisms for ensuring alignment and accountability for business outcomes. Some say agile and accountability don’t mix because agile is all about collective ownership. That notion arose in the context of ownership of a team's codebase. Collective ownership of business outcomes is far more difficult to achieve than collective ownership of code within a team.
Business decisions that are meant to be made collectively often get bogged down in differences of opinion or get stuck because no one is willing to step forward and take a call. It’s not a good example of organizing for responsiveness. Besides, even in cases of collective code ownership, the practice of continuous integration provides for unambiguous accountability when the build breaks. Diffusion of accountability makes for dysfunctional organizations with lots of people claiming authority and few signing up for accountability.
Does Self-Management Help?
Advocates of self-management claim that it helps deal with organizational debt by reducing hierarchy. I haven't found this to be true in non-trivial scenarios. Dysfunctions of hierarchy do contribute to the problem, but I'd recommend Cleararchy to deal with it.
To sum up, a human organization accumulates organizational debt much as software accumulates technical debt over time. Although this debt is non-financial and invisible in the balance sheet, it has the potential to undermine business outcomes. It is therefore important to periodically reassess organization design from a baseline of principles and repay the debt with deliberate changes to the design.