Lazy Tom supplied no alt text, give him grief!

I know the concept of cargo cults is problematic. Still, it’s a useful shorthand for talking about following a process blindly without paying enough attention to whether it is effective. The more rigid your process, the more likely you are to fall into this trap. We’ve been design-sprinting recently, and so I’ve been pondering this.

This is a hard problem because the process is there for a reason. It’s vital to allow it to run its course. It’s bound to feel a little shaky at times, but you see it through. No one gets off a log flume half-way through right?

But you want the log flume to end with the conveyor belt’s chakka chakka chakka, the darkness, the big swoosh and the splash. That’s what makes sense of the log flume. You don’t want it to end by, for example, opening out into a lake and with you finding yourself, and your compadres, drifting out into open water without any form of propulsion.

But the process is the great thing about a design sprint. Each bit leads onto the next. Each thing you do is the prelude to the following thing and helps you to do it better. This is what allows for the speed, the productivity, and the sense of achievement at the end. If you didn’t have the process, you would do what you do at other times, chat, procrastinate, argue and waste time. So the process is vital, but at the same time, it’s not the point.

I can’t help feeling there’s something bigger in this. Some sense that as we codify things and spread them out into the world, as we turn them into recipes, we can’t just rely on those recipes alone. We still need to apply critical thinking at each point and to check them, and be willing to ditch things if they’re not going well. We need to avoid setting up the conditions where completion bias could blind us to problems.

So it’s hard. I wouldn’t say any of the design sprinting I’ve been involved in recently has entirely “left the flume”, as it were, but there is still that worry that just because you own a great hammer, not every problem is a nail. As a designer, as someone who is concerned with doing the right thing (as well as the thing right), but also as someone who accepts that the team is the unit of service design, not just me, I find myself thinking about this more and more.

First published at: