I recently wrote a blog post on We Need More Critical Friends! and have made this point in several of my recent talks on A Risks and Opportunities Framework For Archives 2.0 and Time To Stop Doing and Start Thinking: A Framework For Exploiting Web 2.0 Services and in a workshop I facilitated at the Museums and the Web 2009 conference on Openness in the Cloud.
In recently discussions with my colleague Paul Walk Paul has suggested that there is a need to differentiate between Critical Friends and Friendly Critics and I think this is a useful distinction. In the real world the critical friend is the person who would be honest about a response to a question such as “Does my bum look big in this?“ But the friendship would mean that this response would be given in private and not in a public space. The friendly critic, in contrast, might be someone who is willing to be critical in public, but would not do so in a way which is rude or undermines confidence.
Comments in response to my blog post by Pete Johnston and Mia Ridge made similar points arguing that “our choice of style and language matters – a lot” and “communication has to be both appropriately private and timely“.
But Mia goes on to conclude “That said, I’m not sure what happens when you raise concerns privately and don’t get an acknowledgement or other response“. And this is a legitimate concern to raise. What happens in one’s concerns are ignored? And in the context of services provided bu public sector funding don’t we all, as citizens, tax-payers and, possibly users, have responsibilities to raise concerns which we have. After all, aren’t we correct in raising objections to a wide range of mistakes which the Government has made? Weren’t we right in our objections to the Iraq war, despite being told that the Government had evidence of ownership of weapons of mass destruction and the ability to launch an attack within 45 minutes?
Of course there are huge differences between declaring wars and engaging in IT development work! But if we are in favour of openness and transparency in our development work this tension between open and closed criticisms is something which needs to be addressed.
In discussions I had at the Museums and the Web 2009 conference there was an understanding of the need for projects to welcome feedback, especially in the current environment we find ourselves in in which there is an increasing diversity of approaches to developments. But there is also a need for critics to appreciate the complexities of a specific development environment, aspects of which will not always be appreciated by the remote observer.
Based on the discussions I had will various people at the conference and my suggestion in the final session at the MW2009 that “We need more formal approaches for structuring feedback to the diversity of approaches to development work which can help to de-personalise criticisms” I have produced a diagram which is embedded in this post which provides an initial attempt at providing a structure approach for gaining feedback.
The diagram acknowledges that there will be areas (such as policies, the local environment, sensitivities and levels of resources) within which a development project will have to work. Concerns about such issues are likely to be out-of-scope for Critical Friends. This should help to scope the areas in which input, comments and concerns can be raised and which should be able to be acted upon. The development project will need to provide an infrastructure for engaging with a Critical Friends community. We are finding in some areas of the JISC development sector that a Critical Friends approach is becoming a formal part of a bidding process. However it is likely that in many any cases it may not be possible to adopt such a formal approach. Perhaps then it is the responsibility of the the project team to open up their development processes, perhaps by making use of a blog for use by the developers to describe their development plans and decisions and any complications which may not be apparent to others, ideally at an early stage in the development process. This, I think, reflects the approaches take by the COPAC development team in their COPAC development blog which, for example, described back in August 2008, the reasons why they removed and then reinstated links to Google Book following feedback from “a vociferous few who questioned why Copac would give Google ‘personal data’ about them as users“. As I wrote back in November 2008 “raising these issues in an open fashion is to be applauded“.
Our IT development work does need to have a reviewing process and I feel that we should be pro-active in seeking ways of opening up such processes. Let’s be aware of sensitivities, but let’s not use that as an excuse for being closed. And if there is a failure to open up feedback to development ideas remember that this may leave the concerned tax-payer to act not as a friendly critic but as an unfriendly, and perhaps even hostile, opponent.