Yesterday in class we ran something called the candle transport challenge, or sometimes we just call it ‘boats’ when we hope no students are listening. The idea is basically to transfer a lit candle from one end of a water canal to the other using very limited materials provided by the students. The material is things like a sponge, aluminium foil, some tape, straws, a bit of carboard and some paper. The task is one that always generates a lot of excitement and enthusiasm in the class and is worth the extra effort and time it takes to set up beforehand. Originally the challenge was created by a friend, Alex Utne from UiT The Arctic University. I met Alex through the DT lab in Tromsø, where I was one of the early members, and I had the privilege of learning about DT from him and the other members. Alex is very practically orientated, and has a great way of asking questions that get you to reflect deeply on whichever challenge you are facing.
It was therefore cool to see the boat racing challenge had independently of Alex, travelled to the University where I have recently transferred to. The staff had built their own version of the water canal need for the boats, and honestly was an improvement on the way we use to do things up in Tromsø. It felt great to co-teach a class based around this activity, and just like you can never step in a river twice – every time you teach something you get some new insights or observations.
The first observation was that it is fascinating to watch student expand a task to match the time available. We gave them 30 minutes to build prototypes and test them on this water canal. Most of the students therefore used around 20-25 minutes to build their prototype before boat racing and testing. I am certain that if we had of given them 10 minutes they would have been fine with this. If we had of given them an hour, I don’t think the prototypes would have been much different. The takeaway being that we tend to expand it to fill the space allocated to it. This is partly why I love questions like “what if we were to do this in half the time? What would that look like?”
The next interesting takeaway was observing the way students used the resources. They basically used about 80% of the resources we gave. It is natural to think this sounds logical and smart, unless you have seen this exercise done multiple times before and know that the winning teams only use a single resource – the aluminium foil. As soon as you start using other materials the boat gets too cumbersome and slow, and you either fail or get a poor result. It made me wonder how often I might be doing the same, over using resources, and making things far more difficult than they needed to be.
In using resources, I also noticed students using resources in a particular way. They would often carry out steps early on that could not be undone. For example, I observed a number of students cutting sponges in the first few minutes of a task. Generally speaking, you can’t uncut a sponge. There is no Ctrl + Z to make the cut go away if you decide you now need a whole sponge. The insight here was prototyping is about moving quickly to gather knowledge and learn, yet there is a counterbalancing force here which is some things cannot be undone. If I teach prototyping to the medical industry, and use one of the typical design thinking catch phrases of “everything can be prototyped” I often see people shift uncomfortably in their seats, as what I imagine is the ethical concerns of doing so flashes before their eyes. I guess the caveat in these situations is everything can be prototyped, but that doesn’t mean you should. Or in the case of resources, perhaps a moments hesitation is worthwhile before taking steps that cannot be undone. This is not in support of the endless planning school of thought, but more just a recognition that sometimes thinking through the consequences could help a little.
One of the other more interesting observation is watching path dependencies occur in real time. A team often creates an initial idea, they test that idea and if it is successful, then the earliest attempts are likely to be the quickest. Now if they have enough time to improve it, they will often attempt to do so by adding more stuff or making adjustments. Rarely do they ever make the original concept better though – the times tend to get slower and slower as they fruitlessly try to improve their prototype. These incremental changes seem unhelpful, or at absolute best they might shave a second of their time. The observation though is rarely do teams go back to the drawing board with their newly acquired knowledge and make a completely new prototype. They have a path dependency that they created in the first 5 minutes that will direct the rest of the way they tackle the challenge regardless of the outcomes it generates. I strongly suspect this is true for many of us in our private lives, that what we studied has been a strong path dependency. As for organisations, I think the examples here of path dependencies are probably endless.
None of these are life changing insights, but interesting to watch the group dynamics of innovation occur in real time as a fly on the wall.
Comments