Why Collaborate?

Given a choice, most of us would choose to work somewhere where our colleagues offered support whenever they could and actively shared information they thought would help us. Perhaps some of us prefer the idea of our colleagues helping us but not having to help in return. Our choice is to collaborate or compete. It seems like corporate capitalism favours ruthless competition and short-term self-interest. But psychology suggests competing or trying to cheat the collaboration system does not pay off in the long run.

When I think about my own working environments over the years, there has been a wide variation in how collaborative they have been. Project teams are by their nature temporary. Like most project managers, I have had the interesting experience of becoming a part of a great many temporary teams in various organisations.  I realise, looking back, that I take my cues about how much I collaborate from the group I am joining. This approach is explained by the psychological theory around collaboration. Teams seem to find a level of collaboration. This is part of what is referred to as a Nash Equilibrium (after him out of A Beautiful Mind). We make decisions about how open and giving to be, not in isolation, but keenly aware of how giving our colleagues are likely to be. In competitive environments, team members act as if someone will end up on top and the others will be the losers. This relates to the zero sum game in game theory.

Psychologists and game theorists sometimes talk about collaboration as reciprocal altruism and a famous game in this area is The Prisoner’s Dilemma (Flood and Dresher 1950). The premise is that two prisoners are being questioned separately by police. If they both stay quiet they both get off on lesser charges. If prisoner A gives evidence against prisoner B, prisoner A gets off scot free and prisoner B gets a heavy sentence. If they both give evidence on each other, they both get the heavy sentence.

Analysis of The Prisoner’s Dilemma reveals a lot about collaboration. Mathematically, we are best off over time if everyone collaborates with each other (Axelrod and Hamilton 1981 and Worker and Reader 2004). Collaboration here means both prisoners collaborate with each other (i.e. both stay quiet) not that they collaborate with the police. This dynamic reminds me of being on a see-saw. If we jump off without warning the other person, we get to decide and control our descent but the other person gets to come down with a rude bump. It takes coordination for both of you to come down slowly enough to be comfortable (and nobody be the loser with a sore rump). This is by far the least stressful way to descend from a see-saw, as I’m sure you will agree.

So it seems that true collaboration, not cheating the system, is in our long term interest and is least stressful in the short term. I’ll talk below about how this relates to my experience of project management specifically. In general, it is a phrase frequently encountered on the web but if you Google “project management collaboration”, you get a bunch of software tools rather than theory examples. I guess the tools are easier to monetise than the theory.

Perhaps the benefits of collaboration in project management are so universally accepted as to be invisible. Examples come to mind easily. In a programme setting, open and proactive communication makes it easier to manage dependencies and risks. Projects benefit from sharing lessons learnt and exchanging intelligence on common risks and issues. Examples of a lack of collaboration in projects are similarly easy to call to mind. In competitive teams, members take on as little as possible and avoid supporting others, while maximising the appearance of their contribution. Likewise, if team members are competing then sharing intelligence about risks and issues lessens the chance of their project looking good relative to others.

Considering how something like the Nash Equilibrium might relate to my experience of project teams, I’d say the collaborative dynamic is surprisingly binary and sensitive to competition. As soon as one team member competes to do the minimum work for the maximum recognition, everyone else has two choices: either continue to collaborate and feel a mug, or compete.

The logical conclusion from my experiences of project teams chimes with the game theory concepts above. Collaborative teams are the most efficient and pleasant kind to work in, and if you want to work in a collaborative team, everyone needs to collaborate.

Of course, people don’t choose to either collaborate or compete based purely on reason. There is a nice story about a turtle and a scorpion that illustrates non-cooperation in the face of self-interest.

The references above to The Prisoner’s Dilemma come from the evolutionary psychology section of my Open University textbook. There are new books being written about this topic all the time and it will be interesting to see how much of this filters through to the workplace.

The above has been a brief look at collaboration in project teams. I have found it particularly hard to cover such a large topic in this short post. I have discussed choice of approach (collaborate or not) but I have not talked about the detail of how we collaborate. I touched on this in my post on how project teams talk. Mercer’s exploratory talk is a good example of trying to add light to a debate, rather than just the heat added by disputational talk.

Team Talk

One of the more obvious areas to look for insights into what makes project teams tick would be the field of social psychology. While Freud wrote about groups in the twenties, and industrial psychologists have been looking at this for a long time, much of the impetus for the modern study of what happens to humans in groups seems to have come from people trying to understand the behaviour of the Nazis in the Second World War. The applications of social psychology are many. For example, educators I know are particularly interested in how social psychology can help them improve teaching and learning. So what can social psychology tell us about working in project teams?

One feature I like about agile teams is that everyone is equal and has a respected opinion. I find this so important that I try hard to ensure all my waterfall projects are like that too. I temper this with always trying to give clear direction and leadership. As Laura Markham has said, people want to know that a ship has a captain and that captain is taking care of the ship. If the ship hits an iceberg, they don’t want the captain to come to their table and ask their opinion in a democratic and caring way. They want the captain to take care of the iceberg situation. So, I try to work in a team of equals, each with a clear and equally valid role. In that team, part of my role is to take overall responsibility.

This sense of equality is crucial to how the team talks to each other. Neil Mercer is a psychologist who studied the different kinds of talk in the classroom. I’d like to repeat his work in project teams. In his paper on the subject Mercer says

In exploratory talk, then, a speaker ‘thinks aloud’, taking the risk that others can hear,
and comment on, partly-formed ideas. Engaging in exploratory talk is therefore rather
a brave thing to do, and tends not to happen unless there is a degree of trust within a
discussion group.

This reminds me of both the ethos of agile teams (everybody is equal) but also the structure of the rituals. In the sprint retrospective or daily stand-ups, everyone has a chance to speak. The rituals make room for everyone to have a say. This encourages trust that one will be listened to seriously and an atmosphere of open sharing. Also, the permission (implicit in agile) to try out ideas and fail means that the groups is more disposed to entertain partially formed ideas and examine possibilities together.

Ron Friedman has been questioning the wisdom of collaboration on partially formed ideas, suggesting that it is better to do most of the creative work solo and come together only to share already formed ideas. I find his article very interesting and I easily related most of his examples to my working life. I do think, however, that his ideas apply less of the time than his article suggests. Friedman is not looking at agile teams in particular. I can think of lots of cases where solo creation might be best in agile. Still, it is worth noting that some of my most fruitful experience of agile teams has involved formulating solutions in groups. I’d say that is one of the strengths of agile.

Mercer defines three kinds of talk. I am interested to know if you recognise these from project teams. Disputational, cumulative and exploratory. Disputational communication is competitive. I find a lot of technical discussion sites highly competitive and intolerant of mistakes. I don’t know why this is so commonly the case. Cumulative communication is something I have come across a lot in conflict averse environments like some parts of the public sector. Ideas are accepted and built upon but without much analysis or apparently deep understanding. There is a lack of engagement. I also find this can happen when there are experts in the mix. People will listen to legal advisers thinking “well, it’s her job to know this stuff so I’m not going to question it”.

I once did a rather annoying drama exercise as part of a rather annoying team building day. It was interesting, The annoying bit was feeling compelled to take part (i.e. “You will have fun”). The exercise involved finding a partner, then listening to them start a story. When they stopped, you would say, “Yes and…” and continue the story. The shared ownership of the story made one pay attention and feel a lot more invested in where the joint story went. I imagine this is what exploratory talk is like but I wont be suggesting that exercise to my team any time soon.

There is much written about the interesting practicalities of communication in agile. I am interested in analysing the nature of that communication and would be glad to hear about your experiences.