Slowification and Amplification
How whining and deceleration are keys to improvement and speed
Check out my book called Grokking Simplicity and it’s the functional programming book you can recommend to beginners. If you don’t recommend it to your friends, please recommend it on Amazon.
I’m giving a talk in January at the Houston Functional Programming User Group. I’ll be presenting the last 2.5 domain modeling lenses for my upcoming book, Runnable Specifications. There are 8 sections written already, available free online. Read them now.
This issue is short because I just got back from Thanksgiving vacation. Please enjoy!
Slowification and Amplification
I get the feeling that people think I complain a lot. I notice problems, opportunities for improvement. I want to make things better, and so I tell people what I see. But, in the wrong culture, bringing up problems sounds like complaints. We’re so busy getting stuff done, and all Eric does is bring up problems that we don’t know how to solve. And so people label me as a complainer.
But identifying problems and areas for improvement is a great skill. We should all appreciate when someone on the ground, doing the work, notices an inefficiency. These signals from the trenches can be invaluable. But, too often, they’re ignored, and the source of the signals is stigmatized. That’s how it’s been at too many places where I’ve worked. It makes me feel ignored, alone, and unappreciated.
That’s why I’ve been drawn to the andon cord. When you pull it in the Toyota factory, it not only stops the line, but it calls your manager to come see the problem. And they help you solve it! You’re encouraged to bring up problems. The andon cord is pulled thousands of times per day—and they love it.
Wiring the Winning Organization describes the principles behind the andon cord in great detail. The authors call them slowification and amplification. Amplification is the boosting of signals about problems so they get to the people able to solve them, which is often as high as top-level management. Slowification refers to stopping the performance of our job for long enough to think about the job itself so we can solve problems and improve. These principles are used at high-performing teams and organizations to constantly improve.
But too often, programmers are ignored when they ask for time to improve the code, or denied the budget for a tool that will help them, or considered whiny babies for talking about how things could be better. The book details case study after case study where taking time to slow down and improve the work leads to better results in the medium and long term. I only hope I can work at such an organization one day.
The most I’ve really experienced has been the ubiquitous “retrospective”, where people get to complain but mostly nothing comes of it. Even when there is something that comes of it, it’s the usual “solve problems by adding process.” It makes me so angry I want to throw things. But that’s a story for another issue.