After a serious outage, a company gathers everyone who touched the system. The timeline is reconstructed, action items are assigned, and a careful document is filed. Six months later, another outage follows the same shape. The first meeting produced a report. It did not necessarily produce an organization that learns.
An organization improves recursively when experience changes the machinery of collective improvement: who receives information, how decisions are reviewed, which experiments are permitted, and how lessons survive the people who learned them. This is harder than changing software because the “system” is made of people who interpret the rules and adapt to being measured.
Learning has to travel. An organization’s lesson is only as durable as the practices, incentives, and relationships that carry it. Photo by Compagnons on Unsplash
Many minds, several objectives
Software components don’t usually care whether a patch makes them look bad. Employees do. Teams have local goals, managers have budgets, executives have time horizons, and customers experience consequences that may never appear on an internal dashboard. A change that helps one part of the company can impose a cost elsewhere. By the time the cost becomes visible, the decision makers may have moved on.
Chris Argyris distinguished correcting an error within existing policies from questioning the policies themselves. His account of double-loop learning names a central organizational difficulty. A factory can push harder to meet its production target, or ask whether the target is causing defects to be hidden. A support team can answer tickets faster, or question whether speed is being purchased with unresolved problems.
The deeper loop is uncomfortable because it exposes the rules and interests behind the rule. If promotions depend on a number, the people being measured will sensibly learn how to improve the number. The organization then receives cleaner dashboards and poorer information.
A process designed to improve the organization becomes bureaucracy when preserving the process displaces the purpose it was built to serve.
Memory that can act
Organizations need ways to carry learning across time. Checklists, training, decision records, operating procedures, and shared tools can preserve a lesson after its original witnesses leave. A good incident review changes code or procedure and also improves the conditions for the next review: better telemetry, clearer ownership, safer reporting, and a habit of examining causes without inventing a single villain.
Yet institutional memory can harden into institutional inertia. Every old failure can add an approval step until no one can change anything without a meeting. Rules remain after their environment disappears. New employees learn how to route around the official process, so the written organization and the real organization drift apart.
Ask what the rule remembers
Before removing a cumbersome practice, find the failure that created it. Before keeping it, ask whether that failure is still likely and whether the practice still prevents it.
Healthy recursive improvement therefore needs deletion as well as accumulation. Procedures should have owners, reasons, and opportunities for review. Small experiments make assumptions testable. Local authority lets people closest to a problem act on knowledge that never reaches the executive level, while shared constraints prevent a local gain from becoming a global loss.
No organization sees itself completely. Reports compress reality; incentives alter what gets reported; delayed outcomes blur cause and effect. The best it can do is build several paths for inconvenient information to travel, make reversible changes where possible, and protect the people who reveal that a favored improvement isn’t working.
The company that learns isn’t the one with the longest handbook or the busiest retrospective calendar. It is the one whose people can turn experience into changed practice, then question that practice without having to deny the lesson that created it.