No one ever called me to make their process more fragile. They want their process strong, robust and able to handle anything. Here’s the problem with that approach. If you believe your process can handle anything, then it will right up to the point where the problems are so large that they finally break the process. By then, the problem is too large to solve easily or rapidly.
Consider building a small bridge over a stream. Make one bridge out of intertwined twigs, easily broken individually. The other is made from one much larger, much stronger, log. If both structures have good integrity, that large, strong log seems better. But what if there are some problems. The bridge made from twigs will generate its first cracking sound, and before the rest of the structure collapses, you are able to get to safety. But the log goes suddenly with one loud crack, and you end up hurt and wet at the bottom of the stream.
When you design your process to be fragile, it breaks early but small, and then you can fix it early but small.
Just-in-time pull systems in manufacturing are one example. Inventory is there to absorb problems. When you reduce inventory, small problems will disrupt the flow easily. It doesn’t matter whether the problem is cycle time variation, downtime or something else. As soon as the problem surfaces, the process will be interrupted. This allows you to respond to the problem while it is still a small problem, and do so quickly.
In a product development team, most controls involve gates, review meetings and templates. But the important connection is resource to resource, such as one engineer trying to integrate a system design with another sub-system engineer. It is difficult to just trust that those two engineers will cooperate and serve one another. We prefer to put more controls in place to maintain the system. Person to person is a fragile system. But if you have a mechanism in place for surfacing a problem immediately, you fix small problems quickly.
How do you build a process to be fragile?
1. Start with behavior. If you don’t focus on behaviors, the system design will still not yield the right outcomes. People must want to surface and solve small problems at their source. They have to welcome the opportunity to problem solve, not just work around the problem.
2. Design a way to see problems. You must have a clear and clean definition of a problem. At what point did we just suffer noise in the day-to-day work, and at what point did we have a breakdown? This is easier to determine in manufacturing than in a process such as product development, but without it, you can’t rely on rapid problem solving to keep your process stable.
3. Design a mechanism to surface a problem. Toyota has their famed andon cord which allows a worker to call attention and help to an abnormal condition. It does not need to be this structured, but it does need to be pre-defined. If you are in the middle of a potential problem and need to decide what the mechanism will be, it will never get done.
4. Respond in a helpful manner. Having leaders that act as servant leaders certainly helps, but a bit of leader standard work can go a long way. The simplest script is just three questions, which at least ensures we solve the right problem. First, is there a standard? If not, it is hard to blame someone for not following it. Next, did you follow the standard? Many standards exist but let’s not fix one before we understand if we’re using it. Most reasons for not using standards are legitimate problems to be solved. And then finally, how can the standard be improved?
A fragile system needs to be designed that way. If you respond to the small problems rapidly and effectively, your system will be inherently more robust over the long-term.
