Communication
Communication, both inside and outside the team, is obviously key. During a post-mortem people often say “there was a lack of communication.” It’s hard to know what that really means. Here are some clues.
The “reality distortion field”
A key communication problem within the team, one that seems far too prevalent here at Microsoft, is fondly known as the “reality distortion field.” This is when a team, engrossed in its own magnificence, convinces itself that impossible dates can be met, that enormously complex technical problems are nothing to worry about, and that naysayers just “don’t have the religion.”
This occurs in varying degrees which makes it often difficult to detect. It shows its true colors when challenges to the schedule, business model, or technology are not carefully considered but rather are discarded as the ranting of a non-believer. Often the retort is “you just don’t understand.” Obviously the appropriate reaction is to build understanding, but if this is not forthcoming, there may be a need for some cold, hard reality. A thorough project review with a skeptical audience can do wonders toward dissipating the field.
Lack of communication among dependents
The most important part of working with groups that you are dependent on, or who are dependent on you, is communication. It’s easy to understand the importance of getting the programmatic interfaces correct, or to see why planning the dates is vital, but none of this will actually happen without a huge investment in communication.
Discovering whether you have a communication problem with your dependents is actually quite easy. Among the key questions to ask:
n When is the next drop? The answer should be unequivocal and the date should be before your next drop.
n Who in our group attends their staff meetings? The answer should be at least one of your program managers, maybe a developer or two as well.
n How many bugs do we have on their bug list? The answer isn’t important, but someone on your team should know it.
n How do they prioritize our bugs? The answer should be “like their own.”
In any case, your project is in jeopardy if you don’t manage these communication issues very well.
Inordinate emphasis on secrecy
One of the clues to a team that is in trouble is a team that’s trying to hide things. Clearly some details of the technology can or should remain confidential, but a team that is overly protective of their specs or schedule is hiding something. And it’s not likely to be something good.
Ask for a look at the spec. You don’t have to read it (but you probably should), it’s just a test to see if they’ll give it to you. Ask to go over the schedule. If they let you, it’s probably OK. If they don’t you should be alarmed. If you’re not on the team, maybe there are good reasons. But it’s time to really be alarmed if you’re on the same team and you can’t get access to things. Something is wrong.
Status reports that blame others
If every month the status report looks bleaker and bleaker, yet the problems are always someone else’s fault, there’s a problem. There’s little question that a team can be derailed by the failings of their dependencies, but if it happens continuously month-after-month, there is a problem. They should be making alternate plans, falling back on their contingent strategies, doing something. But throwing up their hands and blaming their woes on others is a clear sign of a team that is out of control.
<again this is not mine - chris williams wrote this in 1995>
done
/i
