"Poor management can increase software costs more rapidly than any other factor." (Barry Boehm)

Johanna and I have been writing again this week. Last time, as my faithful readers may recall, I owned the keyboard, and Johanna watched over my shoulder. She noticed all my little typing quirks, like backing up to fix typos. She really hated that one.

This week, Johanna owned the keyboard and I got to see how she types. And  guess what? She backs up to fix typos, too. The only difference is it doesn't annoy her when she does it.

We had a pretty good laugh over this.

And it reminds me: When I find a trait in another person particularly irritating, I often have some of that same trait myself.

Sometimes I can ask myself, "What is it about me that I find so irritating in Mr. X?" There may be a similarity that represents a part of myself I don't particularly like.

Sometimes I can reframe the irritating trait and allow a more neutral response, one that opens up more possibilities.

posted by Esther Derby at 2:55:00 PM  

|

Here's a little snippet from a Fast Company article on John Mackey, CEO of Whole Foods Market:

Before the adjournment of every business meeting at Whole Foods, including the ones that Mackey conducts, participants do a round of "appreciations," saying something nice about the people in the meeting.

He's onto something. 

People want to be noticed an appreciated, not just for the tasks they complete but for who they are and the qualities they bring to the team. I do appreciations when I lead retrospectives.  I also put appreciations on the agenda at team meetings. I do appreciations first; it sets a tone that says people are valued. I use a particular form: "_______________, I appreciate you for _____________."

Some people are uncomfortable expressing appreciation.  A few months ago I lead a workshop on leading project retrospectives.  When I got to the part about retrospectives, one of the managers protested: "We could never do that here.  All the people here are engineers -- they don't stand for that!"  She didn't notice the engineers shaking their heads in disagreement.

Even if it feels a bit awkward at first, try giving an appreciation using the direct form, "_______________, I appreciate you for _____________." It makes a difference.

posted by Esther Derby at 7:22:00 AM  

|

Johanna pointed out on her blog how pair-writing is different from pair-programming. But I suspect the two are similar in many ways, too.

Here's what stood out for me in my pair-writing with Johanna:

Conflict comes with collaboration. Conflict is part and parcel of any serious collaboration. Any time you put two people together, you've got different life experiences and different preferences. Even you share a goal and have substantial overlap in skills and values, conflict is inevitable.
How you manage feelings about conflict (individually) and navigate conflict (as a pair) effects the success of the pairing.

One of the advantages of pairing is that, typically, both people have better focus and remain focused longer. Each reinforces each other to stay with the work. That said, it's important to take breaks when you come to a logical stopping point... maybe 5 minutes to move around, do some hand exercises, and mentally refresh.

Debrief so you notice what's working, what isn't working, and what you'd like to do differently. A five-minute end-of-day debrief really helped us become more effective over the week that we paired. I suspect once a pairing relationship is established, debriefing weekly or when something out-of-the-ordinary occurs would be enough.

Know where you're headed. The first day, Johanna and I started out with a high-level scenario to guide our work. At any given time, one of us didn't know where we were headed. (I didn't really like that feeling.) After the first day, we spent more time discussing the scenario and our goals for the scenario before either of us touched the keyboard. And we were more willing to pause to discuss where to go next.

A good dose of tolerance helps. I have this habit of backing up to fix spelling errors and typos as I go. It nearly drove Johanna crazy. So I tried to reduce the habit and Johanna worked to tolerate it. I think she felt better after a give her permission whack me if I did it again (I did, and she didn't).


We were both really please with the results... we still have editing work to do, but the product is superior to our previous efforts and merging our individual writing. And we got much more done than we expected to.

So: how is my experience pair-writing similar and different from your experience pair-programming?

posted by Esther Derby at 10:50:00 AM  

|

Johanna and I are writing this week, taking another run at "the book."

We made the (painful) decision to put aside the draft we finished last summer and start over. Some times starting over is a much better course than trying to retrofit, re-architect and fix (sound like software?).

We're pair-writing this time -- whew it's hard work! But the results are worth it. We're working out the kinks in our pairing relationship. It's working more smoothly today than it did at the beginning of the week.

Now, after a long day (3 chapter-ettes!) we are restoring our spirits by listening to the dulcet tones of Karl Zero's cha-cha-chas.

posted by Esther Derby at 8:17:00 PM  

|

I was talking to a friend last week who works for an expert… in how to stifle teamwork.

It’s simple, really: Establish two classes of membership on the team, then follow these steps to ensure that all are aware of the distinction.

1) Bring in donuts for the team every Tuesday… and don’t tell the 2nd class team members. Even better, explicitly communicate that donuts are only for 1st class team members.

2) Hold a team celebration at the end of the project…and provide 1 drink ticket for 2nd class member and 4 for 1st class members. Or don’t invite the 2nd class members at all!

3) Hold meetings to discuss project business, and exclude the 2nd class team members. If they ask to attend, tell them the meetings are to discuss topics they don’t need to know about… or say “This is meeting is only for 1st class team members.”

4) Swap in new 2nd class staff frequently (2nd class team member are fungible, afterall, unlike more important 1st class team members). This is a double-header strategy – it slows down progress, too!

5) Don’t communicate plans and goals to 2nd class team members – assume they’ll just pick it up from the rest of the team.

6) Establish that some roles are only open to one class … whether or not they have the requisite skills and qualities.

7) Discuss the failings of the 2nd class team members publicly.

8) Blame the 2nd class when the so-called team fails to work together effectively...“They just don’t understand how to work as part of a team.”

You could do this with developers and testers. Or employees and contractors. Or people with technical focus and people with business focus. Any two classes will do.

I don’t make these stories up. Really I don’t.

posted by Esther Derby at 6:58:00 AM  

|

My recent post on Bully Bosses prompted this response from reader Jerry Conklin, which I'm posting in full (with permission):

The manager who uses his position to bully employees is pathetic and worse than useless. The negative effect of such people is powerful. This kind of bullying behavior has produces human misery and project failure. Such people need to be weeded out of management.

Like all bullies, the bullying manager hates himself. Since he cannot face that fact, he uses whatever power he has to dump that hate on anyone perceived as weak and vulnerable. At bottom, he is a cringing coward and can generally be seen to grovel before his superiors. He is drven by fear.

The main responsibility of any manager is to remove obstacles to productivity not to create them. The fulfillment of such a responsibility requires character, integrity and courage. The bullying manager is often tolerated because she has high technical qualifications. When someone has shown herself to have the cited leadership traits, then we can talk about technical capability. The bully is a weakling who is, by definition, devoid of the character traits necessary to lead people.

Well said, Jerry.

If you've been following this blog you know I've got energy for this topic:

Jerk is not a protected class I and III.

Thanks also to Andy and Jeff for helping me with spelling and English usage in my previous post.

posted by Esther Derby at 9:44:00 PM  

|

My friend Shannon Severance sent me a link to a NY Times article on abusive bosses (available for a fee unless you are a NY Times subscriber).

I was surprised to see that the study cited in the article concludes that abusive bosses don't affect productivity.

That doesn't match my observations or the author's description the results of bullying:

"It is not long before dissatisfaction spreads, rivalries simmer, sycophants flourish. Normally self-confident professionals can dissolve into quivering bundles of neuroses." (Fear in the Workplace: The Bullying Boss by Benedict Carey, New York Times, June 22, 2004, Tuesday.)

What is clear from the article is that bullying bosses drive all manner of unhealthy coping behaviors and cause misery to their unfortunate subordinates.

Life is too short.

posted by Esther Derby at 4:18:00 PM  

|

I've been thinking about stories lately... not as in user stories (though I did very much like Mike Cohn's new book), but the ones we tell and re-tell in organizations. Those stories shape how we think about ourselves, our work, and what's possible.

And stories help people share knowledge.

When I facilitate retrospectives, I ask people about the story and tease out different perspectives on events.

With this in mind, I attended Sandor Schuman's session on storytelling in organizations at the recent International Association of Facilitators conference.

Here's a way I learned to get a group telling stories to share knowledge.

Choose a proverb. Now tell a story that shows how the proverb has meaning for your project.

Haste makes waste.

Nothing ventured, nothing gained.

This too shall pass.

Time will tell.

Any port in a storm.

Your sins will find you out.

There is strength in unity.

For more on how storytelling works in organizations, see "Telling Tales" by Stephen Denning in the May 2004 HBR (an excerpt here)at Stephen Denning's website, or visit Sandor Schuman's site.

posted by Esther Derby at 7:37:00 AM  

|