Establishing a PM culture in a tech startup that was all over the place was a strenuous job for me to say at the least. I initiated it with the use of Trello so that there is a proper visualization or perspective of project status to all the team members. Have shared my bit of research and learnings on PM in one of my last posts as well.

When I pitched this idea to my team, a bunch of techies viewed me like an arch enemy or an alien trying to dictate their work environment. (Typical scenario of how people look at Project Managers worldwide) Strange as it is, I wasn’t even working as a dedicated PM but only wanted to establish a culture since the team was growing big.

However, I have had the best of friends as techies so I am familiar with getting my way with them.  I convinced the team with the need of tool and so the culture began. The next job was to make sure the discipline of maintaining the Trello cards and commitment to the due dates.

The most challenging task of all was to make the team label the Trello cards from a problem-solving point of view in the user story language. It made sense for the Trello cards to be labeled this way especially because we had a cross-functional team in the project from various domains like operations, marketing, and development. To re-emphasize this, I had even named the entire Trello board as user stories.

However, there never came a day when the cards in the Trello board were labeled completely into user story language. (which would have been my dream come true lol)

I tried to identify the issue as to why this was not happening. Astonishingly, there was no reason at all, in fact, the team believed they were labeling all the cards in the user story language.

Here are a few examples of how the Trello cards were being labeled by the developers. I would have to alter each card name in the user story language one by one.

Below, the card named by the devs are represented with a question mark and the altered one with a green tick.

Example 1

         

 

Example 2

         

 

Example 3

           

 

I am not saying how devs were naming the cards makes no sense but I simply believe that something like “socket sync issue” could have been a part of description inside the Trello card.

However, I connected this problem to the concept of curse of knowledge.

The Tapping Experiment

I had learned about a tapping experiment conducted at Stanford University by Elizabeth Newton. A simple game in which people are assigned to one of two roles: “tappers” or “listeners.”

The idea was to make the tappers tap songs and listeners identify the songs.

Before the listeners guessed the name of the song, Newton asked the tappers to predict the odds that the listeners would guess correctly. They predicted that almost 50 percent should be able to guess the right tune. But out of 120 songs tapped in total, Listeners guessed only 2.5 percent of the songs i.e 3 out of 120.

Apparently, it so happens that when a tapper taps, they expect a lot of people to understand what song they are trying to communicate because the tappers have the song in their head. It’s impossible to avoid hearing the tune in their head because they already know it. While all listeners can hear is disjointed taps. This is what psychologist call the curse of knowledge.

Many times, we communicate our ideas assuming that the audience shares our knowledge. This makes our communication ineffective, people are confused or tend to misinterpret or not get at all. The curse of knowledge is the reason why many scholars write papers that almost no one understands because rarely does anyone have that level of knowledge.

Linking the same situation in the context of my article, the developers tend to think in a language that they write code in,  without realizing that everyone else in the team would not think the same way.

I dug deeper into how to deal with the curse of knowledge and found a book called Made to stick by Dan Heath and Chip Heath which unfolds how to handle this curse better.