Why won't this work? Antidotes to resistance

From CitconWiki
Revision as of 14:56, 3 October 2012 by Mentalartist (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Common reasons of Why can't this work?

  • We're afraid of change.
  • Sunk cost. Because we're already paying for X product, and we want to use it. But could save money by dropping it.
  • Helpful NLP (NeuroLinguistic Programming) Books
  • Because our teams are in separate locations.
  • No permission support. "Our managers won't let us."
  • Our developers will rebel against a new process
  • Everyone will quit.
  • We don't have time. We're under pressure to deliver.
  • It's legacy. Lots of technical debt. Lots of stuff runs on batch processes.
  • Because that's not scrum. That's not agile.
  • What's in it for me? Why?
  • It might make me look bad.
  • I don't own it. Not my problem.
  • Where's data that will prove that this work.
  • We don't know how
  • Only works on toy projects
  • We don't have a problem
  • That's too much new stuff. Quit teaching me these new things.
  • Hard sell to have people try synchronous integration
  • People should just do the right thing without it.
  • That's not enterprise technology.
  • We should detect that in code review
  • We have smart people we shouldn't be telling them what to do
  • Can't prove the ROI on my stuff. Seen it on the data, but can't prove that
  • It's too much work.
  • Because we've followed the path of least resistance
  • Resisting planning ahead and gantt does
  • My ____ doesn't care
  • It'll slow us down.
  • That's hard
  • We only have a few users


Antidotes

What is "this"? Missing referential indexes - "This" is generalized, and not specific enough.

Most of these sound like false objections. Sometimes we should honor where these are coming from. Asking for help is an awesome thing to do. These are not constructive objections.

First objection you hear is always a false objection, and it's not the real objection. The first answer is trying to get rid of you.

Objections arise from a failure to establish value. Not establish problem that is serious enough to solve. Objections come from emotional reasons, and they are not from a rational perspective, and need to be considered from an emotional perspective.

Need to live in other person's shoes, and see what their concerns are form an emotional POV.

List of eight common sales objections. If you can't talk to these eight points, then you won't be able to close sales.

Politely ignore in order to dig deeper. If you push someone, then they'll just strengthen their unreasonable position. e.g. "Managers told us we can't do unit testing." "Must be frustrating to not be able to test your code." Reflect their perspective, believe it and be empathetic. Assume positive intent, and that they're doing the best thing that they know how to do in the situation. In their mind, they're doing it for noble reasons.

Showing empathy and really understanding what they're going through and understanding their pain and what they're going through is really important. Sympathy can reinforce their pain / I'm better than you, and I'll give you pity and hand out. Empathy and compassion is a lot better. Compassion may be a better word.

Near enemy. Compassion is the genuine compassion. Pity is that it's too bad that you're suffering / It sucks to be you. Compassion insights action to help. Compassion includes wanting to help.

One big motivation is reducing suffering.

"Slight of mouth" patterns of taking language and reframing it.

Assume what other people think is mind reading. Looking for invalid attributions.

Get backup support to come support what you're advocating for. Senior business person, and want to do the right thing even if it takes longer. 2nd best answer is no.


Rejecting help, they believe that they're doing the right thing for the business. That it'll be a waste of time, and we should just get to work and get stuff done to complete our deadline. We're already behind. Upper level management felt like a big problem was there, and they wanted to invest money to fix it, but developers were resistant.

CTO should say we should do TDD, and there's resistant.

Interviewing each department, and understanding pain points of each department. In the end there were commonalities of not knowing how to get things to go through.

Meet with individual contributors, and lack of development environments. Met with VP who had budgetary problem, and didn't believe that it's a problem. But didn't believe that this wasn't their biggest problem.

Could be that it was asking VP to do something when other people need to change. Seemed to be mental block, and wasn't able to do it after 3 tries. Steamroller of reality wasn't happening, it changed a year later.

Plant seeds. Sometimes you just have to let go.

Unrealistic expectation of how fast you can learn agile stuff. It takes time.

Celebrate the successes.

Sometimes the most successful technique is to go away for a while. Don't become too dependent. Let them know that he'll be going away. Job is not to do it for them. Your job is to take this on and decide if you continue to do this. Tell them that this iteration is yours. Take well-timed bathroom breaks. A planning meeting, and they're not showing up (Take a walk for 15 minutes) This is setting up "responsibility boundaries"

Allow small failures. And all sorts of failures. Age-appropriate failures.

Do "One small thing" pattern

"Try and see" pattern. See if this comes to fruition. Try it, and see what works and see what works out.

Ask permission to be rigorous. Try to see it and see how it works.

Leverage inertia

Ask permission to help them

Don't inflict help.

Notes by Kent Bye

Retrieved from "http://citconf.com/wiki/index.php?title=Why_won%27t_this_work%3F_Antidotes_to_resistance&oldid=14624"