Context: The previous post gave a long list of examples of just-let-go design: a problem-solving approach/aesthetic based on giving up direct control over the system. In this post, we’ll talk about the first of several reasons why we’d want use just-let-go design, as a strategy in itself.
Compared to railroading-style direct control, just-let-go solutions generally require a deeper understanding of the problem.
If we want to build a platform to support all kinds of different programs, or a sandbox to support many different kinds of players, then we need to understand our players/programmers and their goals in some detail. By comparison, railroading players requires little understanding of the players themselves.
The economic examples make the difference even sharper. Anyone can pass a law which makes it illegal for car-sellers to lie about their car. Building a system in which sellers are no longer incentivized to lie about their car requires more thought.
The car-seller example brings up another point. Suppose we do make it illegal for car-sellers to lie about their car. What will happen? Well, people will probably just work around it. Without modifying the incentives, we haven’t fixed the root cause, and the problem probably won’t go away. The point: direct control solutions don’t actually remove the need for understanding the problem. Using direct control without understanding the problem will usually just break things.
Looking back over the examples makes this clear. A game railroads the players too much? The players get angry and leave. An app railroads the users too much? The users get bored and drop off. Price controls? Classic example of unintended side effects. Poorly thought out incentives? Another classic example of unintended side effects. Even when writing code, programmers are advised to trust the compiler for basic optimization, rather than try to do it themselves.
Just-let-go solutions, on the other hand, are hard to even think about without understanding the problem. We want to lower prices without instituting price controls? We’re immediately forced to think about the root causes of high prices. Now, that doesn’t mean our understanding will be correct. We could still be wrong. But at the very least, we are definitely forced to think about the problem.
That’s one major advantage of just-let-go solutions: they don’t give us a choice in whether to think about the problem structure. We’re forced to think about it.
Heuristic: Maximize Loss of Control
The strict need for understanding in order to build just-let-go solutions leaves them out of reach for most people most of the time. Direct control gives someone who doesn’t understand the system a way to do something. Even if it creates unexpected problems, the person can shrug and say “well we tried, the world is complex, sometimes unexpected problems pop up”. Then their boss, who presumably also does not understand the system very well, will nod along and say “yup, guess we’ll just have to patch this new problem too.” Commence whack-a-mole. All without anyone understanding the system, or even realizing they don’t understand.
On the other hand, if we go out of our way to design a just-let-go solution, then we’re forced to think about the system in depth. We have to consider the players, the rules, the goals, the information flows, the bottlenecks, the incentives, and so forth. Even though the final product may be simple, we have to understand the details of the system.
This leads to a useful heuristic: design to give up as much control as possible.
Maximizing loss of control forces us to maximize understanding. The better we understand the system and the problem, the less we’ll have to rely on direct control to implement a solution.
But understanding is hard to observe. I can’t tell just by looking how well you understand a problem. I can tell by looking how much control you’re giving up in the solution. Similarly, I can’t just ask you to go understand the problem—neither you nor I can directly measure how well you’ve understood it. But if I ask you to generate a minimum-control solution, that will measure how well you understand the problem, across a wide variety of fields. Minimum-control becomes a visible signal of understanding.
On the other hand, low-control solutions also tend to be low-complexity solutions… so why not just use that as a visible signal of understanding? More on that in the next post.
Letting Go II: Understanding is Key
Context: The previous post gave a long list of examples of just-let-go design: a problem-solving approach/aesthetic based on giving up direct control over the system. In this post, we’ll talk about the first of several reasons why we’d want use just-let-go design, as a strategy in itself.
Compared to railroading-style direct control, just-let-go solutions generally require a deeper understanding of the problem.
If we want to build a platform to support all kinds of different programs, or a sandbox to support many different kinds of players, then we need to understand our players/programmers and their goals in some detail. By comparison, railroading players requires little understanding of the players themselves.
The economic examples make the difference even sharper. Anyone can pass a law which makes it illegal for car-sellers to lie about their car. Building a system in which sellers are no longer incentivized to lie about their car requires more thought.
The car-seller example brings up another point. Suppose we do make it illegal for car-sellers to lie about their car. What will happen? Well, people will probably just work around it. Without modifying the incentives, we haven’t fixed the root cause, and the problem probably won’t go away. The point: direct control solutions don’t actually remove the need for understanding the problem. Using direct control without understanding the problem will usually just break things.
Looking back over the examples makes this clear. A game railroads the players too much? The players get angry and leave. An app railroads the users too much? The users get bored and drop off. Price controls? Classic example of unintended side effects. Poorly thought out incentives? Another classic example of unintended side effects. Even when writing code, programmers are advised to trust the compiler for basic optimization, rather than try to do it themselves.
Just-let-go solutions, on the other hand, are hard to even think about without understanding the problem. We want to lower prices without instituting price controls? We’re immediately forced to think about the root causes of high prices. Now, that doesn’t mean our understanding will be correct. We could still be wrong. But at the very least, we are definitely forced to think about the problem.
That’s one major advantage of just-let-go solutions: they don’t give us a choice in whether to think about the problem structure. We’re forced to think about it.
Heuristic: Maximize Loss of Control
The strict need for understanding in order to build just-let-go solutions leaves them out of reach for most people most of the time. Direct control gives someone who doesn’t understand the system a way to do something. Even if it creates unexpected problems, the person can shrug and say “well we tried, the world is complex, sometimes unexpected problems pop up”. Then their boss, who presumably also does not understand the system very well, will nod along and say “yup, guess we’ll just have to patch this new problem too.” Commence whack-a-mole. All without anyone understanding the system, or even realizing they don’t understand.
On the other hand, if we go out of our way to design a just-let-go solution, then we’re forced to think about the system in depth. We have to consider the players, the rules, the goals, the information flows, the bottlenecks, the incentives, and so forth. Even though the final product may be simple, we have to understand the details of the system.
This leads to a useful heuristic: design to give up as much control as possible.
Maximizing loss of control forces us to maximize understanding. The better we understand the system and the problem, the less we’ll have to rely on direct control to implement a solution.
But understanding is hard to observe. I can’t tell just by looking how well you understand a problem. I can tell by looking how much control you’re giving up in the solution. Similarly, I can’t just ask you to go understand the problem—neither you nor I can directly measure how well you’ve understood it. But if I ask you to generate a minimum-control solution, that will measure how well you understand the problem, across a wide variety of fields. Minimum-control becomes a visible signal of understanding.
On the other hand, low-control solutions also tend to be low-complexity solutions… so why not just use that as a visible signal of understanding? More on that in the next post.