Coaching the Uncoachable — The "yes, but" type
As part of my routine as a coach, I often have to deal with different kinds of resistance. Over the coming weeks, I aim to aggregate the different types of resistance traits I have encountered so far. Furthermore, you will learn most, if not all, of my trial-and-error approaches to overcome coaching/change resistance. Certainly you can find proper research of the types I mention here but this series of blog posts also works as a reminder to myself :)
List of resistance types I have seen so far:
- The “there’s no problem” type
- Something or someone else is the problem
- The “yes but” person
- Overly sensitive, taking it personal
- Doesn’t take directions well / Doesn’t understand what you say
- Bad memories from coaching
- The too busy to change
Bear in mind that everything I suggested here is strongly dependent on the context of your coaching engagement at the team and individual levels. At the end of the day, it’s up to your own judgement to try them with your coachees. Remember, there’s no silver bullet :)
The “yes but” person
When we first encounter this type of personality, we feel she’s actually quite open and committed to change. After one or few interactions with her, you realise that on top of nodding in agreement to everything you say, you start noticing a pattern. She’s consistently pushing back all suggestions, usually with quite convincing counter-arguments. An example I faced; on a quite busy team, she was the project manager, we (coaches) are starting to introduce the team to Scrum ceremonies and associated practices and she might say:
I think it’s a great idea having a white-board to reflect our workflow and track ticket’s progress but we are already using an online system for that so I don’t want my team to waste time in keeping two different things up to date.
Depending on the person, she might be quite articulated with the “but” part of it. Opposed to the “i’m too busy” person, this type of individual wants to show they are actually aware and understanding of what we coaches suggest (or at least pretending well). Setting Imaginary (or real) constraints aside, it seems they would gladly follow our suggestion. We shall pay close attention to her answers as we work on identifying whether the argument she’s bringing is a constructive critique or simply a well elaborated excuse to avoid change.
I really appreciate your suggestion but…
Some actions I have tried with this kind of personality are:
Change the reality, work on the perception later
Quite often is much easier to simply go ahead and change the reality rather than start changing the perception of someone. From my own example above, even though I tried setting up the board and leaving up for the team to update, they were still coming up with ‘but’ reasons to not use the white-board. In that situation, what I did was to keep the board updated myself for a couple of days, till I got moments where people (both team members and stakeholders) were staring at the board and I’d approach them asking if it was useful for them to get such information, I then proceeded to make use of the board for every team discussion and making sure to relate to items in progress or blocked and asking them to keep it updated. In less than a month, the team got used to update the board and making use of it.
Help remove any impediments
Imaginary and real blockers are part of any team becoming more Agile. As an outsider, and furthermore as a coach, we tend to question and go deeper on why things are done in certain ways. With that approach, we are able to identify most of the blockers that the team might be using as an excuse to avoid change. Those are relatively easy to work on. For example, the team relying on application security scans from other teams/vendors; we can show that they can scan themselves their code against vulnerabilities (and fix any issues right away) without having to wait for a big and possibly expensive hand-off later on.
Tell a story
As much as people like to rely on facts to believe on something, it’s not without a good story-telling that you are going to be able to influence someone. In the past, I have tried convincing developers to apply TDD by using data from previous projects, white-papers about it, blog posts and books. As expected, It didn’t work in most of the cases. If they cannot resonate the content with their reality by themselves, we know they won’t dig further on using it. In that situation, you can still use use hard-facts but trying to tie them your own personal story. Make it personal.
The main thing I want you to remember is:
To change, is to change twice: the reality and perception.
Have you encountered this type of resistance before? How did you solve it? Leave your comment with your approach and let’s discuss :)
