The Curse of Knowledge bias: Why Stakeholders Don’t Understand Our Ideas

The Curse of Knowledge bias: Why Stakeholders Don’t Understand Our Ideas

by | Aug 10, 2020 | Agile, Coaching, Delivery Leading | 0 comments

I often play “tap and guess” with my son. In the game one player taps a song and the other one has to guess which song or poem it was. You can tap either a table or a box or the other player’s back or head.

If you’ve played this game, then you might have experienced that it is extremely hard to guess the song that your partner is tapping. My son always questions why I couldn’t guess the song which was so easy and obvious to guess. What he doesn’t realise is that while he is tapping, he is also singing the song in his mind. Actually, you cannot help singing or at least hearing the tune in your mind if you are the tapper. Try it, it’s really fun.

The game tap and guess

Let me be honest, I’ve had some good guesses at the songs that my son tapped. Why? Because he seems to be tapping only a few specific songs and rhymes including “Old McDonald had a farm,” (I know you’ve continued with an “E-I-E-I-O!”), “happy birthday to you..” and a couple more. However, he never ever guessed a song correctly that I tapped. Exactly like others who played this game with us.

It is very difficult to be a listener and a tapper. As a tapper you believe that what you’re tapping is obvious and it’s frustrating that your partner is unable to guess such an obvious thing. As a listener all you hear is random tapping on the table.

So why do tappers believe that what they were tapping was easy to guess? Because they already know the song. They have knowledge and they cannot imagine what it was like to not have it.

And this is where we learn about Curse of Knowledge bias.

What is Curse of Knowledge:

The curse of knowledge is a cognitive bias that occurs when an individual, communicating with other individuals, unknowingly assumes that the others have the background to understand. This bias is also called by some authors the curse of expertise, although that term is also used to refer to various other phenomena.

For example, in a classroom setting, teachers have difficulty teaching novices because they cannot put themselves in the position of the student. A brilliant professor might no longer remember the difficulties that a young student encounters when learning a new subject. This curse of knowledge also explains the danger behind thinking about student learning based on what appears best to faculty members, as opposed to what has been verified with students. – Wikipedia

(Chip and Dan Heath have explained Curse of Knowledge in their book Made to Stick through the same game but in a different context. In fact, it was this book that Made this concept popular. Their book is worth reading if you want your ideas to be more sticky.)

How does the Curse of Knowledge bias apply to our workplaces?

You might recognise the expressions below.

“It’s not that complicated, but they don’t get it. Everything I am trying to do is in their favour and will be beneficial to them, but still they are resisting it. What is wrong with these people?”

As a consultant I have heard it from people I have worked with and I often hear it from many others. Some of these people are senior management folks, others are managers, team members, people from business teams etc. Each of them have attempted to do something which was faced with resistance.

We know that change is hard. Yet sometimes we try to either push a change or hope that people will simply accept the ideas, our ideas, that will benefit them because there is merit in them.

One thing that we now know is that some of our ideas don’t get accepted because possibly we are the tappers and our audience are the listeners. What seems obvious to us, might just be random jargon to others.

What can we do about it and are there any solutions?

Dan and Chip Heath suggested two ways to beat the Curse of Knowledge in their book. One is not to learn anything. Two is take your ideas and transform them. I’d suggest that you read their book to learn more about their suggestions.

For the scope of this post, well not focused on their ideas. Instead we’ll look slightly deeper in the subject and explore what we can do.

Why don’t they get it?

There can be a number of reasons why people don’t understand your ideas. Some of them I have listed below:

  • You’re barking up the wrong tree: You haven’t clearly defined who your audience, stakeholders or customers are. Are you talking to the wrong people?

  • Your message is complex: Even though you have the right audience, your message is complex or complicated.

  • You are seen as an outsider: It is a normal tendency that we prefer listening to or paying attention to only those who we trust. In fact, a number of initiatives to improve health and well-being of communities failed because the initiatives involved external experts and volunteers. (Initial efforts to eradicate the Guinea worm disease from African countries failed because villagers often didn’t trust the experts).

  • Time crunch: Your suggestions can solve a big problem, but that might take a long time to be effective and they don’t have patience to wait that long.

  • Short term gains over long term benefits: The Stanford Marshmallows experiment suggested that there are benefits of delayed gratification. However, your customers might be focusing on the short term solution than a problem or benefit coming in long term.

What can we do?

  • Understand the context: it is vital that in order for others to understand us, we understand them and their context first. When we behave purely like tappers, we limit our ability to understand a context holistically. System mapping can help in learning about the context.

One of the aviation organisations I worked for, brought in an executive from a large financial institution to lead a transformation. This executive applied his learnings and solutions from the financial institution to this organisation. Since everything was different, from the culture, the country, the people, the processes, to the technology; the so-called tried and tested solutions that worked at the financial institution, didn’t work at the airline. There was tremendous waste of resources.

  • Don’t be an outsider: if you offer your ideas as an outsider, the chances are that they’ll not be accepted because you’re seen as an outsider and a trusted relationship is not established yet. Once you understand the context, find ways to build and establish a relationship of trust. Of course the scenario would be different if you’ve been invited to offer your opinion.

  • Find the ‘Early Adopters: (refer to Winston Royce’s Diffusion of Innovations theory). The early adopters are those who have understood your ideas and see the benefit of applying them. They’re often the opinion leaders who others not only trust, but also listen to their opinion. They have good influence over their people.

  • Avoid cookie-cutter approach: Take help from those who don’t impose an approach. While your organisation may not be unique, your context would be different than others, even though your industry or domain might be similar to others. Each organisation has its own dynamics. If you or the consultants you bring in don’t understand that specific dynamics, the solution they propose will fail.

In this post, I have discussed problems that we face at workplaces when our stakeholders or colleagues do not accept our ideas. Some of those ideas even benefit them. But they don’t understand the value of those ideas possibly because they don’t have the knowledge that we possess.. What should we do?

The text above has offered some suggestions too. These options have helped me in the past, both in dealing with my own curse of knowledge and also in having more empathy and patience while working with “listeners”.

Everyone comes from a different background. A little empathy goes a long way.

Are there other options or ideas that you have used as solutions that have opened doors for you or have solved problems for you in working with others? What are those options and what did you learn? Let me know.

Agile team practices that showed us immediate results

Agile team practices that showed us immediate results

by | Jun 16, 2020 | Agile, Coaching, Productivity, Visualisation | 0 comments

There are times when culture and the practices that a team follows (or does not follow) start affecting their delivery work, primarily in Agile teams. Non-essential meetings, unplanned or unwanted catch-ups, feeling lack of safety that forces people to keep record of things such as emails, are often part of a bigger problem.

As a delivery professional (Lead, manager, Scrum Master and in some cases even product owners), your responsibility is to ensure that your teams delivers the valuable outcomes, at frequent intervals and with a sustainable pace. This responsibility also includes protecting them from non-productive tasks and mentoring them for de-prioritising non-value adding tasks.

Unfortunately, sometimes teams do not even realise that some of their practices were slowing them down. This often happens because of a rigid mindset that is ingrained in their organisations and the cultures. And as you might already know, it takes time to change behaviours and attitudes that become norms.

The good news is that you can possibly change that mindset.

How do you do that?

The answer lies in the teams. Teams are built of people, and people prefer to stick with social rules. In fact, it is often hard for people to oppose or show resistance to norms of a group that they are part of. As an Agile delivery leader, it is in your and the organisation’s interest that you encourage your teams to develop a social contract or a working agreement. These contracts define how the team members in a team prefer to work together and what they find as acceptable behaviours. Since everyone in a team contributes and agrees to the principles of a social contract, it is also easier to improve practices that affect them most.

Just to be clear, these social contracts are not legally binding agreements. They are there to enforce the values and principles that people in a team believe in and agree to adhere to. 

I was working with this team of nearly fifty people as a delivery manager. The team was consisting of four product streams and there were interdependencies. We were facing some common challenges regarding the day to day functioning of the team. Through the retrospectives, I came to know that there were few common patterns across those streams where the teams were feeling the pinch.

I was able to break those patterns in four themes: 

Productivity (and process improvement)

Culture (behaviours & attitudes)

Development & growth 

Clarity of Mission

All of these themes can be summarised in some of the key challenges:

– Too many meetings. Many of which unplanned and go on for too long

– Lack of agenda and expected outcomes in meeting requests

– Lack of a medium for team members to appreciate their colleagues across the program

– A need for a common platform for the whole team to come together and share ideas

– Finding time for training or capability uplift

– A need to know each other better which was a challenge due to the size of the group

– Clarity of roles at program level

 

Here’s how we solved the problems:

Productivity + process improvement:

There were too many meetings and this large number of meetings was not only affecting productivity, it was also impacting delivery schedule. Since meetings were reducing productivity, team members were also getting visibly annoyed. 

This is what the team decided to do:  

  • No one within the team was allowed to schedule meetings after 3 PM. What that meant was that people get unrestricted productivity time after 3PM.
  • Everyone in the team agreed that each meeting request will have a clear agenda and if possible, the outcome they were looking for. 
  • We also attempted to limit the meeting times. That is, any 30 minutes were planned for 25 minutes and any 1 hour ones were planned for 45 minutes.
  • We also asked people to come prepared so that their messages were concise and crisp.
  • We emphasised on face to face conversations whether people were onsite or working remotely.  

We kept an eye on these practices for adherence and ensured that everyone, specifically the senior team members behave like role models.

Culture:

The program director and I were closely aligned on the values that everyone in the team adheres to. Having a shared understanding at the management layer certainly ensures how each member of the team will behave.

  • We encourage team members to be completely open and honest in retrospectives and otherwise too. We also made sure that our own behaviour reflects what we were advocating for.
  • I attended and at times facilitated team retrospectives. What was motivating for me was that often team members approached me after the retrospectives showing their appreciation for making them feel safe in those sessions. Team retrospectives were purely for the team members and neither product owners nor anyone from the program team were allowed to attend unless required.
  • We made sure that the program management team accepts the improvement areas and takes actions. We circulate those actions to the team members so that they can see the congruency.
  • We also ensured that we provided regular updates on the status of the action items.    
  • To encourage peer to peer appreciation, we introduced “Kudos cards” in the program. When we introduced the cards, we also explained why there was more value in appreciating those who deserve and why a reward system from management does not work. 
  • Monthly retrospectives: Due to the interdependence within the streams, it seemed vital that the whole team has a common retrospective. Team retros also reflected that need. Hence, we decided to schedule a monthly retros for the whole team. In these sessions everyone in the team came together to share ideas openly and respectfully.

Development & growth:

Many project or product teams do not have additional budgets for training for their team members. Depending on the structure of the organisations, team members might belong to different specialist groups that are responsible for their professional development. Sometimes People and Culture (a.k.a HR) teams are responsible for arranging training. Dealing with some of these processes can be cumbersome due to bureaucracy. So what do you do then? Well, see how might you get your team some training and mentoring. We found the answer in some unconventional ways. We agreed that you don’t always have to separate training from ‘business as usual’. Therefore:

  • We build small pockets of training time in each team event. We had a quarterly team events calendar and we specified training time in the calendar. For example, to enhance team collaboration, we added a ‘personal mapping’ exercise in a monthly showcase. Easy! 
  • We placed a flipchart in the project room with suggestions as well as space for other ideas. Team members could either opt for an existing training sessions or could suggest a new one. There was enough autonomy to add anything and we did see some funny suggestions too.
  • We made sure that there were options for lunch-time sessions, brown-bags, separate training and even ad-hoc sessions. Once we organised a session on user stories by extending our stand up to an extra 30 minutes. What you might find hilarious that we expected 5 attendees, but nearly 25 people showed up. 

 Clarity on roles: 

Sometimes within large teams, where you are adding new members regularly, it is difficult for team members and leads to explain various roles (just to be clear, I’m not talking about titles here). In our case, we had data architects, data engineers, CX designers, UX designers, delopers, testers, business analysts, solution designers, legal counsels, procurement people, scrum masters, product managers, domain architects and others. With so many roles, not only explaining them can be hard, but also keeping them clear to avoid overlaps. You don’t want people unknowingly stepping on each others’ toes. Neither you want any frictions among team members, no matter how psychologically safe you believe your team is. We’re all humans after all!       

  • We created a team structure chart that clearly showed who was working on what. We also made sure that the chart shows which stream people belonged to. We circulated this chart to everyone in the team and also added it to our induction pack that we shared with all new team members. 
  • Although I am not a big fan of RACI matrix (responsible, accountable, consulted, and informed), it deemed necessary to us to create one. Of course we consulted our team about what they thought about it.
    Why I’m not a big fan of RACI matrix? Because these matrix define linear responsibilities. That is, one person =  one specific role. If you are a self organising team, you may have team members playing different roles. However, having this chart helped us bring more clarity about roles and it also reduced overlapping and multiple channels of similar conversations. Additionally, team was clear that their self-organisation wasn’t at risk.
  • Skill matrix: Now this is something that was interesting.  I had used skill matrix before to create cohesive, well designed, self supported teams. What a skill matrix does is to show the availability, lack of and level of expertise for a particular skill. For example, you may have someone very experienced in C++ and you may also have someone willing to learn it. As a lead, you can take actions to balance the skill shortage. For me, this experiment failed as no one ever willingly added their skills. I also trouble validating why that happened. Anyways, this was added to our ‘Failure log’.

As you might have noticed, we solved many of our problems by bringing people together. Creating common understanding was our first step in ironing out some of the challenges we faced. We also did a number of experiments and not all of them were successful. However, keep running short experiments, validating them through feedback loops and not losing focus from your primary goal can do wonders for your team. 

Did you do something similar in your organisation? How did that go? Let me know in comments.  

It’s not Agile that fails organisations. It’s the organisations that fail at agility

It’s not Agile that fails organisations. It’s the organisations that fail at agility

by | May 8, 2020 | Agile, Coaching, Culture, Leadership, Management | 0 comments

Agile has been touted by people (who understand it) as an approach, a value centre, a mindset and philosophy. Those who understand, have been observing some interesting posts and discussions going on social media that claim that Agile has failed in their organisation.
If we regard Agile as a tool that a team or organisation might choose to use, then perhaps we can understand the failure of Agile for that organisation. That’s be similar to any other tool that an organisation might use.  Sometimes tools work, sometimes they don’t! Understood! A hammer can certainly fail a carpenter if it breaks during carpentry work. But, if the carpenter does not know how to use a hammer, it is not the hammer’s fault, or is it? (Just too be clear, this analogy does not represent Agile as a tool).
Let’s not jump too prematurely to any conclusions. Instead, let’s try to cognitively analyse if there is a problem here. Jerry Weinberg’s Rule of Three* states that if you can’t think of at least three different interpretations of what you have received, you haven’t really thought enough about what it might mean. Another version of this rule that my friend Jari Laakso suggested was, “If you can’t think of three things that might go wrong with your plans, then there’s something wrong with your thinking.”

When someone says that Agile has failed them (in other words, their Agile way of working was not successful), the actual problem might have been:
They don’t know enough about Agile and they tried to “do Agile” rather than “be Agile”.
They thought that they knew about Agile and implemented it the way we knew it. What they did didn’t work. (Rajesh’s note: you don’t implement Agile in the same way you don’t implement truth.
They thought Agile was predominantly about specific practices and conventions: using post-it notes, having daily standups, having sprints and not much else. Despite those they couldn’t deliver anything.In some contexts, any (or all) of these cases may have been a key contributor to the failure of Agile.
What troubles me is that many people who blame an approach or a methodology, do not in fact try to first understand that approach or methodology.** There was a mention of waterfall methodology somewhere and most people in the discussion did not know about waterfall’s origin. Someone mentioned Winston Royce and disappointingly it turned out that even that person had selective take of the paper and decided to conveniently forget about the last few sections of Royce’s paper which are very important.
More often than not, Agile methodologies are implemented incorrectly. Some implementers don’t realize that there are Agile values and principles (Jari reminded me about ScrumButs). Some have not taken time to look at and understand the Agile manifesto. Many Scrum Masters never looked at The Scrum Guide. Some didn’t even know it even existed. I have done this experiment of asking anyone who mentions Agile whether they have actually read the manifesto. A large number of those had not. Many of those who had read the manifesto, did not try to  understand it well. Sadly those who understood it, could not implement what an approach as outlined by the Manifesto, because their organisations weren’t ready.
It is indeed often easier to blame a methodology or an approach. Agile adoption and implementations of related frameworks can fail for many reasons. What is important is to investigate what went wrong and whether that could be avoided. Even more important is to understand an organisation’s culture and whether the organisation and the approach are good fit for each other. Jerry says in his second rule of consulting, “No Matter how it looks at first, it’s always a people problem.” A good Agile coach might be able to help bring a mindset change if not the culture change.

So, as often the case may be, Agile hasn’t failed you, you may have failed Agile.

 

* The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully

 

** http://www.slideshare.net/EmielVanEst/did-toyota-fool-the-lean-community-for-decades

Why improving culture can bring dramatic results

Why improving culture can bring dramatic results

by | Oct 21, 2019 | Coaching, Culture, Systems thinking | 0 comments

 

It is not surprising that at many organisations, mainly in difficult cultures, management teams increase their focus on individuals and teams when things do not work out. They believe that to resolve any issues or to improve a situation, they need to fix people. While in some cases people related issues might need to be resolved; in many more cases leaders should focus on  improving the systemic issues and the culture of the workplace.

 As a delivery professional, and specifically as an Agile delivery professional, you will face situations where things will not be working out for your teams. There can be many reasons behind those issues, but pay special attention to systemic and culture issues. This post helps you decide whether to be a part of the problem or be the wise person who offers solutions.

 Have a look at this famous quote by Alexander Den Heijer*: 

 “When a flower doesn’t bloom, you fix the environment in which it grows, not the flower.” 

 What this quote symbolizes is what happens at many workplaces. We see that when a problem appears, the management teams get so involved in the lower level details that it becomes harder for them to see the forest for the trees. In other words, they can’t see the bigger picture. This results in either applying short term fixes or fixing the wrong problems.

 It is true to an extent that many managers find it rather simple to find faults in the teams. Local fixes are easier to apply and they can be shown as quick wins. These quick, local fixes are the low hanging fruits and they are quite attractive because they make managers look good in front of their peers and superiors. It’s amusing how culture of a workplace can affects people’s behaviours.

 It is hard to identify and detect systemic issues. When managers have a narrow view of things, when they are not trained in looking at the bigger picture and think critically, they tend to ignore the signs that the system might be showing them. The issues might be with systems, suppliers, other managers, expectations, equipment, skills or any other things.


Challenges for organisations and delivery folks:

 The challenges that organisations and teams face in solving long term problems are:

 – attractiveness of applying the quick fixes
– incompetence of managers in identifying the right problems, and
– ambiguous nature of systemic issues

Below is an example from my personal experience how management ignores systemic issues and focuses on low level details.

I was once invited to a financial institute to do an assessment of how the Scrum Masters were performing there. The person who commissioned the work told me that the company wanted their teams to improve. Through this assessment, they wanted to see which areas needed further support or training. But, being a sceptic, I was curious to know whether the management was genuinely interested in helping their teams improve or this assessment was a ‘performance review’ in disguise. I didn’t know whether this activity was also going to be used as a ‘right sizing’ tool.

 My assessment process included interviewing various people to get a holistic sense of the working environment. After meeting the scrum masters, program managers, product owners, peers and colleagues, I noted that there were many improvement areas. One of them was additional training for scrum masters, but there were many others which were more work-environment related. What was interesting was that these folks had no control over the issues affecting their work. Most of the problems that were slowing the teams down and impacting product delivery had nothing to do with these scrum masters. Almost everything was an organisational issue. 

When I sent my report to the person who commissioned the work, she completely ignored the recommendations related to the organisational issues and decided to action only what was written about the team members. 

As expected, nothing actually changed for them.

 

What should leaders focus on?

 Local sub-optimisations can only produce sub-standard outcomes. If you are an executive or a delivery manager, don’t spend much energy on improving efficiency and productivity of individuals (or individual teams). Those things have limitations. Although you do need to solve the immediate issues. Once that is done, Instead, try to understand the dynamics of your systems. If you face a challenge, pay attention to how your overall system is behaving. 

 Can you pick different sentiments in people’s attitude? Do you see that vocal team members have stopped talking? Are teams reluctant in experimenting? Have the number of sick days increased? Have people stopped challenging you or offering suggestions? Has productivity dropped? Is the work produced by teams appear to be of lower quality than it was before? Do you notice a lack of collaboration and cohesion among all levels of people and teams? Have people started keeping record of interactions ‘just in case’ if they had to ‘prove’ something? Has the learning stopped?  

 The list of questions can be very long. All of these questions are the symptoms of larger problems.

 It takes time and effort to understand the patterns and behaviour of a system, but the results, impacts and effects are often better & long lasting.

 How to identify and action systemic issues:

 As a delivery professional, it is imperative for you to learn and experience practices and techniques for systemic issues. Initiatives, projects, assignments and products can vary in size and complexity. You will have to choose the right tool for the right context. I have provided some suggestions below. 

 Systems mapping: Most initiatives have dependencies and interdependencies on a variety of things. These include people, processes, vendor suppliers, equipment, government compliance and regulations, technology, market forces etc. 

 It is a good idea to create a systems map to understand the breadth of your solution. Specifically for large initiatives with multiple touch points, creating a systems map is vital. Once a basic map is ready, other team members can add details that you might have forgotten. Systems maps help leaders see the forest and not just the trees.

 Group mind mapping: You can start your project with a mind mapping exercise with the core members of your team. A mind map not only helps you develop your ideas, it also helps you reveal the potential outcomes or problems. 

 Brainstorming, decision making and problem solving techniques: I have used techniques such as Lotus Blossom for decision making and problem solving. Lotus blossom is a structured way to explore areas which are high stake and require deeper thinking.

 Collaboration techniques: To improve the culture of your organisations, you should apply team collaboration techniques that improve coordination and psychological safety. Once your team members feel safe to speak out and share ideas, you will notice the substantial benefits for your projects.

 You might already know many of the suggestions I have provided in this article. My job was only to give you a nudge and hope I have done that through this article. What has been your experience at applying practices that have helped you improve the culture of your team or the workplace? Please share your ideas in the comments below. 

* Alexander Den Heijer is a well known motivational speaker and the author of Nothing you don’t already know: Remarkable reminders about meaning, purpose, and self-realization