|
Parts:
<- Previous -
1 -
2 -
3
From the work of Carl Rogers, Haim Ginott, and Jack Gibb, Thomas Gordon has devised a comprehensive list of actions that impede or halt effective communication. These antipatterns have the effect of shutting down open conversation. The hallmark of many of them is that they are not peer-to-peer; to use one is to speak down to someone. Whenever conversation is no longer between peers, the relationship is under pressure.
I've listed a few of them below.
If you cannot learn to listen to others empathetically, then as a speaker you might find it helpful to try to stop yourself as much as you can when you are tempted to do any of the following:
· Criticizing or judging (explicitly or implicitly). This includes any negative evaluation of another person, her actions, or attitudes. ("He can only blame himself for that one!")
· Name-calling. This includes stereotyping ("Yeah, leave it to a programmer to think that way.")
· Diagnosing. Analyzing why a person behaves the way they do; playing amateur therapist.
· Ordering. Whenever you command anyone to do anything (regardless of your authority), you are undercutting trust, respect, and approval.
· Threatening. This includes any sort of implicit warning of consequences. ("I'm afraid if we can't get this done by Friday, you'll all be coming in on Saturday and Sunday.")
· Moralizing or preaching. Telling another person what they should do; imposing your value system on another person.
· Excessive/inappropriate questioning. Closed-ended questions (yes or no questions, or those that can be answered very briefly) are especially detrimental to conversation; they tend to close it down.
· Dumping Advice. Giving the other person a solution to his problems in a dismissive or belittling way. This is a question of tone and frame. A gentle suggestion honors the other person as a peer, while advice might not.
· Diverting. Pushing the other's problems aside through distraction. This communicates lack of care or concern loud and clear. ("You think that's bad? Lemme tell you what happened to me!")
In general, conversations are not threatened when you frame suggestions and ideas as questions for which you solicit feedback,
if you honor anyone's suggestions or ideas, and if you honor all participants as peers.
Ginott's cardinal rule of communication
is especially useful: Talk about the situation, not the participants.
Another Ginott gem is the distinction between anger and insult. Those who have mastered
the ability to express authentic and appropriate anger without insulting anyone can help groups traverse their inevitable conflicts without
injury to relationship and commmunity.
A specific technique for gauging and sustaining presence as a listener is called
reflection. Reflection is the use of feedback loop techniques like empathetic interjections, paraphrasing, and open-ended questions to keep listener and speaker engaged and present together.
Reflection is a staple technique in counselling and therapy, where clients are typically paying their listeners by the hour, and every minute counts.
Used skillfully, reflection can keep a conversation focused and synchronized.
The rhythm of a well-reflected conversation goes something like this.
The speaker makes a handful of statements. An empathetic listener meanwhile focuses her attention fully on the speaker's body language, words, and implications.
She moves her body as the speaker speaks, maintaining eye contact with him, nodding, and making appropriately sympathetic noises.
Every few sentences, ideally in pauses in the speaker's flow of sentences, the listener interjects with a statement or question that attempts to paraphrase or clarify the speaker's meaning.
The speaker either then confirms or corrects the listener's understanding so far.
Once reflection becomes habitual for a listener, there is less and less doubt on the speaker's part that at least that particular listener grasps and appreciates the intended meaning.
In a large meeting, one or two persons who carefully reflect what is spoken can drastically increase the clarity of meaning for all those attending.
Empathetic listening might seem pointless to you in your context, for one psycho-political reason or another.
But so did agile practices themselves seem pointless to legions of programmers and other software professionals who are now making greater and greater strides with them.
God knows if we can learn to program in pairs, and to share a codebase, integrating it every few hours, we can learn to listen deeply to one another.
In fact, perhaps we have been learning it already, without much notice.
Agile software development practices demand plenty of direct conversation to solve
collective problems. This conversation in turn demands empathetic listening, which in
turn demands that those in conversation learn to be as present as possible for one another.
By developing habits of presence and empathetic listening, those of us in a software
team can learn to sustain positive feedback loops of strengthening relationships and community.
We can also gauge the health of those relationships and
community by appraising ambient and specific levels of trust, respect, and approval.
These are the true preconditions of healthy agile software development communities,
out of which come the highest sustained levels of excellent production.
The joke goes that no-one on their death bed wishes they had spent more time at the
office. We can tell ourselves that building quality software is the end, and
that relationships and community are merely means to that end.
But that's an illusion, and (to my mind) a path to deathbed regret. We are mortals,
engaged in
activities that enrich us and pass our finite time together. Software development,
like any work, is simply time we spend together.
We can spend it well or not.
There is a nobility in striving to make our time working together as fruitful in its
process as it is in its product.
Perhaps we then learn that relationships and community are the true
secrets to loving our jobs. And perhaps this is much of what the Agile Methods
movement has always been about.
Parts:
<- Previous -
1 -
2 -
3
-- Patrick Wilson-Welsh,
Adaption Software revised 12-3-05
[More of Adaption's Articles.]
|