On Collaboration

In 2018, Gabriele Griffin and Matt Steven Hayler wrote that “Collaboration has become a hallmark of Digital Humanities (DH) research”, citing works that show that “seven out of ten Digital Humanities researchers said they ‘often or very often’ engage in collaboration”. Collaboration is touted as an essential property of Digital Humanities, together with interdisciplinarity and an open-data / open-source ethos. Beyond Digital Humanities, and looking at scientific research in general, collaboration is a virtuous thing to do, and, in fact, many grant calls require that you collaborate before they even consider you for funding.

However, I am sceptical about collaboration. Don’t get me wrong; I do collaborate often, I enjoy it, and I am certain that many of things I’ve achieved in research wouldn’t have been possible without collaboration. Still, I have the persistent feeling that collaboration is being oversold, that it is way less often used than reported, and that many of us have serious doubts about how far it can get us.

In 2004 I was interviewed for a job at the University of Technology, Sydney. One of the panel members asked me the usual but interesting question “What is your biggest professional weakness?”. I pondered for a moment and they answered something like this: “I am not a great team player. I mean, I can do it, and sometimes I even enjoy it, but I often prefer to do things by myself, or at least to take a strong leadership on them, which relegates input from others to a secondary position”. I sort of blurted it out, without much thinking about how opening my heart like this would affect my job perspectives. They gave me the position, so I imagine it wasn’t that bad. Months later, I was having a coffee with the panel member who had asked me that question (she was a colleague at the Department) and she reminded me about my answer, and asked me to elaborate. We had a great chat about the issue, and these are some of the ideas that I started developing then.

What is collaboration?

What do we mean by “collaboration”? Most people would understand that this means two or more people working as a team, putting effort towards a common goal. OK, but this admits different degrees:

1. Aggregate. A task is decomposed in parts, and parts are allocated to different people to tackle. Then, results are assembled together into the final product. I’ve seen many research papers being written like this. Alice writes the introduction, state of the art and conclusions, Bob does methodology, Claire writes the results, and then one of them takes everybody’s work, concatenates it into a single document, and voilà, the paper is ready for submission. It doesn’t matter much who does the aggregation, because he/she won’t add much value, just put fragments together in the right order.
2. Compose. Like in the previous case, a task is decomposed in parts and each part is addressed by a different person. But then, when they are put together, someone cares to stitch them nicely, add some glue to the joints, and make sure that everything makes up a nice and seamless whole rather than a patchwork of fragments. Here, the person who does the assembling has a much bigger role than before, as he/she adds significant value to the final product. In this manner, the role of the leader begins to appear.
3. Circulate & review. In this style of collaboration, different parts are tackled by different people and then put together, like before, but then each individual contribution is circulated to the other team members for comments and revision. In this manner, everyone has a chance to contribute in parts that are not their own. This is likely to produce a more harmonic result, which also contains fewer mistakes. However, it requires more work from everybody, and despite the clear advantages, each team member is still the “owner” or “boss” of a part of the work, while others typically make minor comments. This approach also introduces the need for a negotiation or reconciliation process, because comments from different team members may be contradictory, and often someone must make the final decisions.
4. Co-develop. This means that the complete product is actually co-developed by all (or most ) team members. In the example of the research paper, all would work in the introduction, all work in the methodology, all work in the conclusions, etc. Working together like this is extremely time-consuming, requires that all team members have a deep understanding of every part, and needs appropriate communication channels and collaboration infrastructure such as meetings, whiteboards and shared folders. More than ever, the role of the leader is crucial to manage the meetings, drive the negotiation and discussion processes, and make sure that the final result is delivered as expected.

Of course, these categories constitute an idealisation, and many real-world collaboration efforts may have elements of more than one category or lie in between. I have used them all with different degrees of success, and I have played different roles throughout.

Some examples

Between 2009 and 2012 I led the MIRFOL project, which produced the first versions of ConML and CHARM. For three years, a team of 5-7 people would meet every Monday between 10:00 and 14:00 to advance the project. That’s over 500 hours of work for each person involved, totalling around 3000 person·hours of effort. I would set the agenda for each meeting, make sure that decisions were made when needed, documented the output from each meeting, and assembled the products as they emerged. This was a clear case of co-development, in which every team member participated in most areas of the project results with intensity and commitment. Of course, not everyone contributes equally to everything, and differences related to background, expertise and personal inclination must be respected. Still, we managed to create a project dynamics where the chance for contribution existed for everyone, and were successful at that. In particular, what CHARM is today would have been completely impossible without a co-development scenario like this.

When the project finished, we gathered together to discuss hits and misses, things that worked well and things that we wouldn’t want to repeat. The co-development style of working was recognised as extremely valuable by everyone but, at the same time, many team members stated that they wouldn’t be willing to embark in a similar project anytime soon, because the time and effort demands of such a working style were too big.

I repeated the experience of co-development a few other times. For example, we developed Cabila under the GEOARPAD project in this manner, and the work that I am currently involved in regarding IAT/ML and LogosLink is taking this form as well. It is an exciting and energetic approach to doing research, but it’s extremely time-consuming and requires a great amount of commitment from all parts involved. In today’s climate, where all of us are subject to pressures to do more in less time, comply with overwhelming bureaucracy and compete for little funding, co-development is a luxury that not everyone can afford all the time. It’s the best approach, for sure, but it’s very expensive.

A very decent alternative is the circulate & review approach. For the team leader, the amount of work required is similar to the previous case. However, team members see their workloads lighten up substantially. Work in this type of projects tends to happen in peaks when a major document or product is circulated and needs to be revised, or when a contribution from a team member is due. This leaves time between peaks for time members to work on other projects, and removes the strict imposition of regular meetings. Most of the work that I do in relation to standards with ISO/IEC JTC1/SC7 is like this. When you lead a project, you are expected to develop a document, circulate it to others, and wait for comments. Then you go through the comments one by one and decide whether to incorporate or reject it. This process is repeated until the document is of an acceptable quality and the project finishes. Developing standards would be impossible using a co-development approach, as the number of people involved is very large and distributed across the world, so projects like this benefit from a circulate & review approach. The drawback is that they are prone to the “design by committee” problem. As direct interaction with contributors is often difficult, and the only information about their contribution that you have is their written comments, sometimes you, as a leader, must decide between rejecting their comment (which may be unfair and a loss for the product) and accepting it without much basis or understanding (thus leading to “design by committee”).

From a team member, rather than leader, perspective, working in a circulate & review style can be anything from a joy to a pain. You are supposed to read some materials that you didn’t develop, understand them without much discussion with the people who actually did, and then provide comments to improve the result or fix mistakes. Some people (including yours truly) get frustrated when working like this, as you must make too many assumptions about what things mean and what the overall goal is. Nothing guarantees that all team members share a common vision and are capable of producing input that aligns with that vision rather than their personal preferences or experiences. Still, this approach is much, much affordable than co-development, especially for large projects involving many people.

Finally, I have also worked under aggregate and compose styles. I don’t like them very much, and I think that they should be avoided. Very few cases justify a compose style of work, and no cases, in my experience, justify an aggregate approach.

So, what’s the problem?

The problem is that few people have a clear picture of what kind of collaboration they are embarking on when they are required or encouraged to collaborate. And few managers and research funders have a clear picture of the implications that collaboration has at different levels. When you embark in collaboration without a clear idea of what it entails, you are bound to commit to something that you cannot afford or that cannot produce results of the quality that you would like. To be blatant:

• If you are a team leader planning to collaborate, and you haven’t thought about what level of collaboration you want to address, whether your team can afford it, and how you are going to make it happen, then you are risking the project big time. Take a step back and think through your collaboration strategy.
• If you are a team member being asked by your leader to collaborate, and haven’t been given a clear description of what kind of collaboration you are expected to do, please ask, and don’t stop until a clear answer is provided.
• If you are a research agency requiring that projects occur in collaboration and not explicitly funding the cost of that collaboration, you are decreasing the quality of the products that will be obtained. Consider whether collaboration is actually needed or just something nice to have to tick a few boxes. Relax the requirements and provide funding for what you request.

In multidisciplinary settings, these problems become even more serious, as cross-understanding between team members can be difficult, especially during the initial phases. In the MARIOL project described above, which involved archaeologists, art historians, anthropologists, software engineers and other specialists, for example, we used the first few months of weekly meetings to agree on a set of shared concepts and terms that we then used throughout the project. In a circulate & review scenario, achieving a common understanding is even harder, and sufficient efforts must be made to guarantee that the team is not talking at cross purposes.

Reasons to collaborate

Collaboration can be motivated by a number of things, such as:

• The work is too big and you cannot do it all.
• The work is too diverse, involving areas of expertise beyond your reach.
• The work will benefit from the perspectives of other people, because of their knowledge, experience or background.
• You just want to work with someone because you like them or feel great sharing things with them.

Collaborating just because you must, because you are required to do it, or because there is a box to tick, is a big waste of time. Do it if you have good reasons, be prepared to invest in it, and enjoy.