• Raghu Challapilla

Teach them so they think like us!

The dark side

I shared the below picture on LinkedIn last week, and it got a lot of attention. It does a good job of portraying the underlying mindset that leads us to take a stance of developing people (or not). Now I am going to write about the dark side of “developing our people” mindset. ​

Have you ever worked at a company where no matter how much you train people, they resist to change? You have "enforced" training sessions, tried hard to “teach” them Scrum process, Pair Programming, TDD, etc. and ended up spending a great deal of mental bandwidth dealing with your misplaced optimism.

Teach them so they think like us!

A good friend and mentor Greg once told me that it's the greatest of consulting fallacies. When was the last time we taught someone “how” to do something when they didn't want to learn and it worked? In fact people develop resistance when we try to teach them something.

[Though you can make the Training sessions fun and inspiring, as I explained it in this post: How to be a good Agile Trainer]

SCARF model

Teaching comes from a place of superiority. According to SCARF model, teaching threatens the status of the person who is being taught (unless the person has a desire to learn).

A perceived threat to one’s status activates similar brain networks to a threat to one’s life.

People don’t want to know how to do, until they understand why you are doing it. Simon Sinek explains this rule of Golden Circle in his book 'Start With Why'

I am not here to rewrite Simon Sinek’s book. It’s too good to be rewritten. I am going to explain (partially) a beautiful, elegant and effective model that is sadly forgotten. It’s called ADAPT, derived from Prosci's ADKAR.


ADAPT model explain the ideal steps through which successful changes happen. This was derived from ADKAR change management model by Mike Cohn

  • Awareness: First reflect the system to itself. Generate awareness of a problem. And wait.

e.g. If you want people to Pair program, generate awareness of the impact of “code ownership”. Show them how Jim, the code owner of XYZ module couldn't enjoy his vacation because people kept calling him for a prod issue.

  • Desire: Wait till there is enough desire to make the change happen. Evoke desire through awareness.

Turn up the heat. Reflect the frustrations around the company due to code ownership, especially due to a much needed market release.

  • Ability: This is when you give them ability to make the change.

When there is enough desire in the system to make a change happen, people will ask you how to solve their problems. Now you can talk to about pair programming - an easy/ productive way to transfer knowledge. They will probably try it. Or reject it and come up with their own solution (even better). Change is happening and people are engaged – that’s what matters.

  • Promote: Promote success stories.

To reinforce this behavior, we promote the success stories (not individuals!) Promoting success stories will not only reinforce this behavior in the teams that has succeed, but also generate awareness in other teams.

  • Transfer: Transfer the implications of this change to other departments of the organization.

Does HR still stack rank people? How will that impact the collaborative environment that teams have newly learned to live in? Does Marketing still promise “Everything in scope by this date” to their customers/ stakeholders? We need to transfer the implications of Agile to these departments so that the change will sustain.


Teaching has its place, but it only works when people want to learn. As change artists, we shouldn't rely solely on teaching/ training. My general rule of thumb: Inspire people with a purpose and let them find their own way to get there. If you did it right, they will seek your expertise when they are stuck.

And as Greg Myers says, It is not only more effective, but also more respectful and humane!

Check out my Prezi to learn more about ADAPT:


Cover image courtesy of:

Previous blog: Learning about learning: The Secret to Being an Effective Agile Trainer