Reflecting on a Critical Incident

On 24th of February I began reflecting on what happened on the day before when several things didn’t run as smoothly as I would have liked. I initially recorded my thoughts and after a conversation in a JISC meeting on 12th of March, decided to rework my thoughts into this blog entry.
I have two aims here. One is to address a critical incident and find a way to move forward. The second is to use the technique of blogging on a critical incident – we are teaching this technique to our eCommunications students.
In reality there were two incidents, but they are interrelated.
The first was my conversation just before the eCommunications meeting with our Multi Media Designer. I mentioned that we wanted to have different learning sets for Mod 3 and he immediately said we couldn't do this as the forums couldn't be reconfigured once the initial learning set had been set up. I took it as read that we weren't talking about creating new learning sets that would run across Kate and my groups, but he didn't work on this assumption. However, as he was a Multi Media Designer and not a teacher, he was not to know this and made a totally reasonable assumption that we wanted to totally reconfigure the learning sets using students from Kate’s group and my group. This is interesting, isn't it? As teachers we were all working on an educational decision and on an educational way of organising things and the Multi Media Designer had absolutely no idea that was how we would work. I never thought to tell him as I assumed he'd know. My initial reflection on this was to identify that it would have been better if I could have anticipated what he might know or not know about how we are teaching and delivering the course. I was, however, aware that it is often a difficult thing to be able to anticipate in this way. I did make a decision that in future, if a similar situation arises, that I must try and step back a bit and ask myself what he would or wouldn't know.

The second, related incident was with the Senior Programmer. I had sent him an email following the eCommunications meeting on Friday 23rd in which I asked him to come up with a solution by Wednesday the 28th of February about our using a wiki for the course. The Senior Programmer has been incredibly supportive of our eCommunications development and he actually made a point of coming to see me to talk this over later that day. We met and discussed things and he agreed to try and find a solution by

*Spending Monday seeing if he could set up an extension to enable media wiki to allow closed pages (there is a warning on this extension that it might be unreliable)
*Talk to our IT Manager to see if TSC will fund having several instances of mediawiki on the server (this is expensive though. We mean up in the £1000s.
Having protected areas is, according to our Senior Programmer, messy and could be time consuming

During this discussion our Senior Programmer said that he'd spoken to Mark Power (from JISC)and Mark's colleague at Bolton and said that there was confusion over what we could do. Our Senior Programmer explained that since he had originally set up the password to mediawiki, it had been configured so that we could all use the same password to enter the media wiki, but that following this we could then create an individual account and thus have individual access to the wiki. This was not my understanding. I thought that we all had to use the same password. I was a bit bemused.

Reflecting on this I could not understand how I had misunderstood things. I made an initial decision that in future meetings and discussions I need to take care to make sure that everything is as clear as it can be when talking to our Senior Programmer or to the Multi media Designer. I really thought that I had been doing this but it is difficult. I reflected that it really comes down to conversations where lots of technical terms are being used that I don't fully understand the implications of and not being aware of what I don't know. It is very difficult to write things down and seek clarification during a meeting, which might be informal. I am aware that even in a formal meeting the final record is dependent on the ability of the record taker and the subsequent competence of those present at the nest meeting to verify that the minutes are a true record.

My initial reflections were that I needed to do more to understand the position of the people we are working with who do not necessarily have an educational perspective and also to try to be more aware of my ignorance of the technology and to try and address this. I realised that I had not reached any solutions here, but it was a start.

The next stage in my reflections was prompted by a discussion at a JISC meeting in Birmingham on 12th of March. During the morning session a point was raised about Peter Galison and the concept of the ‘trading zone.’ Galison recognised that when people from different disciplines and expertise came together to work on a project, they produced what he called a ‘creole’ in order to understand each other. I found this concept immediately attractive for several reasons:-

As an English/communications teacher I was interested in and had knowledge of creoles – it was, if you like, within my area of expertise.

The concept clearly addressed a problem I had been wrestling with.

The concept recognised that the problem was not about things I should have done or needed to do, I now realised that I was approaching the critical incident from the wrong angle.

Lastly, as so often happens, when I came across this concept I realised that it was in many ways familiar to me. Until I was introduced to it, it lay just beyond my ability to articulate it. But as soon as it was explained to me, all the pieces fell into place. To use another technical term from my area of expertise, it was an epiphany. I realised this is something that often happens to me and I assume all of us.

My final reflections now take me to realise that the implications of the critical incident are simultaneously easy to understand and hard to address.

The following, taken from Wikipedia, shows the way forward. All involved in the project, the stakeholders, need to agree on ‘rules of exchange’. The first stage is to recognise that we don’t need to know everything about each other’s expertise and knowledge base and that we don’t need to.

An interesting point about using the Critical Incident technique here, is that the final process, for me, has taken place well beyond the period of my initial reflections. Even before I had heard of Peter Galison I was trying to engage with and change my initial decisions in view of subsequent events. It seems, therefore, that the technique is much more of a 'live' and ongoing process that I had at first thought.

Overview of the ‘trading zone’
Peter Galison produced the "trading zone" metaphor in order to explain how physicists from different paradigms went about collaborating with each other and with engineers to develop particle detectors and radar.
According to Galison, "Two groups can agree on rules of exchange even if they ascribe utterly different significance to the objects being exchanged; they may even disagree on the meaning of the exchange process itself. Nonetheless, the trading partners can hammer out a local coordination, despite vast global differences. In an even more sophisticated way, cultures in interaction frequently establish contact languages, systems of discourse that can vary from the most function-specific jargons, through semispecific pidgins, to full-fledged creoles rich enough to support activities as complex as poetry and metalingusitic reflection" (Galison 1997, p. 783)
In the case of radar, for example, the physicists and engineers had to gradually develop what was effectively a pidgin or creole language involving shared concepts like ‘equivalent circuits’ that the physicists represented symbolically in terms of field theory and the engineers saw as extensions of their radio toolkit.
Exchanges across disciplinary boundaries can also be carried out with the help of an agent: a person who is familiar enough with the language of two or more cultures to facilitate trade.
At one point in the development of MRI, surgeons saw a lesion where an engineer familiar with the device would have recognized an artifact produced by the way the device was being used. It took someone with expertise in both physics and surgery to see how each of the different disciplines viewed the device, and develop procedures for correcting the problem.(Baird & Cohen, 1999). The ability to converse expertly in more than one discipline is called interactional expertise(Collins & Evans, 2002).
[edit] Areas of Application
The U.S. National Nanotechnology Initiative calls for a “broadly inclusive interdisciplinary dialogue on nanotechnology” that would incorporate a wide range of stakeholders (http://www.nano.gov/html/society/Responsible_Development.htm). This kind of a dialogue will require developing creoles that allow different stakeholders to communicate, and also interactional expertise (Gorman, Groves, & Catalano, 2004).
The convergence between nano, bio, information and cognitive technologies will set an even greater premium on the development of trading zones and interactional expertise (Gorman, 2004).
Computer science education requires development of trading zones between experts in the social and learning sciences and computer scientists (Fincher & Petre, 2004). Each of these communities uses different methods and speaks a different language, hence the need for a creole and also for interactional experts.
Managing environmental systems like the Everglades also requires the development of trading zones (http://www-personal.umich.edu/~bwfuller/Trading_Zone_Paper--Boyd_Fuller--Distribution--Jan_1-05.pdf). Brad Allenby suggests the development of a new kind of expertise in Earth Systems Engineering and Management, which will include an interactional component (Allenby, 2005).
A workshop at Arizona State University on Trading Zones, Interactional Expertise and Interdisciplinary Collaboration raised the possibility of applying these concepts to other applications like global health and service science, and also identified avenues for future research (http://bart.tcc.virginia.edu/Tradzoneworkshop/index.htm).