Chapter Nine. Communication and relationships


One of the earliest engineering stories in Western history is the story of the Tower of Babel, from Genesis, and at its core is a lesson about communication. As the story goes, humanity was happily united in the desert. They soon figured out how to make bricks and mortar. Things were going so well that, for no particular reason, they decided to build a tower high into the sky. Things went along brilliantly until the workers suddenly lost the ability to use the same language (can you say "divine intervention"?), at which point everything literally fell apart. The once-united people were scattered across the world (more divine intervention), and different languages and societies were formed. It's suggested in the story that had they been able to continue to communicate well with each other, nothing would have been impossible (which is perhaps, as the story also suggests, what motivated the divine intervention).
This biblical story is quite short in length: barely a full page. However, through the centuries, it's captured the attention of many artists and writers who used the story to explore contemporary issues. The vivid images of the tower painted by Brueghel(1) and others gave the story increasing relevance to engineering and project management tasks of their times. The interpretations of the story have shifted from age to age, as did the depictions of what the tower actually looked like, but the general themes are the same. Some believe the story is a warning about humanity's hubris and a reminder that some things should be unattainable to us. Others see it as a story of people striving to achieve all that they can by pushing the boundaries of what's possible. But for me, and for the sake of this chapter, the central lesson of the story of Babel is simple: if you can't communicate, you can't succeed.
For much of the history of civilization, the slowness of communication caused problems. Even as late as the American Civil War (1861-1865) there were no radios, telegraphs, or semaphore (flag) systems in common use. Generals sent messages by horse to coordinate battle information with commanders at different camps (which, depending on distance, took hours or days, assuming the messenger didn't get lost). As a result, decisions were often made days in advance with no effective way to withdraw or change attack assignments. Many disasters and frontline miscommunications resulted from these limitations. (Imagine a battlefield commander who has just sounded the charge, sending all his troops to attack, when an exhausted messenger stumbles into his tent. The messenger, struggling to catch his breath, says, "Dispatch from command.... 'Dear commander: The reinforcements you were depending on were sent elsewhere. Sorry. Good luck.'" No wonder messengers were often shot.)
These days, communication is still as important as in previous eras. But two things have changed. First, speed is no longer the primary problem (how can you get faster than instant messaging?). Instead, the problem has become the quality and effectiveness of communication. Second, for work that's as complex and interdependent as software development, communication isn't enough: there need to be effective and healthy relationships between the people who are working together. So many decisions are shared, and so much work is done collaboratively, that without good relationships, no amount of extra communication matters. Unlike the military command structure of an army, most software teams rely on peer-to-peer interaction and other, less hierarchically driven relationships. Although there are often clearly defined leaders, who sometimes give orders, projects are heavily dependent on the team's ability to make use of each other's knowledge, to share ideas, and to work in synchronicity (as opposed to relying on strict lines of authority, rigorous discipline, and the compulsion to follow orders without question).
Because project managers spend a lot of time communicating with individuals and groups, they inevitably carry more responsibility for effective communication than other individuals on the team. Good project managers provide steady streams of good communication and healthy relations, amplifying the effectiveness of everyone they come into contact with. If it's the health of the social network of a team that prevents it from becoming another Tower of Babel, then it's the project manager who has the most natural role in building up and maintaining that network.
Doing this doesn't require an extroverted, game-show-host personality; nor does it demand a brilliant sense of humor or magical powers (although these may help). Instead, it starts by admitting that communication and relationships are critical to success, and that there's room for improvement for yourself and your team. If you admit it's important, then you'll want to understand where most communication problems occur and learn how to deal with them.

9.1. Management through conversation
This might sound strange, but it took me a long time to understand the value of talking to people in the workplace. I'd chat and joke around, but I rarely confused socializing at work with the actual doing of work. My upbringing and experiences in college led me to believe I had to solve problems on my own at work. In my first year at Microsoft, I'd rarely seek out the opinion of others or find someone who had more knowledge than I did and reuse it. Instead, I'd grind it out on my own and work hard instead of smart. At the same time, I watched two of my earliest managers, Ken Dye and Joe Belfiore, exhibit the curious behavior of spending a great deal of time talking to other people. I'd see them, sitting in various other people's offices, chatting away. As busy as I was, I couldn't help but wonder how they could afford to spend so much time "socializing." Being new, I didn't ask them about it. Instead, I just labeled them "extroverts," which at the time, given my background, was a minor kind of insult. Their behavior annoyed me (shouldn't they be working at least as hard as I am?), and I didn't see any value in what they were doing. How wrong I was.

As my responsibilities grew, I slowly understood what Ken and Joe had been doing. Through trial and error I learned that manhandling, bullying, dictating, or demanding things wasn't an effective tactic when I needed things from people who weren't obligated to listen to me. I noticed similar results in noncommunicative programmers or testers, and that they were ineffective when getting work done that involved other technical people. (This is significant if you look at Figure 9-1. The implication is that everyone can benefit from better communication and relationship skills, no matter how isolated their work supposedly is.)


Figure 9-1. There's evidence that programmers are not as solitary as we think.




I found that the more times I demanded or assumed things from people ("You need to code it this way, OK?"), the lower the probability was that I'd get the best work from them. Even if they did what I asked, something about my approach killed some of their motivation or minimized the probability that they'd add value beyond what I'd asked for. However, I found that when I conversed with them ("Hey, I think we need to do X, and I think you're the right person to do it. What do you think?"), instead of barking orders, I received what I needed sooner than when I used those other tactics. And, as a bonus, the odds increased of them suggesting good improvements on my ideas. I learned that dialogs are better than monologs.

9.1.1. Relationships enhance communication
Despite how obvious it is that you need to have a positive relationship with someone in order to have a good conversation with him, people are rarely rewarded for their skills in doing so. Those informal chats and conversations Ken and Joe invested time in were not a way to kill time. Those conversations were investments in people and information, giving Ken and Joe knowledge and insight into what was going on that few others in the organization had. But specific to my point: when they needed to request advice, an opinion, or a task, they could talk to almost anyone on the team, at any time, and start from a healthy and positive place, rather than from scratch. Their relationship with the team accelerated their ability to communicate with everyone.

This made it easier to cut to the chase without being rude, or even to make exceptional requests of people that ordinarily would be rejected. In matters of opinion, they had built enough trust to get honest opinions from the right people in a casual manner, and, if so inclined, they could incorporate those suggestions and ideas into their own thinking well in advance of larger discussions. In short, through those informal conversation and relationships, Ken and Joe were ahead of the rest of the team. They knew more about what was going well and what wasn't, and they had more influence on it through their investment in relationships. They'd paved the way for all kinds of additional support and benefits, simply by talking and listening to people.

In Tom Peters and Nancy Austin's classic, A Passion for Excellence (Warner Business Books, 1985), this sort of behavior is called management by walking around (MBWA). It's described as a central quality in the successful managers they observed (an entire chapter in their book is dedicated to it). But it's not easy to do well. They recommend explicitly picking a small number of people, at different levels and roles in the team, and investing time in building this kind of informal relationship with them.(2) More importantly, it requires an understanding of how healthy communication and relationships work and a commitment to growing those skills. Even if you don't choose an MBWA approach to build relationships, core communication and interpersonal skills will still be essential to everything you do.

9.2. A basic model of communication

Despite how often we communicate with people, we rarely step back and dissect what's actually happening. Because most of us have never been taught or trained to understand what's going on when people communicate, it's not surprising that we run into problems frequently. Very few people in the workplace have any real proficiency in diagnosing communication or relationship problems, or have the necessary authority to sort them out. However, it is easy to learn a simple framework for what the goals of communication arefrom a project management perspectiveand apply it to daily situations. With this knowledge, you can break down where things are failing and become more capable of resolving problems because you'll have a better understanding of what's not working.

"Good communication centers around highly developed individual awareness and differentiation. A good communicator is aware of both internal processes in themselves, and external processes in others."
John Bradshaw

In the simplest framework I know of, there are five basic states (outlined shortly) that any act of communication can be in.(3) Each is progressively more important and harder to achieve than the previous state. Communication is successful only if it reaches the third state (understanding), if not the fourth (agreement) or fifth (action). To help illustrate each state, I'll use an example from the film 2001: A Space Odyssey: Dave, an astronaut, is in a small spacecraft and wants to get back inside the mother ship. Hal, inside the mother ship, is the only entity capable of opening the doors to let him in.

1. Transmitted. When you send an email or leave a voice mail, you are transmitting a piece of information to someone. This doesn't mean she has read or heard it, it just means the message has left your hands with the intent to arrive in hers. With email and the Web, it's very easy to transmit information, but there is no guarantee that anyone is ever going to read it. Example: Dave says, "Hal, open the pod bay doors, please." (Dave hears only silence in response.)
   
2. Received. When someone checks his email or signs for a FedEx envelope, the message has been received. However, reception doesn't mean the message was opened or that the recipient has any intention of reading it or spending any time trying to figure it out. While read receipts for email do tell you it was opened, nothing else is confirmed. Example: Hal responds, "Hello Dave." (The transmission is received.)
   
3. Understood. Digesting and interpreting a message's information correctly is a big jump in effort from simply receiving a message. Actual cognitive activity has to take place in order to understand something ("What does this mean?"), whereas receiving it does not require that same activity ("Hey, I got some email!"). Depending on the issue involved, understanding a message might involve learning about a new concept, looking up references, or examining a complex piece of code. Often, to understand something, the recipient needs to ask questions to clarify ambiguous things about the original message. Asking questions requires a full-on two-way communication, which is more involved for both parties. (This complicates the simple five-stage framework, creating a tree of simultaneous nested communications, as each question, and each response, starts its own sequence of transmission, reception, understanding, etc.)
   
4. Agreed. Understanding something doesn't mean a person agrees with it. I might fully comprehend every aspect of a request from an executive, a day before final release, to do a Linux port of our Mac-only video editing program, but that has no bearing on how insane I think the idea is. Achieving agreement between two intelligent, opinionated people can be a complex and time-consuming activity, especially if the objections aren't stated clearly. Despite how difficult it is, agreement is the basis for making decisions that impact a team.(4) Example: "Sorry Dave, but I'm afraid I can't do that." (Hal understands what Dave wants, but he doesn't agree and offers no explanation.)
   
5. Converted to useful action. Despite how much energy it can take to understand something properly and perhaps reach a level of agreement on it, significantly more energy is required to get someone to do something about it. Even if the message explicitly called for the receiver to take action, there's often no strict obligation on her part to do so. Perhaps she assumes it's OK to meet the request next week or next month (when you need it done in the next 10 minutes). And perhaps, worst of all, it's entirely possible that an action is taken but it's the wrong action, or it is an action that the sender of the message doesn't agree with.
   

Good communicators transmit information with the intent of it being understood. Instead of just sending an email and seeing what happens, they are thinking about how deep into this five-step model they need to go to be effective, and they are crafting the communication to make that possible. They use language and examples that will make sense to the recipient of the message, instead of just using what is convenient for them. More so, in the message they clarify what the likely points of argument are and identify what action they want the recipient to take in response.
So, every time you receive or send an email, or stop in at someone's office to ask him something, there is a natural progression of communication taking place. Use this framework to help you diagnose why what you want to have happen isn't happening. Good communication occurs when there is a natural and fair sequence of exchanges between two people to get through each of these stages. Even when things don't go well, being aware of a framework like this helps identify where communication is breaking down.

9.3. Common communication problems

There are a handful of reasons why communication breaks down. Every project manager needs to be familiar with these reasons to identify them in others and their own behavior and to take responsibility for working to resolve them whenever they occur. In many teams, these behaviors exist because the group manager either exhibits them herself or tolerates them in others. Until someone with some authority steps in, identifies the problem as a communication issue, and takes at least partial responsibility for helping to sort it out, those bad communication habits will continue.
This short list covers many of the common communication problems, briefly describes why they occur, and offers some simple advice for avoiding or recovering from them.

• Assumption. When you walk into someone's office and ask him why he hasn't sent out that important email yet, you're assuming that: a) he knew he was supposed to send it; b) he knew when he was supposed to send it; c) he understood what was supposed to be in it; and d) he was supposed to notify you somehow when he did it. Before yelling at this person (let's call him Sam), or blaming him, good communication involves clarifying these assumptions. "Sam, did you send that email yet?" Sam replies, "What email?" "Sam, remember yesterday we spoke in the hall and you confirmed you could do this?" "Oh yes, I sent it a few minutes ago." Good communicators habitually clarify assumptions during discussions at key points, such as when commitments are made, and confirm them again before the deadline.
• Lack of clarity. There is no law in the universe claiming that others will understand what you're saying simply because you understand it yourself. No matter how eloquent you may be, if the other person doesn't understand you, then you're not eloquent enough for the situation at hand (as Red Auerbach said, "It's not what you say, it's what they hear"). The natural remedy is to step back, slow down, and break down ideas into smaller and smaller pieces until a point of clarity is reached, and then slowly build up from it. Find a story or analogy to give a rough framework that people can follow, and add detail to it until you don't need the analogy anymore.
• Not listening. In the movie Fight Club, the main character, Jack, says in reference to one of the many support groups he's recently joined, "They actually listen to me, instead of just waiting for their next chance to talk." We are compulsively bad listeners, and we tend to prefer the sound of our voices to that of others. Worse, even while people are speaking to us, we are often simply calculating our next responsecontinuing to defend our original line of argumentinstead of truly listening to their point. (The extreme form of this problem is simply not paying attention, as in reading your email while someone is talking to you. Despite doubtful claims of multitasking proficiency, it still sends a negative message to the person who's talking to you: "You are not worthy of eye contact.") The remedy is to always accept the possibility that they know something important that you don't. Your goal is not to force them into a position, but instead to achieve the best possible outcome for the project.
• Dictation. The evil twin of not listening is dictating. Instead of giving even the pretense of listening, people who dictate simply give orders. Any objections or questions to the order are rejected or responded to with disappointment or derision, as if it should be entirely obvious why the order is what it is and why it is being given without explanation ("What are you, stupid?"). This is not an act of communication because it's a complete violation of the framework covered previously: no attempt is made to reach understanding, much less agreement. Giving orders has its place, but it should be the exception. Instead, strive to make decisions in an environment where people have the right to ask good questions and propose challenges to your logic.
• Problem mismatch. Communication can mask many other problems. It's only when we communicate with someone that they have a chance to surface their feelings about other issues. What comes back in response to a request may be an expression of feelings that have nothing to do with the specific request ("Hey, can you read this spec?", "No! Never! Death first!"). There might be an unresolved issue about another decision that he hasn't expressed his feelings about yet. If neither party recognizes that there are different issues being discussed under the guise of a single issue, the discussion will be frustrating and difficult to resolve. Someone has to separate them: "Wait, what are we really talking about here? How to code this feature, or why you didn't get that promotion you wanted?"
• Personal/ad hominem attacks. Situations are often made personal when one party shifts the discussion away from the issue and toward an individual. This is called ad hominem (against the person). For example, Fred might say he doesn't have time, to which Sam replies, "That's the problem with you. How come you never have time for reviewing test plans?" This is unfair to Fred because he has to defend not only his opinion, but also his personal behavior. Personal attacks are cheap shots, and there are many different forms of them.(5) Often, the person taking the cheap shot feels vulnerable and sees the attack as the only way to win the argument. It's up to a more mature person (or perhaps Fred himself) to intervene and separate the issues.
• Derision, ridicule, and blame. When a person has a new idea, she is making herself vulnerable to whomever she chooses to share it with. It requires a feeling of trust to be forthcoming and honest. If she is consistently ridiculed or demeaned in the process of communicating important but unpleasant information, she will stop doing it. The first response to a problem shouldn't be "How could you let this happen?" or "You know this is entirely your fault, don't you?"

There are other problems that arise in communication, but this basic list covers many of the possible situations. Sometimes situations surface in conversations between two people alone in an office, and sometimes there are several people involved. The more people involved, the harder it can be to isolate what the problem is and take action to fix it. Sometimes, group discussions are the wrong place to solve communication issues because there are too many people and conflicts involved to resolve any problem effectively. Group communication is an issue I'll touch on briefly in Chapter 10, but for most of this chapter, I'll focus on simpler situations.
A simple tactic for making the previous list actionable is to share it with people on your team, and ask them to identify when someone is behaving in a problematic way. The team will now have a language for the problems they see, making it easier to identify and minimize those behaviors. Specific to team leaders, a commitment should be made to re-examine their own behavior and pay more attention to what they're doing and saying. Odds are high that they'll quickly identify habits that need to be worked on. (Change of any kind is tough. Organizational change requires those in power to take action. See Chapter 16.)
However, no matter how much you read or study about human psychology and communication, it will always be subjective. There's no mathematical formula you can use, or detection device you can buy, to help you recognize when you're about to cause a communication problem. The same applies to making others aware of communication problems they are causing. It's sensitive and complicated, and some people have years of experience with bad communication habits that they're unwilling to give up simply because you suggest that they should. This is one of the many reasons why project management is a tough role: you have to invest in relationships with people, regardless of how much they're investing in you.

9.4. Projects depend on relationships

Project managers are only as good as their relationships with the people on the team. No matter how brilliant or knowledgeable the PM is, his value is determined by how well he can apply those traits to the project through other people. For example, because programmers and testers do most of the actual work, any value the PM adds has to be through those people. This doesn't mean micromanaging them or becoming an expert in those skills; it's about seeing the PM role as amplifying the value of those other workers in any way possible.
The challenge is in how to do it. Every time I've given a lecture or taught a course on project management and convinced a group of this point, someone invariably raises her hand and asks: "So, how do I amplify their value? I understand that it's something I should do, but how do I go about doing it without annoying the crap out of them?" This is a fair question. Few people come to work wanting to be amplified or to have some person they might not like involved in their daily business. The answer is in understanding relationships. There is no one-size-fits-all way to add value. It depends on the person you're dealing with and what expectations have been set for the roles that person will play.
9.4.1. Defining roles

"The cause of almost all relationship difficulties is rooted in conflicting or ambiguous expectations around roles and goals."
Stephen Covey, author of The 7 Habits of Highly Effective People

In the previous list of communication problems, one of the most important issues regards assumptions and how to clarify them. The PM, leader, or manager roles are the most ambiguous and most prone to assumptions by others. Any programmer or tester will always carry the first experience they had with a PM (bad or good) as their model when working with all future PMs. The first time you walk in the door, the new team sees you as a projection of all of their previous experiences with PMs. They will assume different things than you will about what you can do and what value you might add to the team. No matter how well defined you think the job descriptions are where you work, there's always plenty of room for bad assumptions.
The easiest remedy is to clarify roles with any important person you know you will be working with: programmers, testers, marketers, clients, or even executives. Sit down with one person you work with and make three lists on the whiteboard. The first list is things that you are primarily responsible for. The second list is things that both of you share responsibility for. And the third list is things that others exclusively have responsibility for. As you work together to make the lists and discuss which items belong where, you will quickly recognize what expectations you have of each other (see Figure 9-2). Role definition flushes out all of the assumptions and baggage people have about what project managers, general managers, developers, testers, or anyone else is supposed to do.

Figure 9-2. Role-definition discussions help every relationship (this is just an exampleyour lists may look different from these).


At a minimum, you'll identify the places where you disagree, and, even if you don't resolve them all, you'll be aware of potential problems and can work more sensitively on those tasks. Most of the time, useful discussions will lead to a better understanding of roles and a clearer sense of how dependent both parties rely on each other to be successful. But perhaps most important is that this discussion is a framework both parties can use to discuss relationship problems in the future. The ice has been broken, and it's now easier to talk about roles, collaboration, and responsibility. Should there be a problem later on, it will be easy to come back to the lists and point out where something isn't working out as well as it should have.
The fear in having these discussions is largely about control. As soon as you put up on the whiteboard something you like to do, and offer it as fodder for review and debate, you're vulnerable to having it taken away from you (or so the fear goes). But as far as the PM is concerned, most of the time the things of greatest interest (high-level decision making, cross-discipline work, strategy) are the last things more technically focused programmers or testers want to be involved in. In fact, in most cases, there is great ignorance among the technical folks about what the PM is doing all day, and without some kind of role discussion, they have no way of ever discovering what the PM is doing (and because good PMs often do a lot of work to protect programmers and testers from politics, bureaucracy, and general management stupidity, the rest of the team might never have an opportunity to understand how much the PM is helping).
In the worst case, where there are huge gaps in perceived roles ("I don't care what your last PM did, I will not do your laundry"), it's time to talk to your boss and possibly the manager of the person you spoke with. There's no cause for alarm: the framework you used is the easiest way to bring the discussion to others and work toward a resolution. On larger teams, I've sometimes started this discussion with the manager of the programming team first, got his buy-in, and then worked my way down to line-level programmers. This makes sense if you think their support is necessary up front, or if you have a better shared understanding of roles with him than you do with some of the line-level programmers.

9.5. The best work attitude

An unspoken assumption of the workplace is that people are working hard and trying to do their best work. But because there's no way to measure how hard people work,(6) or what their best work actually looks like, managers rarely spend time talking about it. This is a mistake. A manager should help each team member cultivate a desire for achievement. The relationship between worker and manager must involve the manager assisting the worker in being as effective as possible.
It should be entirely natural and acceptable for a PM to ask a tester, developer, marketer, or designer the following question: "What can I do to help you do your best work?" No preface is needed, nor any caveats about what you might not be willing to do. Just by asking this simple question, three positive things happen:

1. You establish the possibility that the person you are talking to is capable of doing her best work on the current project and that perhaps there is something preventing her from doing so.
   
2. You put her in a framework of evaluating her own performance and identifying things she can do that might make a difference.
   
3. You make it possible to have a discussion about what both of you can do to improve the quality of the work being done. By framing the discussion around "best," you dodge the possibility that she feels criticized or that her current work isn't good enough.
   

This approach has nothing to do with being a nice guy or trying to make people like you. Getting the best performance possible out of the team is a direct responsibility of the PM. Figuring out how to make a designer or programmer more effective is not simply doing that person a favor, it's improving the quality and speed of the work done on the project. Of course, for a project to succeed, it might not require everyone's best work, but so what. If their pursuit of a higher standard doesn't hurt the projectand it clearly improves their own morale and personal investment in the teamthen it's worth the cost of asking a few simple questions.
Sometimes, when you ask people how to get their best work, the answer might be "Leave me alone," or "Stop asking me silly questions," or other less-than-useful responses. Even if they don't seem receptive, they will be thinking about your question, whether they admit it or not. I've had programmers shrug off my initial question ("No, Scott, there's nothing you can do"), and then come back to me a week later and make a great suggestion that ended up helping the whole development team. Plus, they thanked me for respecting them enough to ask their opinion.
The underlying attitude implied by all this is that when a programmer is falling behind, the PM's job is not to assign blame and yell at him to work faster. Instead, it's to help him to understand the problem, and contribute time and energy to help resolve it. Asking about his best work is an easy way to establish a supporting relationship with him. This attitude applies to any person or organization that is contributing to the project. Even if there are other demands on the PM's time, it's often best to prioritize assisting direct contributors to the project ahead of secondary political or bureaucratic matters. The former will always have a direct impact on the project schedule, but the later may not.
9.5.1. How to get people's best work

Great leaders rarely force people to do anything. Instead, they use every other means in their power to convince people to do things. Everybody has different strengths and weaknesses when it comes to motivating others, and it follows that better leaders tend to have a wider range of tools to use and more command over them.
Something I've seen in weaker managers and leaders is the over-reliance on one approach or method to try to get the best work out of people. If that one method doesn't work, they give up, claiming that there's nothing that can be done. Sadly, not much happens when the team leader claims there are no alternatives. Instead, when stuck, there's probably another angle to take that might work. It's possible that you're capable of trying another tactic, but also consider that someone else on the team might be able to help by lending a talent to the situation that you don't have.

• Follow advice. Listening to suggestions is one thing, but doing something about it is another. When they ask for more time for certain tasks, make it happen. If they suggest that there are too many meetings, let them suggest ways to shorten them. Take them seriously. Invest real energy in following through on what they need. Even if it doesn't pan out in the end, if you seriously take on the challenge of fulfilling their requests, they'll notice. The effect in the quality of their work will be similar to having succeeded. But, it has to be genuine. People can spot token managerial effort from miles away (they have lifetimes of experience observing it).
• Challenging/making demands. The most obvious and stereotypical way for a person in authority to get work out of people is to demand it: "40 push-ups, now!" The more intelligent, independent, or skilled the people you work with are, the less likely this approach will work. If the vision is good, the work is interesting, and people get along, there's little need to demand anything. Motivation should come naturally. When you need to light fires, find clever ways to do it. Place friendly wagers: "If we make this date, I'll dye my hair blue" or "Whichever team of programmers fixes all the bugs first will get an afternoon BBQ on my boat."(7) Demands have their place, but don't get mean, get honest. "Look, this needs to be done. It's too late to debate this, and I'm sorry if I wasn't clear before. Please, just deliver on this for me. OK?"
• Inspiring. It's very difficult to fake inspiration. Either you believe in what you're doing, or you don't. If you do believe, then you have to find some way to express it in a positive manner so that other people can feed off of it. "Look. I love this project. We are paid to learn new technologies and figure out how to apply them. That's rare and special, and it gets me to come here every day." It doesn't have to be elaborate or even eloquent. If it's honest, it works. Human nature reciprocates positive emotion, and when you bring something real out, you invite others to follow. More direct methods include asking people what they like about writing code, and helping them to make connections between those feelings and the work they have in front of them.
• Clearing roadblocks. Every great running back in American football had an unsung hero who paved the way for him. That unsung hero is called the blocker (a.k.a. fullback). He runs out in front of the running back and knocks over the first guy who tries to tackle the running back (usually someone much larger than he is). If you look carefully at any highlight reel where someone runs for 70 yards, you'll see another guy lying flat on the ground, buried under various large people, who was responsible for making the play possible. Good PMs make plays possible. They seek out and eliminate issues that are slowing the team down. Ask people: "Are you blocked by anything?" If they say they are waiting for a decision, or trying to track down information, it's your job to figure out if there's any way you can accelerate that process. They should know you are available to help if they ever feel blocked.
• Remind them of your respective roles. The most frequent way to enable best work is to remind people of their roles on the team. When a programmer complains that she is getting too many new-feature requests, the response should be that it's probably not her job to field requests: she should direct people to you (the PM). She's free to involve herself if she feels it's appropriate, but if it's late in the schedule, she should be using the PM to run interference. Sometimes people, especially programmers, are so focused on the work itself that they lose sight of the testers, designers, and managers around them who are often better suited to drive certain kinds of tasks than they are.
• Remind them of the project goals. As the PM or leader, you have more perspective on the project than any individual. It's easy for people to get lost in the complexity of their narrower areas of responsibility and lose track of what issues are truly important. A short conversation with you, where you refresh their understanding of what they're really accomplishing and why, can restore their focus, motivation, and effectiveness. Like the landing lights that identify an airport runway at night, making it easy for pilots to spot their way to safety, good PMs light the way.
• Teaching. If you have a skill or trick that people you work with can make use of, why not offer to teach it to them? Giving them a new skill or a tip for using an old one doubles the value of that knowledge. By teaching, you make it possible for people to get more work done faster and improve the chances of them doing good work, as well as possibly improving the quality of what their best work is. Noel Tichy, author of The Leadership Engine (Harper, 2002), has this to say about the importance of teaching: "You talk to a Navy seal [after he's learned something] and one of the first things he does is teach his buddy, because it will save his life. If I learn something...do I run back and teach people? Then can I do that on a larger scale? That's the trick."
• Asking. It seems obvious, but it's rarely done. Simply ask them for their best work. You don't need to explain why, or even necessarily offer anything in return. Just say, "Hey, I'd love to see your best work here. This work is important and if you have more to give, I'd like you to give it now."

9.5.2. The motivation to help others do their best

Early on in my time with the Windows team, I remember feeling like I spent all my time helping other people do their jobs. I was a relatively new manager (as in having direct reports), and after running around helping people put out fires and giving advice, I just wanted to be alone. I tried going to my office and closing the door, but people kept coming by. My voice mail light wouldn't stop blinking, and I didn't even want to look at the email that had accumulated while I was running around the building. I remember questioning why I spent so much time in other people's offices, and it took me awhile to come up with an answer I believed. But I found one, and here it is.
Those conversations were not ethereal or anecdotal things. In each of those conversations, I was doing something directly related to the goals of the project. This goes beyond the abstract importance of good relationships. Every time I answered a question at my door, negotiated with another organization, or argued for resources for my team, I was doing as much as any developer or tester to move the project forward. I was enabling them to write code, find bugs, and do 1,000 other things faster or easier than they would have otherwise.
My point is that if you carefully examine the conversations you have with people, and consider their impact on the project, you'll generally find every conversation contributes to one of the following things:

• Improves the quality of what's being made
• Increases the chances it will be finished on time
• Helps make the product/web site/software more useful for people
• Increases the chances the product/web site/software will generate profit or traffic
• Protects people from needless work, stupid politics, or bureaucracy
• Makes what's built easier to maintain
• Increases the morale or happiness of the people on the team
• Helps the team to work smarter and faster, and to apply (and learn) new skills
• Eliminates or clarifies behavior that is detrimental to the project or the team

So, even when you tire of clearing roadblocks, answering questions, or checking in with various people for different reasons, remember that the effort you put into those things is not wasted or of low importance. As long as you can connect those discussions, pep talks, fire drills, arguments, and discussions back to positive trends in the project (or the prevention of negative ones), they're essential to moving the project forward. You're doing work that no one else in the organization can possibly do as effectively as you can. However, if you find that you can't tie those conversations back to important things, stop having them. Prioritize your time, and your relationships, so that your energy goes toward the things that have the greatest positive impact.

9.6. Summary
Projects happen only through communication. In modern times, speed isn't the communication bottleneck, quality is.

Relationships enhance and accelerate communication.

There are several frameworks for how people communicate with each other. PMs should be familiar with them so that they can diagnose and resolve communication breakdowns.

There are several common communication problems. They include: assumptions, lack of clarity, not listening, dictation, personal attacks, and blame.

Role definition is the easiest way to improve relationships.

Ask people what they need in order to do their best work. Ways to do this include: listening, clearing roadblocks, teaching, and reminding them of goals.

Relationships and communication are not low-priority work. They are essential to all of the individual activities that take place during a project.

10.3. Non-annoying email
As remedial a subject as it seems, email is still the most annoying system people on projects deal with. Simply as a result of the volume of email we receive, it's easy to feel pressure to read and respond to new messages as quickly as possible, often sacrificing good reading and writing skills. Most of us, most of the time, just don't read or write email very well. What's ironic is that the speed and convenience of email are squandered when we can't understand what the hell the other person is trying to say, or we can't get her to understand what we're trying to tell them.

And perhaps of most importance to project management: email is a primary means of communication for leaders and managers. In both creating new mail and responding to mail sent by others, a leader influences and controls the flow of information through a project. If a leader has clear thoughts and asks solid questions, she encourages others to do the same. One response to a large discussion with dozens of people can send a wave of clarity through the organization. But, the leader hurts the team's ability to communicate well if she expresses fuzzy thoughts and makes obscure or obfuscated points.

One major challenge is that few people admit that they send bad email. (Their inability to recognize bad email is part of why they're bad at writing it.) For example, take the following test: using your own subjective judgment, what percentage of email that you receive from people within your own organization is high quality? Average quality? Totally useless? Now ask yourself what percentage of the email you send fits into each of these categories. As an experiment, I once asked a small group of PMs, testers, and programmers this very question. By a factor of almost 2 to 1, everyone claimed that other people wrote crappier mail than they did. Because they all worked together, this anecdotal data implied that everyone thinks the problem is email generated by others, not themselves. I don't have harder data to support this claim, but it rings true. Somehow, when there's a communication failure, on average people tend to blame the other guy (for copious evidence, see any history of international politics in Western civilization).

10.3.1. The good piece of email
One habit I learned at Microsoft was the reward for the good piece of email. Many important debates took place on email, and it was common for these discussions to include people at multiple levels of hierarchy; line PMs, middle managers, and VPs might all be exchanging mail back and forth, treating each other mostly as equals. I often found myself in the middle of these debates, usually because something I was responsible for suddenly became very important to the division.

Every so often in these email discussions, I'd make a really strong point in response to something someone else said. I'd carefully word it, revising it over and over to get it just right: simple, strong, and clear. Then I'd send it out. Sometimes my arguments would get torn apart; sometimes I'd be ignored. But on occasion, I'd hit a home run. When I did, I'd often get a private email a few minutes later from a VP or "other person much more important than I" that said only two words: "Good email." The discussion might still rage on, but I'd know that I scored some points in the argument. More important was this: someone took the time to let me know that my points were good, and that I was expressing them in a praiseworthy way.(1)

Smart managers value good email. Managers read so much poorly written email every day, and if they don't take the time to reward those who communicate well, they're unlikely to see more people do it. Little side emails take about 15 seconds to send, and as my story indicates, may mean more to others in your organization than you think.

But praising others is easier than taking responsibility for your own bad email habits. As I mentioned previously, I'm convinced that most people think they write better email than others think they do (and the more senior you are, the harder it might be to get honest feedback about your email etiquette). Because leaders and managers send more email than others, it's critical to sort out what bad habits you have and invest energy in curbing them. Here is some project management-style advice on what good email looks like and what some of the common bad habits are.

Be concise, be simple, and be direct. Pascal, the mathematician for whom the language is named, once wrote "If I had more time, I'd write a shorter letter." Language, like code, can be optimized, although the goals are different. Instead of optimizing for logical efficiency, you want to optimize for communication efficiency. Unlike code, a grammatically and logically correct three-word message is useless if the recipient can't figure out what the hell it means.(2) Consider who is reading the email and how you would explain or ask whatever it is you need to say if you were talking with him face to face. What details would be needed? Omitted? What concepts can you assume he knows? What metaphors can you use? For important email, step away from it for a few minutes and then reread it, with these questions in mind, before you send it. Or for important mail, or mail going to a large number of people, have one of the people on your team skim it over and give you feedback.

Offer an action and a deadline. The best kind of email has a specific intention or request that is clearly stated, and, if appropriate, is tied to a reasonable deadline. It should be easy for people reading the email to understand why they are receiving it, how they are impacted by the action, and what they need to do (before the deadline). Assuming you enforce the deadline ("Requests must be in to me by Friday"), you set yourself up for people to be attentive to future actions you communicate through email, which puts you in a position of power.

Prioritize. Is it really necessary to send that email? The more emails you send, the more work others will have to do to prioritize your requests. How many of the things you're mentioning are important? If you have 10 issues to discuss, break them into two groups and focus on the most important group. Consider if some things can be better handled on the phone, in the next team meeting, or by going door-to-door. If you don't prioritize, expect the recipients to prioritize for youin a way that serves their interests, not yours.

Don't assume people read anything (especially if it's important to you). It's arrogant to assume that because you sent it, someone has read it. People get tons of email every day, much of it from people just as important as you are. The more important the issue is to you, the more energy you have to expend to make sure people actually see it and are actively doing something about it. The more trust you've built with the people on your team, the more assumptions you can make about how people will respond to things you send.

Avoid giving a play-by-play. It's rare that anyone needs to know the sequence of events that led to something happening. Avoid writing emails that focus on the contributing actions by different players: "When Sally first designed our build process, she was interested in..." or narrative-driven prose like "The meeting started off fine, with Bob and Steve talking through their slides with great passion and conviction. That is, until...." Instead, focus on impact: what happened, how this changes the world, and what we're going to do about it. If you're compelled to include background details, list them below the critical points. The same goes for references to slide decks, web sites, papers, etc. Make it possible for anyone to skim the first two lines and know immediately if it's important enough to them to read any further.

Sequester FYIs. I've been on teams that persisted in forwarding tons of semi-interesting-but-not-directly-relevant-to-anything email. Some people call these FYIs, or for your information emails. Curiosity and industry awareness are fine habits, but don't let them dominate communication forums used for more tangible work. Set up an email alias or discussion group for "industry trends" or "tech watch," where your team can post the cool things they find. If your email client supports it, ask everyone to set these kinds of emails to low priority, or add "FYI:" to the front of the subject line. Make this stuff easy for people to filter out.

The telephone is your friend. If ever you don't understand something in an important email you've received, don't respond with an elaborate five-part question. See if you can reach the sender of the email on the phone. Interactive communication is always better at resolving confusion and conflict than email. A 30-second phone conversation is often equivalent to a long series of time-consuming email exchanges. If you do get the sender on the phone and resolve the issue, you can then share your clarified understanding in an email sent to everyone: odds are good that if you were confused, so were others. Telephones (or a walk down the hallway) are the great expediters of group email communication.(3)

10.3.2. An example of bad email
Awful email is easy to recognize. Awful email is often very long, poorly written, has many attachments, and is hard to skim. It can be spotted from very far away, and it is usually either ignored or challenged appropriately: "Fred: I found this email very confusing. If others agree, can you either revise or call a meeting? If not, I'll call you. Thanks." For this reason, awful email is not the most dangerous kind.

The really dangerous emails are the ones that look like well-written communication but are, in fact, ripe with distractions, half-baked thoughts, and ambiguities. What follows are two examples of the same email: one bad and one good. Here's the bad one.

From: Jack Colono

To: Striker development team

Subject: Summary of recent checking discussions

Over the last four weeks, many of us have wondered when the process for redesigning our code check-in procedures would finally be complete. I know it's taken a long time and that there has been much debate in hallways and meetings about the right way to go about deciding on, much less figuring out, the actual design for the new procedure as well. Choosing the members of the committee was not easy for me, and as many of you know, took more time than expected. Apologies for that, but these things happen.

So, first I'd like to give you some of the highlights of our new proposal, in case you missed one of the weekly discussions we've had, or didn't come by to chat with me about it over the last two weeks:

1) Check-ins are very important. They determine what we're really building.

2) Everyone has opinions. We've all heard Randy and Bob each describe in detail why they think the current system is so bad.

3) There are no easy answers. Most of the changes we've discussed all have downsides. So, when we do finally reach a conclusion, there will be some rough edges on transition and possibly on an ongoing basis.

With that out of the way, I'd now like to let you know that later this week I'll be sending out the revised proposal. Please be on the lookout for the next piece of email from me. It should be coming soon.

Thanks,

Jack

10.3.3. An example of good email
Unlike the bad example, this email does not tell any stories or try to justify anything: it's all action. It's short, clear, and to the point. Instead of talking about proposals, it actually offers one. While it has the flavor of an ultimatum, it serves the purposes of creating escape velocity for the proposal, helping to push it out the door.

From: Jack Colono

To: Striker development team

Subject: New check-in process

The final proposal for the new check-in process is complete and is up on the web site: http://intman/proc/checkin/.

Because this has been a contentious issue, I've discussed this proposal one-on-one with much of the team and incorporated everyone's feedback. If this didn't include you and you have strong opinions, please send me mail ASAP.

But be warned: this is the second public notice about these upcoming changes. The opportunity for making changes is currently small and is getting smaller by the day. Please act now or prepare to hold your peace.

Friday at 5:00 p.m. is the deadline for contacting me with feedback on the above proposal. I will consider and respond to any questions or comments raised before then (in collaboration with appropriate folks). Otherwise, this matter is closed and will become effective next week.

Thanks,

Jack

As clear as the difference between these two emails should be, don't read too much into these examples. They're not meant to be templates for things to always or never do. Each email you send might have a different purpose, and it might make sense to contradict these examples. As long as you're writing it thoughtfully and with clear reasons, do whatever is necessary to get the job done. But always be on the lookout for ways to cut to the chase and use email to make things happen.