Broken but functioning

By Andy Palmer, with Antony Marcano

Recently, a team-member’s motorbike started sounding a little bit more rattly and metallic than usual. He’d let the engine run dry of oil. It turned out that the piston had seized and torn a chunk out of itself. He managed to keep it running by topping up the oil and, as a result, he was still able to get from A to B. But it was too late by this stage. It was broken, but still functioning. It wasn’t efficient, clean or even as enjoyable an experience — why would it be when you’re always on a knife edge that the next kilometre could be the bike’s last — but it worked. His bike was like many organisations and products we encounter: broken but functioning.

When people are on a knife edge that they might not make their next deadline, we might consider that organisation broken, but functioning.

In an organisation, are they empowered and safe to adapt, make changes and take chances? Do we make it easy for our teams to experiment, innovate and find that competitive edge? Or do we see have layers of sign-off needed for a few hundred pounds/dollars of travel expenses (costing more in management’s time than the expense itself). Do we have immovable deadlines that somehow get moved at the last minute when the short-cuts taken to try and hit it have already started to slow people down? When people are on a knife edge that they might not make their next deadline, we might consider that organisation broken, but functioning.

…if the product isn’t making it easy for users to achieve their goal, then we might consider that product broken, but functioning.

Think about the user experience of your product. Is it enough that people can achieve what they need to do? Is their experience the most pleasant and simple it could be? In The Design of Everyday Things, Don Norman states that people tend to blame themselves when they fail to achieve a goal, but if the product isn’t making it easy for users to achieve their goal, then we might consider that product broken, but functioning.

If the code is making it hard for us to make progress, even if we still complete our tasks, we might consider our code broken, but functioning.

Our code is the user experience for our development team. Can they achieve what they need to do? Is it easy to add new capabilities? Is it easy to prove that the system is working as designed? Is it easy for new starters to install a local working environment and get it working? Do the automated tests run fast enough that we’re happy to run them multiple times a day? If the code is making it hard for us to make progress, even if we can still complete our tasks, then we might consider our code broken, but functioning.

…it’s never the right time.

The owner of this bike had often thought about checking his oil level, but it was never the right time. There were always places to go and other things to do that were more urgent. How often do we hear this story in our organisations and teams? We don’t have time to try a different process to see if we can ease this bottleneck because the next deadline is looming. We don’t have time to fix the user experience because we need this new feature by the end of the month. We don’t have time to refactor our code or speed up our automated tests because there’s not enough time. We all know that these things are important, that by investing in them often we actually get the outcome we seek, to be able to travel further in less time. But there’s always something more urgent. Wait too long and you run the risk that the engine might seize up completely. Then, it is broken and not functioning.

When was the last time you took your organisation in for a routine service? When did you do a safety check on your user experience? When did you last check the lubrication in your code?

What kind of lubricant will protect the moving parts in your organisation, in your user experience, with your code? For some ideas, contact us via RiverGlide.com.