I once sat in an iteration review where the recently completed work for an API was being demoed. The demo covered a lot of ground around technical implementation.
At the end, it was asked if there were any questions. No one said anything for about a minute. Then the CEO, who had been attending iteration meetings for the project, said, "I have no idea what I just saw. Can our client integrate with our system yet?"
With a good heart everybody on the team tried to help the CEO understand what he'd just seen. The waters only got muddier with each attempt to share an explanation, analogy, or metaphor. Confusion led to frustration and the CEO, obviously discouraged, shared, "Maybe I'm just not smart enough to get it."
This was a problem. It was no secret that the CEO would be present throughout the project as he was fulfilling the product owner role. The demo put off-kilter the rhythm the team had achieved during their earlier iteration.
The CEO is smart enough to get it, but he didn't. The team is smart enough to explain it well, but they weren't. Good progress was made on the iteration; so what happened to derail the review, the planning meeting, and the team's momentum?
In my experience, this was an issue of communicating without considering your audience.
This is what commonly happens when you take someone who knows a lot about a particular topic (the expert) and ask them to explain it to someone who knows much less (the novice): the expert communicates in language they're comfortable with and the novice is left scratching their head.
It may seem like a simple challenge to overcome, but it's actually quite difficult. Experts often have a hard time remembering what it was like to NOT know. This doesn't mean they, or you, should oversimplify anything because that can create its own set of communication issues.
I've found spending just a little bit of time considering what everyone is looking to get out of a meeting helps immensely. Considering the motivations and viewpoints of others will help the expert find the right information to communicate based on what their listeners are interested in.
Here are two questions that might help put one in the right frame of mind to achieve this:
- What is the other person looking to get out of this?
- What do I know that will help them reach that outcome?
Answering these questions helps construct a narrative better suited for the audience. Any other details can be used to support those narratives.
Let's take the iteration review and try to answer these two questions. I'm going to focus in on the CEO, but this could be applied to the team as a whole.
First, what is the other person looking to get out of this?
The CEO is interested in knowing how close we are to letting their first customer integrate with the system. This had been something he and the rest of the business team had communicated a lot over the past few weeks.
Second, what do I know that will help reach that outcome?
I know that the customer hasn't integrated yet
I know we've sent them the first draft of the API documentation
I know the work we completed will allow the customer to begin integrating in the next iteration
And I know that we're going to be incrementally pushing updates for more API functionality for the next few iterations.
Before reading ahead to see what I came up with for the narrative take a moment to consider what you think the narrative might be. Remember–there's no right or wrong answer. The goal of the activity is to help us move toward improved communication.
Here's the narrative I came up with:
Communicate: where the customer has progressed to with regard to integration with the API, how recently completed work explicitly helps the customer get closer to integrating now, and how this work affects integration in the coming weeks.
The narrative is high level, avoids "dumbing down", and provides opportunities for more details to be communicated in the context of bigger picture goals and interests. It provides a structure that connects the content of our message in a way that we think will resonate with the audience. That's hard to do without considering what our audience really wants to know.
Had the audience been considered for the iteration review at the start of this post, it and everything that followed would likely had a very different outcome. The team would have spent less time finding their rhythm because it would likely have never lost it.