Designing Self-Critical Systems
How to Build Things That Last
Recently, Elon Musk presented an interesting idea when asked how he envisioned a political system on Mars (you know, once his fleet of spaceships will have sent enough explorers over there).
He proposed that laws should have expiration dates and, as a rule of thumb, it should be easier to get rid of a policy than to implement it.
On first sight that might be a strange thought. Nevertheless, let me explain why there is some very sound reasoning behind Musk’s proposal. To get there, we need to look at the bigger picture because his idea is only one specific measure to achieve what I call a self-critical system.
A self-critical system is a general concept I use. It is important if you aspire to design any kind of system with longevity in mind. Regardless if you want to build a company that lasts, develop a new constitution (don’t laugh!) or create the finance system of the future: Injecting self-criticism by design will likely pay dividends in the future.¹
The basic idea is simple: A self-critical system is a system that regularly and methodically challenges its properties as well as the underlying assumptions based on feedback from its environment, and initiates changes according to need.
Let me dive into the important bits.
Any system exists within a broader environment. If you develop a system today, say a company, you factor in that environment though usually subconsciously. Those are the _underlying assumptions_ on which your system is built.² For example, when deciding on your company’s communication structure, you do so based on the communication instruments that exist. This will impact the structure you choose. In a world of typewriters and letters a solution will differ from one in which the internet exists. There are many areas where such assumptions are usually made:
- Technology & Infrastructure
- Laws
- Public opinion
- Form of Government
- …
Of course, any of those environmental conditions are subject to change. Hence, regularly questioning the design choices based upon them is necessary to ensure your system’s properties are still in sync with the world.
Importantly, you shouldn’t leave that to chance. This is where the definition’s ‘regularly and methodically’ bit comes into play. While it’s not impossible a system without a dedicated mechanism for self-criticism changes over time, this depends on several factors you’d probably rather hedge against:
- Are the necessary changes in line with the decision-makers’ world-view?
- Are decision-makers sufficiently incentivized to make necessary changes?
- Do decision-makers identify the changed environmental conditions which call for changes within the system in the first place?
If you think about systems that already exist for a comparably long time you’ll realize they changed during their lifetime. Since few employ a mechanic for self-criticism you might conclude the answer to those questions is often ‘yes’. However, that’s a classical case of survivorship bias. Once you take all failed systems into account, it’s evident the answer is in fact mostly ‘no’. Hence, chances of longevity are small without regular and methodical self-criticism.
In practice, building self-critical systems translates to implementing clearly defined measures to continuously collect feedback from the environment as well as within the system, and thereupon challenge current structures and properties of the system as well as its purpose.
The important notion is that self-critical systems not only challenge what they do — which many regular systems are fairly good at — but also how and why they do things. It might sound obvious but in practice it’s not all that common. Let me give you an example.
In most companies, structure and key processes are a responsibility of top management. However, very few companies use a dedicated routine to reflect on them. And even if one does, several problems occur if management in a traditional organizational structure is in charge.
First, many issues arise at the bottom — where the actual work gets done — but never make it to top management (for instance because the middling management layers filter information).
Second, often the solution to a problem runs against decision-makers’ personal interest. For instance, I’ve been involved in several projects that proposed restructuring all customer-facing disciplines (e.g. marketing, sales, communications, customer care) into interdisciplinary teams responsible for customer journeys. In most cases clients decide against it or implement it only halfheartedly. Too many executives are afraid they’d lose their current influence.
Third, even senior managers are people. Thus, they come with their own set of experiences, believes and opinions. Contrary to popular management myth, these are very much subjective, prone to biases and error. If only a few people are able to make systemic changes and if necessary adaptions aren’t in line with their thinking, the system won’t adapt.
Of course, it’s not all bad. The concept of baking self-criticism into a system isn’t a new idea. Corresponding mechanisms exist in several real-world systems. I’ll go through a few examples I’m aware of.
The organizational system Holacracy has some good ideas to inject self-criticism into an organization. Most notably it employs a regular meeting routine called Governance Meetings. In Holacracy, every organization consists of several circles that are supposed to be as autonomous as possible. Every such circle holds regular Governance Meetings. These constitute a forum that invites every member of the circle to address organizational tensions s/he identified. A sleek moderation process (called Integrative Decision Making) ensures that reasonable changes to the system can be made quickly by every member of the organization.
Another example for self-critical systems can be found in software development: open source software. By open-sourcing software, every interested developer can look at the source code and either suggest or make changes to the system. In doing so, open source software — especially when it attracts a decent developer community — often has a pretty good code quality and can quickly adapt to changes in the software’s environment (e.g. new HTML standards, popular services that need integration).
The most persistent system is probably nature. It came up with a very nice mechanism for self-criticism we all know: pain. Pain is a direct feedback mechanism that signals when something wrong was done or done the wrong way. As it is the natural tendency of creatures to avoid pain, it is one of the most effective teachers. Of course this applies to both physical and mental pain. A related concept is posttraumatic growth. Psychologists use the term to describe that many people, after suffering through traumatic events, experience personal growth they often describe as “life-changing”. Humans, it turns out, are pretty capable at adapting.
When looking at Musk’s suggestion in that light, it’s just one mechanism to inject self-criticism into a system. As readers with a legal background will be aware of, laws with an expiration date are not a new idea. In fact, they are an available tool in many jurisdictions known as Sunset Provisions.
Neal Katyal, a Law Professor at Georgetown university and former Solicitor General of the United States, published an insightful paper (PDF) in the Notre Dame Law Review arguing for Judicial Sunsets. He writes:
“Alongside the structural and political forces for inertia lies the
obvious point that legislatures, composed of human beings, cannot
anticipate every problem and are likely to make mistakes.
…
The costs of this inevitable human error are therefore exacerbated
over time as bad or outmoded legislation stays on the books due to
inertia.”
However, because legal practice in the U.S. is guided by the principle of stare decisis — that is sticking with former decisions also known as precedent — Katyal concludes that “instead of using devices that minimize the impact of systematic mistakes as part of a broader architecture of justice, our judicial system has adopted a system to magnify it.”
The same can be said about many system architectures from all kinds of domains.
Given we are currently living through a chapter of history characterized by rapid change, volatility and thus uncertainty, stare decisis appears like a risky design choice. In a VUCA world, systems should be capable of dealing with an ever-changing environment and thus favor adaptability over stability³.
Building self-critical systems, therefore, is essential if the intention is to create something that lasts. While there are no guarantees for the latter — not even with systemic self-criticism — you can at least increase the odds.
I’ll tackle the specifics of designing mechanisms for self-criticism in an upcoming post. Make sure to follow me here or subscribe to my newsletter if you don’t want to miss it.
¹ I highlight the latter because it is explicitly a concept for the long-run. Short-term it might well cost a few percentage points of your efficiency. So, if longevity is not important for your system, never mind.
² While it would be useful to make them explicit, it’s likely unpractical in most situations as it would cost a lot of time. Being or becoming mindful of them later on is very important though.
³ Perceived stability, I should note, which is only short-term stability. Not changing a system gives you a sense of stability and security until it is so out of sync with the environment that it blows up. Nassim Nicholas Taleb makes that point in Antifragile, p.81: “Depriving political (and other) systems of volatility harms them, causing eventually greater volatility of the cascading type.”
This piece is an excerpt of a book I’m currently writing about decentralized systems. It’s an early draft. I intend to share some passages along the writing process. In the meantime, any feedback is much appreciated (I’m also grateful for reading recommendations)! If you have questions regarding the project please don’t hesitate to contact me.
About me
I work, think, write and speak about digital business, technology and decentralized systems. If you’d like to connect, follow me here on Medium, or check out my website to find out more. I’m always glad to talk & interested in inspiring discussions. My analog residence is Munich, Germany.
