C. Keith Ray

C. Keith Ray writes about and develops software in multiple platforms and languages, including iOS® and Macintosh®.
Keith's Résumé (pdf)

Tuesday, March 24, 2015

Rewards, Teamwork, and Ropes Courses

(Originally posted 2003.May.02 Fri; links may have expired.)

Esther Derby, on her blog, mentions a few reward-structures that work against teamwork. She writes:
Many companies throw up organizational barriers to collaboration:
  • reward structures that focus on individual achievement
  • recognition of individuals for group efforts
  • disbanding groups that do work well together (the "seeding" principle)
  • promotion of individual stars
  • And most "team building" misses the mark. Ropes courses, pep talks, and inspirational posters are a crock.
    Once upon a time, I and my coworkers were sent to a Ropes Course once. One thing being emphasized was the fact that old people, when asked what they would have done more of, never said they'd spend more time at the office. (Those who sent us on this course probably didn't know about this lesson ahead of time. Or maybe they did.) We also learned about providing "back up" to each other (support), not using joking put-downs on each other, and were given some time to think about our individual priorities.

    Many of the employees were energized and tried to improve things at the office when they came back from the Ropes Course, but became frustrated and bitter because, while many of the employees who came back did change (more teamwork and respect among coworkers), the managers who came back from the course didn't change: they continued a long history of backstabbing and turf-building.

    Some employees quit to get better jobs and spend more time with their families. The company's president, who wanted this course to help turn the company into a focused team, did not achieve her goal: the managers under her did not change their behavior, even though the employees did change, for a short while, until they realized that the managers were not providing "back up" to their workers. They probably could have used Retrospectives, Charters, and all sorts of good things, but as long as the managers were rewarded for back-stabbing and turf-building, the situation would not have improved.

    One of my priorities was/is "fun". (The IXP value of "Enjoyment".) The IXP mailing list has been discussing this, including other names like "Satisfaction". The most fun I have had in work comes from working in teams of respectful coworkers, with collaborative design (and since I've discovered XP, pair programming).

    Pairing can be tiring, and with the some people it can be VERY tiring, but the fun comes from getting work done quickly, with someone to provide "back up" (catching my mistakes), and with me providing "back up" to the pair when he's keyboarding. Getting code to pass the latest test (or sometimes, getting the test to fail) is a shared triumph, repeated many times during the day. Getting our changes checked into source code control several times a day is also a shared triumph, particularly when you can announce that this check marks the completion of a story/feature.

    Even formal code reviews can be a little bit fun, if the people in the review respect each other, and have a sense of humor about the mistakes we can all make.

    Check out more about Pair Programming at http://www.pairprogramming.com

    1 comment:

    1. I feel that team building exercises are really good for coworkers to give them new energy for work. This way we can improve their work capability. When I have to plan for any event, I just took some time to plan things in unique way.