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 the stance of developing our 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!
It's the greatest of all 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]
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
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 during his vacation. And wait!
Turn up the heat. Reflect the frustrations around the company due to code ownership, especially due to a much needed market release. Don’t forget to wait!
When there is enough desire in the system to make a change happen, they will ask you how to solve this problem. You can talk about pair programming, an easy/ productive way to transfer knowledge. They will probably try it. Or reject it and invent their own solution (even better). Change is happening and people are engaged – that’s what matters.
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.
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 it's 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: https://prezi.com/eetlnrxima4g/mike-cohns-adapt-concepts/
Cover image courtesy of: https://angryprofessor.files.wordpress.com/2008/12/istock_000005377886medium.jpg
Previous blog: Learning about learning: The Secret to Being an Effective Agile Trainer