After reading Atul Gawande’s book The Checklist Manifesto I will never look at checklists the same way again. Not only are they deceptively simple ways of codifying knowledge in an organisation, they also provide a focus for keeping that knowledge up to date. Checklists – written guides that walk us through the main steps in a complex procedure – are so familiar we can easily overlook just how powerful they are. Checklists draw together experience and knowledge and make it available to others in an easily digestible format. If a checklist is created as a group exercise it also helps those involved focus on what is really important and share the fruits of their experience – a way of both codifying knowledge and connecting people. In complex high pressure environments, checklists can prevent us from overlooking routine matters that we would normally remember. They can also help us to avoid skipping important actions because we may mistakenly believe them to be non-critical. That’s why checklists are used in pre-flight preparations in every aircraft cockpit in the world.
We tend to think of checklists as only suitable for highly routinised work settings but experience shows that checklists work well even in complex working environments because they can help us maintain an effective balance between professional autonomy and organisational requirements. As Atul Gawande suggests “Under conditions of complexity, not only are checklists a help, they are required for success. There must always be room for judgement, but judgement aided – and even enhanced – by procedure.”
The Checklist Manifesto provides lots of useful hints for devising checklists and, importantly, keeping them up-to-date. An interesting distinction is made between READ-AND-DO checklist items (where you read the item and then carry out what is specified), and CHECK-ONCE-DONE (where you confirm you’ve carried out the specified action). Whatever way is used to construct a checklist, they work because they can help people to apply the knowledge and expertise gained in their organisation (and beyond) consistently well. And providing they are used and regularly updated in the light of new experience and knowledge, the better they become.
I was reading a story in ‘Wikinomics’ – the bestselling book about Web 2.0 – on the train home from my organisation’s Community Day in York, England yesterday evening and it provoked an interesting question for me. The story is about a company called Geek Squad that provides computer support to home and office computer users across the US. The founder of Geek Squad, Robert Stephens, was concerned that his 12,000 employees were not using the specially designed wiki networks that were supposed to help them share their knowledge with each other and thereby build a company knowledge base. Why, he wondered, did supposedly tech-savvy staff overlook something that would help them do their jobs better? It turned out that they were sharing their knowledge – its just that they were using an on-line gaming platform to do it rather than the company’s carefully designed wiki pages! Stephens was smart enough to realise that it didn’t matter how the knowledge-sharing was done – whether it was self-organised around a computer game or through a company designed platform. What was important was that the company was benefitting from their collaboration.
This prompted me to think about knowledge-sharing in development organisations. I hear of many NGOs that set up elaborate in-house knowledge-sharing systems which see very little use – for many different reasons. Not surprisingly this can be very frustrating given the investments made in setting up the systems. It is like the Geek Squad founder’s experience – you set up a mechanism that few people use. Then you look around and find that people have created their own ways of collaborating. How frustrating! But in the end does it really matter whether knowledge gets shared using in-house systems providing people in the organisation find some way of sharing their knowledge and ideas? Many people in those same organisations already do this by belonging to on-line communities, contributing to wikis, posting on their blogs and commenting on others’ blogs. They have found their own ways to share – it’s just that they don’t use the ‘company’s’ system.
Is there a lesson we could learn from this? Maybe it would be better for organisations to ‘outsource’ their knowledge sharing so that people are encouraged to use the mechanisms that suit them best. Part of each person’s regular discussion with their managers and colleagues would be about what they have shared and learned from their interactions, not whether they have contributed to the organisation’s own knowledge base. Of course, it is more difficult to track contributions and it doesn’t look as impressive from the organisation’s perspective but maybe it’s more important for an organisation to be sharing knowledge using popular existing channels than spending some of their valuable resources setting up little-used in-house knowledge bases.