AYE 2008 – Making Better Use of Personality Resources

My Wednesday morning session at the 2008 Amplifying Your Effectiveness Conference was Don Gray‘s session, Building on Strengths: Making Better Use of Personality Resources.  This session was about recognizing our differences, and our strengths, based on our personalities. (Continued)

AYE 2008 – Moving Projects Forward: The Clinic Method

As I slowly work through my notebook from the Amplifying Your Effectiveness Conference (having blogged about sessions on Unearthing the Data You Need, Remembering Your Resources When Stressed, and Congruent Coaching), I come to Jerry Weinberg’s session of Tuesday afternoon, Moving Projects Forward: The Clinic Method.

As long as projects are staffed and led by people, we can be sure that they will sometimes get stuck, or headed in the wrong direction, or something.  This is true no matter what sort of methodology you follow.  Even if the methodology is perfect, the people following it are not.  They will make mistakes.  They will have blind spots, and not see what it is that they’re not seeing.  Projects will still get in trouble.  (Yes, even Agile projects.)

So, what do you do about this certainty? (Continued)

AYE 2008 – Congruent Coaching

Continuing with my recap of the AYE Conference sessions I attended, I come to Johanna Rothman‘s session, Choosing the Right Coaching Approach: Congruent Coaching. This was a time-slot where I wanted to attend every single session. I chose this session because coaching is a big part of what I do, and Johanna is one of the best people I know to learn to coach more effectively. (Continued)

AYE 2008 – Unearthing the Data You Need

The AYE 2008 (Amplifying Your Effectiveness Conference) is now history. I never have time to blog about this conference during the conference–I’m always too busy. Besides, it’s so rich with learning that it takes me awhile to process it. This year (my fourth at AYE), I’m going to look back through my notes and blog a little about each session I attended.

The first session I attended was titled First Steps for Organizational Change: Unearthing the Data You Need and was presented by Johanna Rothman. I say presented, but like all the sessions at AYE, the word “presented” doesn’t convey the essence of the session. Johanna presented a lot of information, to be sure. (And you can find some of the same material on the AYE Wiki.) But the power of AYE lies in the fact that all the sessions are experiential. In this session, we took turns, in small groups, interviewing each other, and observing each other interviewing. And after each interview session, we examined the experience in a debrief. The debrief is the heart of the experience, for it’s where we make our actions explicit to ourselves. And it’s where we share our insights with others, and share theirs.

A few Johanna tidbits from my notes:

  • Don’t be afraid to ask for quantitative data before starting an assessment, but don’t expect to get it.
  • I take notes [when interviewing people as part of an assessment], but everything is off the record.
  • Pay attention to differences between expectations and reality.

Thanks, Johanna, for a wonderful and rewarding session!

How to get people to do what you want

Back in March of last year, David Maister was interviewed by Wayne Turmel and he said some amazing things. I’ve been meaning to talk about this for some time, but the work of transcribing from audio has tempted me to put it off. I highly recommend listening to the whole thing.

David Maister is a business consultant, but what he says here is extraordinarily appropriate for most of us technical people, too. He describes starting out with the same vision of success that I had, and how completely wrong it was. (Continued)

The Case of the Recalcitrant Customer

Over on the ScrumDevelopment yahoo group, a ScrumMaster reported problems getting the Product Owner fully involved in the development process. Part of the problem is that the Product Owner isn’t co-located with the development team. The physical distance will certainly make participation more difficult, and less sure. That’s something to work on.

The Product Owner is not following the “rules” of Scrum, and this is frustrating the ScrumMaster. He’s likely right that playing the game by the rules will benefit everyone. He asks for advice on how to handle the situation. (Continued)

Efficient don’t work for people.

Esther Derby commented on my Overcoming Resistance entry with an excellent list of reasons why people may appear to be resisting. Thank you, Esther!

She also said

Unfortunately, I hear many people–even those who hope to influence others to change–label people who are “resisting” as clueless, stupid, or selfish. Some would-be change agents attack the motives of the people who aren’t following their ideas, accusing them of wanting to bring the company down.

This may make the so-called change agent feel superior, as he/she belittles people who don’t get his/her wonderful ideas. But it doesn’t help him/her bring about change.

Well, it may make the so-called change agent feel superior, but I’d bet that it’s really an ego defense against feeling frustrated and helpless. Ineffective change agents need love, too.

“Hi, I’m George and I’m a so-called change agent.”

(Continued)

Oh, about that Notable Example…

In my post on Overcoming Resistance, I said, “I wanted to write an article with a shining example of a time when I didn’t try to overcome resistance, but used it to advantage, instead.”  Besides the Velvet Elvis principle that Don Gray describes, there’s another reason why one didn’t come to mind.

You see, actually listening to people doesn’t work in a big, noisy way like that.  Instead, it’s a quietly effective activity that doesn’t call attention to itself.

When was the last time you said, “Boy, I really listened to her, didn’t I!” Hmmm…  Doesn’t have the same verbal punch as “Boy, I really told her, didn’t I!”  It’s just more effective, that’s all.

Overcoming Resistance

Esther Derby posted an excerpt of a Management Consulting News interview with Jerry Weinberg where he answers the question of how to overcome resistance, “Yes. Don’t.” Oh, he says more there, and he can say a lot more on the topic, but that’s enough for the intro to this article.

You see, I wanted to write an article with a shining example of a time when I didn’t try to overcome resistance, but used it to advantage, instead. The problem was that I found myself in the trap that Don Gray frequently mentions, that when someone tells you not to think about something, you can’t help but immediately think about it. So what filled my memory was a time when I had tried, eloquently and earnestly, to overcome resistance on the part of my client. (Continued)

When do we get to the stage where we can tell the client what the answer is?

I saw this question in a blog post by Mark Schenk:

About two-thirds of the way through the workshop one of the students asked “when do we get to the stage where we can tell the client what the answer is?” This literally stopped us in our tracks – we were so accustomed to working on the basis that complex problems have no single correct answer that we hadn’t explicitly explained this and we had bumped headlong into a prevailing management mindset.

That question struck a chord. I thought back to the days when I first learned XP. Most of the ideas and practices resonated strongly with me. The one that seemed most foreign, Test Driven Development, became a personal fixture after trying it for three days. Yep, this was the way software development should be done! It was so obvious and right, and I told everyone I knew.

They all immediately agreed and thanked me for the information. Well, not exactly. (Continued)