Managers and rules
Jerry Weinberg, if you don't know him, is the author of more than a dozen books on software development and memorable laws such as the Law of Twins. In Quality Software Management: Systems Thinking, published in '92, he described what we might today call an agile team. (He lists several levels of software team cultures, ranging from Oblivious to Congruent. Along that spectrum, an agile team would fall somewhere along Steering, Anticipating and Congruent.)
At AYE 2007, I had the pleasure of meeting Jerry in person. Something that I was not aware of was his remarkable skill at helping others. Instead of answering a request for advice directly, he'd delve into the details, applying something like the 5 Whys. Within minutes, he would hone in on a rule that the person had imposed on themselves that was at the root of the problem. After expressing the problematic rule, he'd help them relax the rule into guidelines. Several people who've spent more time with him have echoed my gut feel that they too found this ability to help others rare and invaluable.
His approach to helping individuals is based on Virginia Satir's work in family therapy on survival rule transformation. An excerpt from The New People Making:
After you have written down all the rules your family thinks exist and cleared up any misunderstanding about them, go on to the next phase. Try to discover which of your rules are still up to date and which are not. As fast as the world changes, it is easy to have out-of-date rules. Are you driving a modern car with Model T rules? Many families are doing just this. If you find that you are, can you bring your rules up to date and throw away the old ones? One characteristic of a nurturing family is the ability to keep its rules up to date.Now ask yourself if your rules are helping or obstructing. What do you want them to accomplish? Good rules facilitate instead of limit.
Last weekend, while attending a Satir workshop I was struck by the applicability of Satir's ideas on rules to teams at work. There too, rules can be unstated, ambiguous or inapplicable sometimes hampering our ability to get things done, other times making everyone miserable.
(For a valuable discussion on rules suitable for software development teams, check out the section on Rules in chapter 21 of Software Teamwork:Taking Ownership for Success. To summarize, the rules should be focused on ensuring that a team has "the capabilities and resources to do the right things, rather than on stepwise procedures to be dogmatically followed".)
In big companies the problems are magnified as fully connected networks of people become prohibitively expensive. For example, it'd take each person over a day out of every week for 25 people to stay in meaningful weekly one-on-one contact. (Indeed, the few who take the time to build an extensive network can become stars capable of getting things done faster than their peers could.) Additionally, in a big organization, it's likely that a rule that works for one group will be applied to ones where it doesn't fit.
The role of a manager is to engender an enabling environment. But how? Virginia Satir's approach to rule transformation provides one way. One which fits in well with the management advice in many of the management books I am familiar with, including Behind Closed Doors, Peopleware and Slack.
Here's how I describe the process:
- Identify implicit rules and restate the explicit ones.
- Explore how they came about.
- Express the rules explicitly.
- Clear up ambiguities in the team's understanding of each rule.
- Evaluate each rule's applicability.
Having done this, you might find that a rule is:
- Helpful and reasonable. So, apply it!
- Helpful but impossible or untenable. Then transform it into one or more guidelines that aren't prohibitive.
- Limiting or obstructing your team. If so, the rule should be challenged, publicly.
Again, quoting The New People Making:
What do you think about your rules? Are they overt, human [i.e. reasonable] and up to date? Or are they covert, inhuman [i.e. prohibitive, impossible] and out of date? If your rules are mostly of the second variety, I think you realize that you and your family [or team] have some important and necessary work to do. If your rules are of the first category, you are probably all having a ball.

1 comments:
A hint about rules and teams.
A person's mind is a multimind: several more or less independent minds working in parallel. Different parts may defend certain rules, rules that may conflict with the rules defended by other parts. You experience this kind of conflict when, for example, you vacillate between your "always on time" rule and your "always be perfect" rule. You need to meet your deadline, but you would like to test some more.
It's nice to talk about team rules, but teams, of course, are also multiminds. Different team members will have different rules that sometimes conflict. "Should we ship now, or should we test some more?"
Expect such conflicts among team members. If possible, transform the members' rules that may come into conflict when you try to decide on team rules. To learn how to do this transformation from rules to guides, see Becoming a Technical Leader.
Post a Comment