Egocentric bias is a cognitive bias towards seeing things from your own perspective as opposed to others.
From this perspective, humans, and therefore scientists make many assumptions:
- That others share our interests
- That others share our knowledge
- That others share our abilities
- That others share our interpretations
Until you intrigue them, others don’t know why to care about your research. Until you teach them, others don’t know what you know and most will never have time to learn. Others may not have your skills and might never learn them. They also won’t believe your conclusions until you convince them.
Sure, it’s likely that the skills, knowledge, perspective and curiosity that you have are shared by a small group of others. Maybe a large group of others. You can probably think of many people in your lab or research hub that share those traits with you so it’s tempting to overestimate the total number of people in that category.
And just because a bias exists doesn’t mean everyone is guilty of it.
Here’s the problem. Research is getting really complicated. Combinatorial complexity between fields of study, experimental methods and computational methods are starting to create ever increasing lists of prerequisite knowledge required to understand any given publication.
An editorial in the journal Infection and Immunity, discusses the ever increasing specialization of science. It describes the benefits of “efficiency” and “rigor”, and the dangers, in “monopoly, monotony and isolation” that specialization creates.
This editorial calls for efforts to remove barriers between disciplines, but we might even settle for removing the barriers between individuals. Let’s do this by overcoming egocentric bias which will help us not only to communicate better but to make our work more useful to others.
Communicate your Why
I read lots of papers produced in certain domains, about certain tools or organisms. In these papers, it is always very obvious what was done. “We collected data on X using method Y and cross referenced this with prior research in area Z to make the following conclusions”. Often the problems or limitations of existing solutions or research is debated in detail.
However, it is less often that the why is communicated nearly as well. Why statements are often relegated to a single sentence, left at the end of the abstract to be ignored by anyone under time pressure who managed to find (or not) all the keywords they needed to justify (or not) reading further.
When I’m reading papers for the purpose of gaining an understanding or building a tool, the why is the first detail I look for and the detail I most often look back to.
My favourite papers, those I’m most likely to cite, have a why. They tell me why to care. Why they care. And if those match, I know the paper will be useful.
Keep your message simple
I heard of this first in the context of writing code but it works well for communicating in research too.
It’s the 21st century. Everyone is busy. Everyone is distracted. Everyone is multitasking.
If it’s hard to understand a point you care about, people just won’t understand it. Sometimes I work really hard to understand research. But I often don’t.
The Rule of 7, says that for someone to take action, they need to hear a message 7 times. If I read your paper twice, that means your key message, insight or call to action needs to appear on average 3.5 times. That’s once in your abstract, once in your introduction and maybe 1–2 times in your discussion/conclusion.
The more complicated all those details are, the more likely what you are sharing is to be lost. Whatever your message is, it’s got to be consistent.
You built an R package that does a statistical test with more power than common alternatives. Abstract: This package allows users to achieve more power when performing test X when compared to traditional methods. Introduction: Motivated by the recognition that statistical tests with lower power are less likely to detect true positives, we developed our package to enable more sensitive detection. Results: As such, we found that in datasets A, B and C, more true positives were detected using our R package than the alternatives. Conclusion: This R package is therefore useful for the discovery of real effects not found by existing tools.
Imagine trying to make that point 4 times if it was any more complicated.
Package your code (so others can use it)
Scripts are good, but a well written package (or even well structured and abstracted code) is much easier for other people to use and can be much more impactful than idea.
I think of this as a “write a paper on fishing” vs “give a man a robot that fishes for them” type scenario.
It’s surprisingly easy to turn code into a package and it looks great on your cv. It’s scary putting your code out there but there’s only so much feedback you can take to heart before you are writing good code.
Everyone has different skills and it’s ok to be a little scared about sharing your code. If you’re nervous about sharing your code, start slow. Share it first with people close to you. Ask them for help making it better and try your best to really listen. There’s only so much feedback you can take to heart before you are writing good code.
The other benefit to writing a package is that you’ll get to use it. That’s a really nice feeling and goal to work towards.
Communicate more effectively by refining with feedback
We’ve all seen characters in books or tv shows with writers who won’t let anyone read their work. In almost every case, this completely backfires.
Somehow, the authors of all these characters know that to write well, it is necessary to get lots of feedback.
Good writing, good thinking and good science are all tightly connected so it is no surprise that in all three cases lots of feedback is key to success.
Your writing, and your publications are not about what you have to say, they are about what other people need to hear. Sample feedback from your work and iterate. Make the audience your focus and you will find immediate and lasting progress.
Modelling other people on yourself means you are less likely to make your work interesting, understandable, usable or as convincing as it could be.
Taking the outside perspective without placing expectations on your readers, colleagues or users will empower you to write better papers, tools and protocols.
- Thinking, Fast and Slow by Daniel Kahneman is both a fascinating and detailed summary of the author’s Nobel prize winning on the topic of cognitive biases.
- If you are interested in biases and improving how you think, I could not recommend more highly any book except [Rationality A — Z](https://www.lesswrong.com/rationality. The author’s style can be a bit jarring, but the lessons are many with far reaching consequences.
- Writing to Learn by William Zinsser is about effective communication and provides many suggestions that will empower your writing, inside and outside of academia.