On Zen & Organizational Debt

As organizations scale and mature, we’ve often encountered that they develop structures, policies, and rules appropriate for their maturity, optimizing for the exploitation of their existing value streams to deliver product to customers. Usually, these various policies and processes are justified, and well-intentioned compensating controls put in place to mitigate constraints of the existing operating model or to address risks or uncertainty in the system. 

Overtime, however, the accumulated decisions related to these policies and processes become organizational debt, inspired by the term first proposed by Ward Cunningham when he coined 'technical debt'. These can be treated as a form of debt because as an organization, these compensating controls from a past operating model are borrowing against the future agility of the organization, and the interest payments come in the form of decreased feature throughput.

I’m reminded of an old story I heard in the dojo when I was studying martial arts. An old Zen monk and his apprentice were traveling together along a mountain road from Osaka to Kyoto. At one point, they came to a rushing river with a strong current. As the monks were preparing to cross the river, they came across a young woman who asked if they could help her cross to the other side.

Without a thought to the vows the monks had taken, the older Zen monk picked up the woman, carried her across the river, placed her gently on the other side, and carried on his journey to the monastery.

The young apprentice couldn’t believe what had just happened. Hours passed without a word between them. Finally, the younger monk couldn’t contain himself any longer, and blurted out “Master, as monks we are not permitted to ever touch a woman, so how could you carry that young woman on your shoulders across the river?” The older monk looked at him and replied, “Brother, I set her down a long time ago. Why are you still carrying her?”

My colleague, Ross Beurmann, and I faced this challenge recently while leading a transformation in a large enterprise within a heavily regulated context. We had designed a future state operating model including governance, structure, and metrics for the new system of delivery. We had pulled all the subject matter experts and key stakeholders together into cross-functional, cell-based structures aligned to value streams. The next step was “running water through the system,” - by which we mean running requirements through the system of delivery to measure flow. This allowed us to identify all the various policies, processes, and governance bodies that were no longer fit for purpose or fit for use in the new system. They had become debt on the product organization’s ability to prioritize value for the customer.

Our next step was to work with various stakeholders we had placed “on the teams”, to identify and classify those various compensating controls and create a plan to design their intent (what outcome they were meant to achieve), into the new flow-based governance model. Finally, through the use of acceptance criteria in a portfolio Kanban board, we refactored those processes or governance committees that no longer served a useful purpose in the new system.

While simple in theory, it was by no means an easy task. That intervention and refactoring alone, was able to contribute towards a significant increase in the due-date performance of one particular value stream. Those recovered cycle times then became available to add a synchronization buffer at key points in the value stream according to Eli Goldratt's Critical Chain Project Management.

As the old Zen monk said to his young apprentice, “why are you still carrying her?” To achieve the desired outcomes of business agility, it becomes necessary for us to address organizational debt, or ‘refactor the code’ to receive the benefits of a new agile operating model.

Organizational debt represented by the policies and processes meant to mitigate the impediments of the old operating model become context-free constraints on the flow of value in the new system. Once you’ve elevated the constraint, you must remove policies which might create inertia or backsliding into business-as-usual. This “debt” needs to be identified, prioritized, and designed out of the new system to reap the benefits of increased throughput of product to customers and value to the business.