My recent adventures with my local utility offered up some great lessons on system failure, design, and purpose. I’ve jotted them down here as hunches to look back on rather than a epiphany of understanding.
Failure
Systemic failures can and will happen. They will happen often and their occurrence is an excellent opportunity to better understand your systems and the things that system is interacting with. Elimination of failure is impossible and probably unhealthy. Not learning from it is irresponsible and undoubtedly inefficient. Also, failure is subjective. What might look like massive failure to one participant in the system maybe be inconsequential to the rest of the system and vice versa.
Design
Systems design should never have compliance as an objective. Compliance is a condition. Designing for base targets turns a system inwards as opposed to inspiring it to grow and contribute. Designing for purpose and even tangential goals might produce unexpected gains, quite possibly from the failures it produces. The design should go further to anticipate those failures, make them small and handle escalation of failure iteratively to do everything possible, not just the minimum required to avoid massive failure from the perspective of any participant in the system. And finally, people are a valuable part of any system. Our capacity to process patterns and complexity is unparalleled. Designing them out of the system can actually decrease efficiency and efficacy.
Purpose
Like any system, it’s purpose and patterns permeate it’s entirety. Purpose should be productive and pull the system forward. It is its reason for being. When system designers lose their sense of purpose and instead boil, or allow a system to be boiled down to a spec list it will all but guarantee a lifeless system. The system may well meet the criteria of the project, but it will have lost the greater purpose it is there to fulfill.
In my recent experience, a system failure on my end collided with a system failure in a regulated utility. On my part I relied on more signal than I was getting from the utility. On the utilities part, they relied entirely one communication channel (on-bill messaging), the minimum required by law. They failed to use multiple failure signals (un-paid bills), or changes in patterns corresponding to changes in systems, or their in the street people with a relationship to the customer, to stop the repeating failure. Instead they allowed the system to escalate to a costly and inconvenient option of physical gas disconnect, something that could have been avoided with an email, mailer, phone call, or on door notice… all which would have cost the company far less and allowed a customer relationship to be fulfilled.
Why it happened I suspect has to do with an image of a customer as a switch as opposed to a human. As a regulated utility with monopolistic privilege it is understandable to see how this might develop, and it is likely an expression of the nature of the current purpose of the organization. From my perspective, it sure seems to make sense and whether it is indeed true or not, it is how I will perceive and express those perceptions of that utility. And that’s my final lesson… if the purpose of the system is subjective, and if purpose permeates systems, the failures of a system could have disproportionately large influence on the ultimate purpose of the system… so design with purpose, design for failure, and design with care.