Originally published by the Cutter Consortium Agile Email Advisor. Used with permission.

by Christopher M. Avery, Senior Consultant, Cutter Consortium

More in this series
Collaborative Leadership Basics:
Part 1: Why Is Collaborative Leadership Required for Agile Environments?
Part 2: Develop Personal Responsibility for Team Productivity
Part 3: Get in the Same Boat Together
Part 4: Keys to the Boat — Generating Positive Interdependence in Groups
Part 5: Why Project Teams Are Easier to Build Than Management Teams
Part 6: Why Team Member Motivation Is a Better Predictor of Team Effectiveness Than Are Technical Skills
Part 7: The Single Most Powerful Tool for Managing Peer Motivation
Part 8: Keys for Creating Designer Norms in Teams

In my last Advisor, “Collaborative Leadership Basics, Part 7: The Single Most Powerful Tool for Managing Peer Motivation” (25 January 2007), I told you about the best tool available for managing peer motivation. In this Advisor, I’ll share my keys for creating designer norms (as in forming, storming…) in teams.

What are norms and why do they matter? Good question. Did you brush your teeth this morning? Hug your spouse? Smile and say “Good morning” kindly to others as you greeted them? And if so, was this normal, desired, and expected behavior on your part? Or was it aberrant, out of bounds, and unacceptable?

Okay, those examples have to do with personal hygiene and etiquette, so let’s talk about a relevant team experience. In your most recent team, did you take 100% responsibility for your work, communication, and actions? Did you keep every agreement you made, or own the breakdown and clean it up at the first opportunity? Did you support all of your teammates all of the time, even when you disagreed with them? More importantly, did all of your teammates behave like this so that it was normal, desired, and expected?

Or did you and your teammates weasel out of work and engage in behavior that you’d be ashamed to own? Did you make agreements you didn’t or couldn’t keep, and then pretended you never made them? Did you create in-groups and out-groups within the team, effectively harming the collective performance? And if so, was this behavior normal, desired (think carefully about that one), and expected?

Norms are the set of normal, desired, and expected operating behavior that can be observed readily in any group. Unless you are paying attention, you don’t see them, since they are “normal.” Like the question about whether fish think about being in water, most of us don’t pay attention to such ambient things.

But norms are critical in teams because they dictate how the team interacts (relates to, communicates with, and behaves toward one another) to get things done. And team performance rises and falls on the dynamics of trust, goodwill and cooperation, and respect for individuals — dynamics that ride on the currents of team interaction.

So, if norms are “normal, desired, and expected behavior” and are so important, how do they get established?

Good question. Norms get established in groups in two ways: it can happen by default, or it can happen by design. The default method predominates, of course, in most groups most of the time. In the default method, members do what they do naturally in that setting and other members provide feedback in the form of acceptance or nonacceptance of the behavior. It’s that simple. Think of being in a classroom or a meeting and noticing how to get your voice into the conversation. Do you have to raise your hand, speak up, catch the eye of the teacher or moderator? That’s figuring out a norm.

Sometimes, by default, all the norms that support effective team dynamics fall into place naturally. That’s cool when that happens. But more frequently it doesn’t, and then the default norms that evolve can hurt rather than support team interaction. That’s where designer norms come into play.

So how do you create designer norms?

Easy, actually. You make and keep agreements about behavior that supports the team reaching high performance. Most groups are experienced at making behavioral agreements, often called operating agreements or rules of engagement. Where most groups fall down is in keeping them. So expect agreements to be violated, just the way you expect code to be buggy. This will help you make only agreements that you are willing and intend to enforce with each other. Then learn to be completely intolerant of the smallest violation. Call violations as soon as they occur, and with appropriate force, usually just less than or equal to the force of the violation, so calling the violation while it is a small deal requires minimal force.

The real key is that creating designer norms has more to do with what you are willing to accept than with your ability to paper the wall with agreements, so raise your standards. With practice you can become extremely skilled at creating designer norms in any group.

Send your questions about developing a collaborative leadership culture to me at cavery@cutter.com and I’ll address them in future Advisors.

Sincerely,
Christopher M. Avery, Senior Consultant
Agile Software Development and Project Management Practice