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): https://doi.org/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): https://doi.org/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 [Moderator update – In January 2026, this link was no longer available and so the link structure has been left in place but the active link deleted: maxkemman.nl]