- Resisting the Urge to Provide Unsolicited Expertise
- Handling Explicit Requests for Expertise
- Sharing the “Minimum Viable” Amount of Expertise
- We All Have Blind Spots
- Applying a Coaching Mindset to Teaching
- Creating a Self-Serve Knowledge-Sharing Environment
- Guidelines for Sharing Feedback and Expertise
- Additional Considerations for Sharing Feedback and Expertise
- Receiving Feedback as a Coach
- Chapter Summary
We All Have Blind Spots
As an Agilist, you have a “superpower.” You have an aptitude for Agile, have spent time taking Agile classes, and have more experience with Agile than many other people. When you observe a standup or retrospective, you will see things that others don’t see.
Let’s say you see team members showing up late to the standup and also grumbling about the start time, even though that’s the start time in their team agreement. You see some discussion on the late start that isn’t leading to a resolution. Based on your experience and where this team is at in their Agile journey, you feel they need to revisit their team working agreement. Although they often refer to their team agreement, it has been a while since they have updated it. During that time, there have been some changes to both the team and their environment.
If, based on your observations and experience, you suggest to them that they revisit their team agreement, they may go along with you. And perhaps it will help. But the question here is this: Why didn’t they think of this on their own? Is it because they forgot about the team agreement? Is it because they don’t actually value it? Is it because they haven’t built the habit of regularly revisiting their team agreement? Or is it something else?
Instead of sharing your conclusion based on your observations and experience, share what you saw that started your thought process and see where it goes from there. You might say something like this: “May I offer an observation? Yes? OK, I notice quite a bit of tension around the start time of the standup. Considering that the start time is in the team agreement, I wonder what might be going on?”
There is no point in making observations, providing feedback, or sharing expertise regarding things that are in the receiver’s blind spots. First, you need to find a way to raise their awareness of the blind spot. By focusing on what they can already see, you show that you are listening to them and focusing on them, and you build trust and rapport.
Here’s another example, but this time the blind spot is in a coach. I (Damon) was overseeing a coaching engagement where the embedded coach was at risk of being removed from the engagement. I went to talk to the coach and asked what was going on. The coach said, “They just don’t see it!” I asked, “What don’t they see?” The coach said, “They are losing so much money and opportunity by not doing DevOps.” I asked, “What is it that they do see?” The coach said, “Oh, they have a whole list of things they want help with.”
About a month later in a follow-up, the coach said, “They are starting to see how fragile their deployment process is and are starting to ask how continuous integration and continuous deployment might help.” As the team learned more and took care of what they saw quite clearly, other impediments and potential improvements became visible to them.
When you are observing a team or an organization, consider the model of blind spots, as shown in Figure 4.3. Keep in mind that what you see and what they see are different. Look for impediments and opportunities for improvement that both you and your coachees see, and then focus on these first. As you build trust and increase the coachees’ Agile knowledge and experience, the scope of what you see in common will expand, and their trust in your coaching and Agile expertise will expand as well.
Figure 4.3 Blind spots