The curse of knowledge is a cognitive bias that occurs when we communicate with others and assume they have the background to understand. Colin Camerer, George Loewenstein, and Martin Weber first described this bias in a 1989 paper titled “The Curse of Knowledge in Economic Settings: An Experimental Analysis.”

The concept gained prominence through a series of experiments by Elizabeth Newton at Stanford University in 1990. Newton’s experiment involved a simple but revealing task. Participants were assigned roles as either “tappers” or “listeners.” Tappers were asked to tap out the rhythm of well-known songs while listeners tried to identify the songs as the first person tapped. The tappers predicted that listeners would guess correctly about 50% of the time. In reality, listeners only identified the songs correctly about 2.5% of the time.

This stark difference between prediction and reality demonstrates how knowledge of something (in this case, the song) creates the illusion that the information should be obvious to others. The tappers could hear the music in their heads as they tapped, but the listeners only listened to a series of disconnected taps.

The implications of this bias extend far beyond simple communication exercises. It has been observed in various fields, from education and management to product design and marketing. The curse of knowledge highlights the challenges experts face when sharing their expertise or creating products for those with less knowledge in their field.

In the context of software teams, the curse of knowledge can profoundly affect how teams operate and communicate. When team members all have different levels of expertise or knowledge about a subject or a project, it can lead to misunderstandings and inefficiencies.

For example, engineers might struggle to explain technical concepts to designers or marketers who lack the same technical background. This can result in miscommunication, leading to design decisions that don’t align with technical constraints or marketing messages that don’t accurately represent the product’s capabilities.

Stakeholders who are deeply familiar with a product might urge the team to build features that make sense to them but are confusing to new users. They might incorrectly assume that users will intuitively understand how to navigate the product.

In team dynamics, the curse of knowledge can create friction between team members with different areas of expertise. For instance, a senior team member might become frustrated with a junior member who doesn’t grasp concepts quickly, forgetting their own learning curve when they were starting out.