By Max Kemman
How can tasks and goals among partners in a collaboration be effectively negotiated, especially when one party is dependent on the deliverables of another party? How does knowledge asymmetry affect such negotiations? What is knowledge asymmetry anyway and how can it be dealt with?
What is knowledge asymmetry?
My PhD research involves historians who are dependent on computational experts to develop an algorithm or user interface for historical research. They therefore needed to be aware of what the computational experts were doing. Sharma (1997) called this relationship information asymmetry, which may be solved by information systems keeping track of activities and results. However, a deeper problem is when the first party does not fully understand the other’s activities. A computational expert might show commits on GitHub, but a historian may not understand what these commits entail or why they were necessary. (GitHub is a web-based service for tracking changes made during software development, and a ‘commit’ is an individual change to a file that is assigned a unique identification for tracking purposes.) Sharma called this relationship knowledge asymmetry to describe the ignorance of how a collaborator performs their tasks. This leads to misunderstandings, as it is difficult to interpret what another party is aiming to achieve in the collaboration.
How knowledge asymmetry affects collaborations
Knowledge asymmetry especially poses risks in collaborative settings where the distance between forms of expertise is large, with little overlap of conceptual or methodological understanding. It affects not just the outcomes of research, but also the development of mutual trust, as the following examples from my research show:
- In one collaboration, historians did not sufficiently understand how to communicate functional requirements, and received a tool that technically met their specifications but did not work as intended.
- In another collaboration, historians did not know how long development took, and therefore could not plan communication and adoption of a tool under development.
- In yet another collaboration, historians were unaware that the tool they were using was hosted on a server for experiments, which regularly crashed when computer scientists ran resource-intensive experiments. Therefore they could not depend on the stability of the tool. The principal investigator from this final example reflected on this problem, exemplifying the complexities of knowledge asymmetry: You are very dependent on what the computational experts argue should be in the project proposal […] In hindsight I think they should have said more about the really practical things, such as computation capacity, server space, the stability of software, how that is managed. You need money for that too. We did not have budget for that in the project, as idiotic as that seems now.
In all the examples above, historians became sceptical about the intentions of their collaborators, wondering whether miscommunications were intentional or reflective of other problems. Knowledge asymmetry thereby led to unsatisfactory results, and decreased trust between collaborators.
While Sharma posed the problem of knowledge asymmetry in one direction, as a client unaware of how a provider works, the above examples show knowledge asymmetry in both directions. If a computational expert knows how historians want to use a technology, they are better able to interpret functional requirements. Or if a computational expert knows when a historian needs a tool in their project, they would be better able to prioritize functionality and communicate in time. However, despite this bidirectional ignorance, in all cases it was the dependent party that ended up with results not meeting their expectations.
Dealing with knowledge asymmetries
Sharma points to co-production to reduce the problems of knowledge asymmetry. Both parties should actively contribute to a joint enterprise, rather than one party being in a passive relationship of dependency on the other. Co-production requires much more thorough and frequent negotiations. These frequent negotiations reduce misunderstandings, and establish trust for several reasons:
- Regular social involvement helps both parties become aware of personal practices and goals.
- The providing party better understands the needs of the dependent party, and is better able to work towards those needs.
- The dependent party observes how the providing party works, developing understanding of the process of development.
In my studies, interviewees pointed to the development of know-how to establish a bridge of understanding between different collaborators. This know-how covered a variety of aspects of collaborations:
- How to conduct project management, make joint decisions, and plan the project accordingly?
- What can a technology do, and what are its limitations that historians are unaware of?
- What data should be used to test the technology, how should data be entered into the system, and what kind of tests are then possible?
The aim was that individual collaborators would possess sufficient knowledge of both parties’ goals and practices to translate between the two, and thereby decrease the problems of knowledge asymmetry.
Conclusion
What has your experience been with knowledge asymmetries? How did you deal with them in collaborations? What forms of know-how did you develop to establish mutual understanding?
References:
Kemman, M. (2018). Power asymmetries of eHumanities infrastructures. In, 2018 IEEE 14th International Conference on e-Science. Amsterdam, Netherlands: IEEE: pp.370–371. Online (abstract) (DOI): 10.1109/eScience.2018.00103
Sharma, A. (1997). Professional as agent: Knowledge asymmetry in agency exchange. Academy of Management Review, 22, 3: 758–798. Online (abstract) (DOI): 10.5465/AMR.1997.9708210725
Biography: Max Kemman (@MaxKemman) is a PhD candidate at the Luxembourg Centre for Contemporary and Digital History at the University of Luxembourg. His PhD project, titled Trading Zones of Digital History, is an ethnographic study of how digital history works as a negotiation between historians and computational experts. He writes a blog at www.maxkemman.nl.
“Regular social involvement helps both parties become aware of personal practices and goals.” I think this aspect is very important (not only where there is a knowledge imbalance but also where there are other imbalances between collaborators — power being an obviously significant one). I have found that the importance of investing in regular social contact is often undervalued or, by some, even discounted. When I mentioned it once as part of a collaborative working workshop, the immediate and unconsidered response (from some) was to say “Yes, we know that, but what is the method for collaborating effectively.” Collaboration cannot be done by the numbers, it is a relational activity. Call it co-production, or investing in intensive and purposeful communication, or simply making time for “in the same space” face-to-face interaction: it must be done. The most effective collaborative initiatives know this; a surprisingly large number do not. I explore this a little more here: https://cuttingedgepartnerships.blogspot.com/2019/02/how-to-develop-collaborative-meta_28.html
Thanks for your post Max.
Dear Charles, thanks for the comment. I agree face-to-face interactions are fundamental to collaboration. A recent publication of interest that tested this statistically is Marlow et al (2018, http://doi.org/10.1016/j.obhdp.2017.08.001) who found that the effect of communication on team performance was stronger for face-to-face than for virtual communication (hypothesis 3 in the paper). Interestingly, entirely face-to-face was not stronger than ‘hybrid’ communication, for which the authors suggest this may consist of face-to-face communication for ill-defined problems and building trust, and virtual communication for clearer tasks. I have not empirically tested the difference between face-to-face and virtual communication in relation to knowledge asymmetry, but more frequent negotiations reduced knowledge asymmetry, suggesting face-to-face interactions are absolutely important.
Thanks Max, Very useful for current existing collaborators as well as teams contemplating entering into a joint collaborative venture in future.
The terms of mutual benefit for each collaborating partner need to be spelled out in advance before entering into a memorandum of understanding (MOU) of expectations. The interdisciplinary team or transdisciplinary team have to set up an initial meeting where aims, objectives, goals, vision, mission of this joint venture are discussed thoroughly and agreed upon by all consenting parties for the greater good to them in particular and larger humanity in general. The terms of conditions of who will do and provide what need to explicitly made clear to the entire group, what the reasonable and pragmatic expectations are from each member actively engaged and invested in this larger collective undertaking.
It helps to avoid later hard burns and buyer’s remorse when expectations are not met to the satisfaction of partners willing to invest their intellectual capital, hard work and valuable resources to this noble idea in the first place. Before people get into the mind set of cutting their loses in the middle of the project, they ought to think realistically up front in the beginning was it a lop-sided enterprise of give and take or mutually beneficial symbiotic and reciprocal professional relationship for the long term sustainability of the partnership.
Dear Anil, thank you for your comments. Most, if not all, of my case studies started from a description of work (DOW) which describes each partner’s responsibilities as well as possible dependencies. However, the problem is that since the research problem is usually ill-defined, it is not always possible to determine properly at the start of the project how a problem will be solved and how much time this will take. Another problem that I’ve found is that the DOW is not just written for collaborating partners, but also aimed at the funder, so that certain parts may reflect promises made for a grant that may or may not be as feasible as expected. The actual implementation of what is in the DOW may therefore be very different depending on interpretations. Is this dynamic specific for digital humanities, or does this reflect practices in other inter-/transdisciplinary fields?
Thank-you Max, very useful.
I see parallels with other fields: namely evaluation and management information systems: evaluators may focus on evaluation uses and key evaluation questions, yet a projects’ MIS (Management Information System) may have focused on other parameters, leading to an awkward mismatch and doubts about who should yield. I also recall the notion of optimal ignorance that may be relevant here.
Dear Ricardo, thank you for your comments. The notion of “optimal ignorance” is definitely relevant, especially in raising the question how to define how much collaborators should know, and even more so who gets to define that. For ill-defined research problems, which are common in digital humanities, it is hard to know beforehand how much everyone should know to perform their tasks. I suppose that would fall within the scope of the “know how” development.