Coaching the uncoachable — The "yes, but" type - why innovation!

why innovation! uses cookies to provide you with an optimal browsing experience on our website. Please check our Privacy Policy & Terms of Use to learn more about how we use cookies. By clicking on “I agree”, you consent to the use of cookies.
Sign up   |   Sign in

Coaching the uncoachable — The "yes, but" type - why innovation!

Coaching the uncoachable — The "yes, but" type
Pedro Pimentel
2 min
23 Nov. 2016
​As part of my routine as a coach, I often have to deal with different kinds of resistance. In this two part series, I aim to aggregate these different types of resistance traits I have encountered. Furthermore, you will learn most, if not all, of my trial-and-error approaches to overcome coaching/change resistance. 

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 suggest 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 coaches. Remember, there’s no one size fit all solution.


​The “yes but” person

When we first encountered this type of personality, the initial impression of the person was someone who was quite open and committed to change. After one or few interactions however, you realise that on top of nodding in agreement to everything you say, a pattern started forming. They're consistently pushing back against all suggestions, usually with quite convincing counter-arguments.
An example I faced; on a busy team, this person was the project manager. Us coaches are starting to introduce the team to Scrum ceremonies and associated practices. One such practice was using a physical white-board to visualise and track workflow. To this, the project manager 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 your mileage, this person might be quite articulated with the excuse; 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). Setting imaginary or real constraints aside, it seemed that they would gladly follow our suggestion.
To resolve a potential situation or obstacle, we must pay close attention to this person's answers as we work on identifying whether the argument they've brought 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 it is much easier to simply go ahead and change the reality rather than the perception of someone. Using the example above as the problem to solve, even though I tried setting up the board and leaving it for the team to update, they were still coming up with ‘excuses to not use the white-board.
In that situation, what I did was update the board myself for a couple of days, until people (both team members and stakeholders) started to take notice of the board. I approached them asking if it was useful for them, then proceeded to make use of the board for every team discussion, making sure to relate to items in progress or blocked and asking them to keep it updated.
In less than a month, the team started to use the board. 

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 in something, it’s not without good story-telling that you are going to be able to influence somebody. In the past, I have tried convincing developers to apply Test-Driven Development (TDD) by using data from previous projects, white-papers, blog posts and books. As expected, it didn’t work in most cases.
If they cannot synergise the content with their reality by themselves, it is unlikely they'll put any effort into learning more about it. In this situation, you can still use use hard facts but try to tie them with your own personal story. Make it personal. Make it relatable. 
The main thing I want you to remember is:

To change, is to change twice: the reality and perception.

More Blogs