In a blustery rainy Toronto, speaking at the joint Canadian and American Academies of Child and Adolescent Psychiatry annual meeting. First workshop we (Efrain Bleiberg, Trudie Rossouw and I) did on mentalizing approaches to affectively unstable adolescents seemed well received. A symposium on mentalizing approaches to treatment next, on Saturday, with Peter Fonagy, Efrain, Trudie and Carla Sharp. I will be talking about AMBIT, MBT-F (Mentalization based treatment for families) and will include material on the tiddlymanual. Increasingly I like the notion of AMBIT as an 'open source therapy'... This is very much true to the nature of mentalizing in practice... Just like the programmers who throw open their source code for others to examine and help improve upon, so the mentalizing therapist takes a chance on 'throwing open' his or her thoughts, all the while marking them tentatively as 'just my best theory about what is going on here'. I love the open source 'mantra' - "Release early. Release often"... Really good match to mentalizing work, and draws a marked contrast between the stance that a mentalizing therapist takes and those of more 'knowing' or 'expert' schools of therapy, who may be perceived as withholding, or secretive, by their patients in ways that arouse emotional responses that then paradoxically block mentalizing...
Anyway, the other news is that a third generation of the user interface for tiddlymanuals is in development thanks to Jon and Josh at Withjandj and funded through the Comic Relief grant - the effort is all directed at smoothing (and soothing!) the user experience (once you adopt the frame of mentalizing it is like a benign virus that infects everything - web design is of course all about mentalizing the user!)..
The new design will aim for a crisper typeface, and will further emphasize the notion of tiddlers as paper on a desk (think wood, like the beautiful walnut2 theme for Firefox!) but we are working to make the 'meta-data' attached to each tiddler note even more intuitive, and to make it clearer for the user whether she is browsing or editing...
Should be released in a couple of weeks or less.
Friday 21 October 2011
Tuesday 4 October 2011
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,
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,
Subscribe to:
Posts (Atom)