Manualizing Practice

A manual is where people who know how to do something write it down so that others can copy what they do and get the same results.

In a team this could just mean keeping minutes of team discussions and filing them in a place where everyone else knows to find them - so that those moments of clarity when we have met a problem, discussed and agreed how we might better manage it if were to happen again... don't get consigned to the dustbin of institutional amnesia!

Tiddlymanuals are about giving a team the opportunity to record its own ever-changing 'best estimate' of what best practice is, and to do so in a way that encourages outside scrutiny - that is radically rejecting of notions of 'intellectual property' as far as how best to help vulnerable and deprived youth.

The radical bit about Tiddlymanuals is the way that they allow a blending of centrally-curated "evidence-based" material, with locally-authored "practice-based" expertise. although what the viewer sees is a single integrated wiki, different groups of people are managing these different pools of content.

In the last weeks in my wonderful team in Cambridgeshire (CASUS) we've really started to try this out...

We had a case discussion the other day, chaired by my excellent trainee Meinou, and under her guidance, after the therapeutic case discussions were over, we talked briefly about how team meetings like this could be improved. It was one of those conversations that we have had many times before, and it could so easily have been "just another" one; this time, though, we were able to minute our discussions live, as we agreed "these are the things that would help better to shape the way we use the precious time we do have available"

As the team talked, so I minuted and checked that what I was writing fitted with other people's understanding - this is made much easier as the tiddlymanual is projected on the wall in the little room where the CASUS team meets, so that everything is transparent and explicit.

You can see the rough draft of how we shaped this ten minute discussion here - it is rough and ready, but that-in-itself will propel us to work harder to "get it right". Why? Because over time the wiki manual becomes the 'flag under which we sail' - which as a team i hope we will come to take pride in. It is just this "nimbleness" (going from discussion to publication in about 10 minutes) that wakes us up, keeps us on our toes...

Early on in my learning about wikis and open source, I was told that one othe mantras of the open source programmer is "RELEASE EARLY, RELEASE OFTEN". Why? Because there is nothing like real world exposure to (a) cull real world FEEDBACK (see here) and (b) spur one on to do better in awareness that our present efforts are short of the mark! I couldn't agree more, and this goes for ways of working therapeutically, as much as for developing computer code that others might find helpful,