Lean, not backpressure
Lucas Costa has written a good article on how to build systems that can handle<br>code-generating robots. Unfortunately, when calling it backpressure, he used<br>the wrong metaphor.11 Which, to his credit, he seems aware of. It’s just that<br>he’s spent too much time using the wrong metaphor that it’d be silly to switch<br>now. Backpressure is about signaling to upstream processes that they running<br>too fast and need to slow down. Note that the suggestions presented by Costa are<br>mostly about signaling to the upstream process that it needs to do things<br>differently, rather than just slow down. This has more to do with ensuring<br>sufficient quality is sent downstream, rather than quantity.
This irked me. As I was reading, I was searching for the right analogy. I kept<br>coming back to lean manufacturing. The more famous half of the lean philosophy<br>is waste reduction. The other half is about managing the unstable input of<br>people. That’s what we’re interested in here.
A common approach to the input of people – especially in lower-skilled jobs – is<br>to make line workers responsible for everything. We ask them to be<br>hypervigilant, tell them to never make mistakes, and let them know that if they<br>don’t always perform at their best, they will be chastised … or fired.
Lean, as it is described22 It may be different in practice; I’ve read some<br>conflicting accounts., is much more respectful of line workers and the<br>conditions they are performing their work in. A process designed in the lean<br>philosophy tolerates workers that don’t always perform at their best.33 One of<br>my favourite things to tell myself when I’ve messed up system safety is “If I<br>designed a process that assumed people would never make mistakes, then whose<br>fault is it really?” It’s about setting up processes and structures that have<br>positive optionality on people’s creativity, without undue requirement on their<br>level of responsibility.
This can take many shapes, but the Costa article reminds me of three concrete practices:
Single-piece flow means working on one thing at a time, so downstream<br>processes have a chance to reject before too much of the wrong thing is<br>produced.
Autonomation (or jidoka) means giving a machine the ability to detect<br>when something is wrong and not continue at that point.
Poka-yoke is a process that forces results to be conformant by construction.
You probably recognise these things as good, but a surprising number of<br>managers seem to think they can just chastise people until quality improves.<br>They talk themselves into this because they believe line workers are fully<br>responsible for their actions.44 They aren’t. As Deming said, a bad system<br>will beat a good person every time.
But even those managers will find it very hard to convince themselves quality<br>improves when they scream at the code-generating robot. It’s a robot! It can’t<br>be responsible for its actions. We have to adopt the lean philosophy for<br>building systems around robots. When something goes wrong, we have to blame<br>the process, not the robot.
We always had to do that, even with people, but with robots it’s painfully<br>obvious.