Section 10.4.  Manage Your Team

10.4. Manage Your Team Many project managersespecially those who have been promoted from technical positionsfeel like their primary job function is to understand the job each team member is doing. Often the best programmer, designer, or tester will be promoted into a management position. And in many cases, this is a very good choice, because it's important for a manager to understand the work being done by the team. Sometimes the project manager is also the direct manager of each team member, and in this case, he is especially vulnerable to certain management pitfalls. Understanding the work that the team is doing is very important; however, the primary task of a manager is to have the right people do the correct work and, ultimately, to get the tasks done in the most efficient and least problematic way. The first instinct of a manager who got to where he is by being a good programmer will be to be the best programmer on the team. That's not what the team needsthey need someone to make decisions, provide guidance, and prioritize their tasks. If all he does is "get his hands dirty" by solving programming problems for his team, they will not only sense a lack of direction from their manager, but may also feel demotivated because their work is not valued. In contrast, some managers understand that their job is to delegate. But while delegation is an important part of management, it must be done with a good understanding of the work being delegated. The manager may not be the best engineer in the group, or even be able to perform all of the engineering tasks he assigns. He should, however, understand the goals and limitations of each task, and be able to offer real guidance if team members get stuck or need help. That's much harder than delegating: while he's trusted a team member to accomplish the task, he must still understand enough about it to be useful if that team member encounters a problem. Good managers usually feel a little guilty about being managers. They know that their people are good, and they want them to succeed. But this necessarily involves riding their coattails. As a manager, you might feel that in some ways you are not making a direct contribution by producing work products. This is a good feeling: embrace it. Recognize that your role is to "grease the wheels" by providing an environment in which work gets done. And the best way to provide that environment is to show the team that you trust them to do the work. Show the team that you are there for them when they need you. When you make decisions about the project, make sure that you are always fair, just, consistent, and predictable. That way, when people disagree with you, they can at least understand why you made that decision and will remain motivated and loyal to the project. 10.4.1. Avoid Common Management Pitfalls Poor managers are distinguished by their poor habits. They tend not to question their own authority, and they frequently don't have much faith in the people who work for them. They distance themselves from their projects, and tend to see their jobs as simple, intuitive, easy, and straightforward. A manager who acts this way projects hubris and arrogance; some people find that reassuring, but most engineers find it condescending. The best way to improve as an engineering project manager is to avoid these pitfalls. The best way to avoid these pitfalls is to question each decision that you make: Is the decision based on facts, or are you automatically jumping to a decision based solely on intuition and gut instincts? Are you unfairly questioning your team's honesty, integrity, or skill? Are you making a decision that is politically motivated? Are you simply siding with the person you like better? Are you oversimplifying a task or avoiding its internal details out of laziness? By understanding the root cause of many common pitfalls, a project manager can keep his team motivated and avoid bad decisions that lead to serious project problems. It requires constant vigilance to avoid those problems. 10.4.1.1. Don't manage from your gut There is a common belief among many managers that decisions should make intuitive sense. This is generally true. However, the conversethat all ideas that make intuitive sense are good decisionsis definitely not true. Software projects are complex. They involve many people serving in different roles, sometimes with multiple roles per person. They involve numerous tasks and subtasks, where each task may be assigned to several people. As a manager, you can't expect to intuit all of that complexity. Just because you, as the project manager, have the authority to make decisions about the project, that doesn't mean that it's your job to overrule people all the time. It's your job to understand the issues that face the team, and to help the team deal with those issues. Think about it rationally: if a team member disagrees with a decision that you have made, and comes up with a well-researched and logical explanation for her disagreement, is it fair to dismiss her opinion simply because it does not immediately make intuitive sense to you? There are many things in the world (especially in complex engineered products) that simply are not intuitive to most people. For example, it seems intuitive that doubling the staff on a project should allow them to complete it in half the time. However, in the real world, projects are much more complex: there is overhead in the extra communication, certain tasks on a critical path cannot be split, it takes time for new team members to ramp up, etc. But that doesn't stop many project managers from trying over and over again to throw additional team members at a late project, only to find that it becomes an even later project.[*] [*] Fred Brooks pointed this out in his 1975 book The Mythical Man-Month. He referred to it as Brooks' Law: "Adding manpower to a late software project makes it later." Unfortunately, software project managers have to make decisions based on complicated information all the time. To make good decisions, you have to understand software engineering concepts and technological concepts that are not intuitive, and remain open to the idea that there have been recent innovations or changes in software engineering and technology that may contradict your current beliefs. This job is about being informed, not about feeling your way through problems. A project manager must make many individual decisions: who to assign tasks to, how long they should be expected to take, whether to implement certain features or requirements, the dependency between tasks and software behavior, and many other design, development, and testing decisions. There is no way that even the best project manager can be on top of every detail in an average-sized software project. But these decisions still must be made. So how can you make them without simply relying on your intuition, but also without being overwhelmed by the details? Luckily, your project team is staffed by competent software engineers who are capable of building the software. (If your team is not competent, you have bigger problems!) This means that you have at your disposal people who can help you make those decisions. You should enlist their help and work to understand the perspectives of all of the people involved in the project. When you make a decision, you must understand which team members it affects and take their perspectives into account. If you don't know those perspectives yet, ask the team members their opinions. Most people will be more than happy to help you decide the direction of their tasks, and you will almost certainly get better results because they participated in the decision-making process. If you try to learn all of the details for every decision that must be made, you will find that your projects will quickly get bogged down, with everyone waiting for you to decide on at least one issue. But if you work with your team to make well-informed decisions, you can share that load...and everybody wins. That's why you have a team: so people can collaborate. 10.4.1.2. Don't second-guess estimates Many managers fall into a common trap when considering their team members' estimates: they automatically cut those estimates, no matter how reasonable or well researched they are. There are generally three reasons this is done. One reason is that the organization already committed to an earlier date for the software, and changing that expectation is difficult or impossible for the manager. This means that the project was not planned properly. The solution is to apply the project planning and estimation tools and techniques to bring the project under control. If the estimate does not meet the needs of the organization, the manager has several options: the scope of the project can be scaled back; the software can be released in phases; the deadline can be renegotiated; resources can be added; or some combination of all of these can be done. The team will generally respect the decision, as long as it was clearly based on honest estimates and planning rather than an artificial date. The second reason that an estimate may be second-guessed is that this second-guessing is a misguided attempt to motivate the team. For some reasonand nobody is really sure why some people believe thisthere are managers who think that telling somebody that they can do a task in less time than they estimated will cause them to "step up to the plate." Somehow, knowing that their manager believes that they can do it is supposed to increase their productivity. Unfortunately, this sort of second-guessing becomes a self-fulfilling prophecy. As the team realizes that their estimates will always be cut, they will start padding those estimates. This can create an environment of distrust between the team and their manager. The third reason managers will second-guess their teams' estimates is to force them to work overtime. By enforcing an overly aggressive deadline, some managers find that they can squeeze five, ten, or more extra hours per week out of all of their team members. This is especially dishonest, and it almost always breeds resentment. If the team is expected to work overtimeand in some cases, this is a valid and realistic expectationthat should be taken into account when the effort estimates are turned into a project schedule. This way, the team is not blindsided by the extra work and can plan their lives around it. (Sometimes managers forget that people have lives outside the organization!) In all of these cases, the key to understanding how the team members react to second-guessing is to recognize that they believe their manager is sending them a clear message: he does not trust their estimates. The solution to this is to establish trust by making decisions in a transparent manner. (A good way to do this is to use a repeatable estimation process like Wideband Delphisee Chapter 3.) This does not mean that the project manager does not need to understand estimates. It is important for a project manager to not only understand the reasons why the team estimated a certain effort for a task, but to question the estimate if it looks inaccurate, unrealistic, or seems to be based on incorrect assumptions. As long as the questions are reasonable and can be answered with facts, the team will generally respect them and work to answer them. If it turns out that the estimate is, in fact, unrealistic, the team will be glad that the project manager pointed out a potential problem with it! 10.4.1.3. Don't expect consensus all of the time Over the course of almost any project, there will be disagreements between team members. Some project managers make the mistake of expecting the team members to settle all of these disagreements, reaching a consensus on their own. The project manager treats all disagreements as if they were merely petty or politically motivated, rather than based on a genuine difference in opinion over some important issue that affects the project. When two team members have a genuine disagreement, it is the manager's job to make a decision. That decision is going to leave at least one of the team membersand possibly bothunhappy. It is important to share the reasoning behind the decision with everyone, and to stand behind the decision. If it turns out to be wrong, it's the project manager's fault, not the fault of the person who originally proposed the solution or of the person who didn't fight hard enough for the alternative. To make a good decision, the manager must understand both perspectives. It's not enough to just tell the two people to go decide among themselves: if they could do that, they would not have brought the disagreement up with their manager in the first place. Sometimes a compromise can be reached, but most team members are capable of recognizing when a compromise is available, and implementing it themselves. If you treat each conflict as if it were a trivial or petty argument and tell your team members that it's their own responsibility to solve it, you are essentially asking one of them to acquiesce on something that he clearly thinks is important. That is unfair and divisive, and it makes both team members feel as if you do not care about their concerns or the project itself. That's not to say that there are no problems that cannot be left to the team. Sometimes a problem really is petty ("Bill stole my stapler!") and the team members really should at least try to work it out between them before involving their manager. But even these problems can escalate, and if that happens, a concrete decision ("Buy another stapler") is the only way to make the problem go away. It's important for a project manager to learn to differentiate between trivial problems ("Someone keeps taking the last donut") and more serious ones ("Tom won't let go of his ridiculous database design"). Regardless of the magnitude of the problem, if two people on your team care enough about a problem to come to you with it, you should take it seriously. If you dismiss it and tell them that it's their problem to solve among themselves, you are making it clear to them that even though you are their manager, you do not care about the team members' problems (and, by extension, the project itself). 10.4.1.4. Avoid micromanagement When a manager is overly involved in each task to the point that she personally takes over the work of each person on her team, she is micromanaging. From her point of view, there are a lot of benefits to micromanaging her team: It endears her to the people at or above her level, because it seems like she always knows everything there is to know about what's going on with her team. She knows that no mistakes will ever make it out of her team. She does not have to trust the people who work for her to do a good job. Instead, she can review everything they produce to ensure that each work product meets her standardsand she will redo anything that does not meet those standards. It makes her feel very important, because nothing gets done without her. It allows her to feel superior to everyone who works for her. She gets to steal her team's thunder, taking credit for all of their accomplishments while blaming them for any failures. Her micromanagement has a devastating impact on the people who work for her. They feel that they have no responsibility whatsoever for what they do. They are not trusted. If they produce poor work, she will fix it, usually without explaining what they did wrong and often without even telling them. They feel like they do not have any impact, positive or negative, on the final product. And they're right. Many people will put up with this situation for a long time. They can continue to collect a paycheck. The job that they do is not particularly stressful, because any work that does not meet the organization's standards will be redone for them. They are not trusted to set priorities, make decisions, or do any aspect of their jobs. This is very inefficient for the organization, and very demotivating for the team members. While they will tolerate the situation, the team members are neither challenged nor fulfilled. Meanwhile, their manager is drowning under all of the work. Nobody is happy with this situation. There are a few easy rules that will help you avoid micromanagement: Don't expect to review everything Many people think that to be an effective manager, you have to have read, reviewed, and redone all of the work of the people who work for you. A good manager will spot-check the team's output, but reviewing (and possibly redoing) every piece of work that the team creates is a terrible use of a manager's time. Delegation requires trust; if you do not trust your team to do their jobs, then you should fire them and replace them with people who you do trust (or don't replace them, so the organization does not have to pay their salaries). Don't fall into the "hands-on manager" trap There is a general perception in the technology world that management is not an actual job. It's often believed that competent engineers manage themselves, while their incompetent "pointy-haired" bosses just get in the way. This is simply untrue. Competent engineers can be trusted to produce good requirements, designs, test plans, and code; their focus is not on prioritizing or managing teams of people. They can't do your job for you, so don't try to do theirs for them. Many managers assume that because they are responsible for the work that their team produces, they should be able to do all of it. That's just not truethe individual team members have time to build up their expertise in developing the software, while you only have time to manage the project. Instead of trying to fill in as a technical team member, work on building up your project management skills. Use transparency to your advantage Some people fall into the trap of thinking that the job of project manager consists of constantly bugging each team member for status reports. Team members have trouble with this. They are surprised and unhappy that their project manager doesn't know enough about the project to glean even the most basic status; they also feel that they are not responsible for reporting their status upward. The project manager always goes to the team members, so they don't ever feel the need to report problems unless directly asked. If all project plans and work products are kept as a matter of public record, the team members don't need to deal with a project manager constantly bugging them for status reports. If the project has transparency, each team member is responsible for his own status communication. If your team is falling behind, don't just ask them for their statusthis will encourage them to give you excuses. Instead, gather the status yourself using the documents that you have made public, and ask them about specific problems. Transparency only works if you make it clear that there are consequences for poor performance, and that poor performance is evident from public documents. Given this, people will see what's required of them in order to do a good job. Don't be afraid to let your team make mistakes People learn from their mistakes, and it's important that they be given the opportunity to make them and take responsibility for them. If they are going to grow professionally, it is going to be through their own experiences and through trial and error. Without this, team members will never see that their success takes effort to achieve. If a micromanager simply corrects all of their mistakes and redoes their work, they have no incentive to learn or improve. It's okay for your team to make mistakes, as long as you're on top of it. The way to stay on top of mistakes is through the peer review tools. This allows team members to share information and help each other to grow to a standard that is in line with what the project needs and what the organization requires. 10.4.1.5. Make your mistakes public If you make mistakes, you need to communicate them to everyone around you. It's okay to make the wrong call. Good managers recognize when they have made mistakes and correct them. The best managers publicize those mistakes so that everyone can learn from them, and so no one is blindsided by them. When a team member makes mistakes, the project manager should share in the responsibility. Many project managers don't realize that they are culpable for the mistakes made by their team members. The reason the manager is culpable is because he assigned the task to the team member, allocated the resources to do it, set the priorities for the project, and set and communicated the deadlinesall of which were contributing factors. For example, if somebody makes a bad decision because she failed to understand the project priorities, the project manager shares the responsibility for the error. That doesn't mean the project manager is solely to blameif there were 20 people in the meeting where that priority was communicated, and 19 of those people understood it, the one person who ended up making the mistake should have spoken up at the time. But it still means that the project manager was not entirely clear, and failed to communicate the project priorities to everyone on the team. So when that mistake gets made, it's still partially the project manager's fault. Just as it is okay for team members to make mistakes as long as they learn from them and corrective action is taken, it is okay for project managers to make mistakes as well. That's not to say that there are no consequences for mistakesa serious mistake can lead to delays, which could lead to reprimands and even failed projects. As a project manager, if you find that one of your team members has made a mistake, it's your job to figure out what role you played in that mistake. And when you communicate that mistake up to senior management, you should highlight your role in it and try to shield the individual team members as much as possible. This is very difficult to do. It's human nature to blame others. But by taking the blame yourself, you protect the team and keep them motivated, and help prepare them to recover from the mistake. If you stick your neck out for the team, they will know it, and they'll be much more loyal to you. On the other hand, if you let the blame roll downhill, the team will resent you and begin to work against you. Some project managers don't think this is fair. They feel that if someone makes a mistake, it's that person's responsibility to take the blame for it. But the project manager is in a position of authority, and just as other people are accountable for their individual responsibilities, the project manager is accountable for everything he is responsible for. And he's responsible for the entire project. 10.4.1.6. Avoid lists Some managers do little more than hand their team members lists of tasks or action items. When a team member is handed a list of tasks, but has no understanding of the rationale behind each action, he does what he can to complete the task. But without a real understanding of the needs that drive the project and the rationale behind each task, he will often make basic mistakes that would be obvious if he were given the proper context. There will always be decisions that a manager cannot predict and put on a list; without context, a team member has little chance of making those decisions correctly. It's easy for a team to feel comfortable working from a list. It means that they are not responsible for anything other than this list of tasks. They don't have to think about overall project goals or the bigger picture. Most importantly, they don't have to make decisions. Accomplishing everything on a list of tasks is gratifyinga team member can go home at night knowing his job is 100% complete. But someone who feels responsible for the project, and not just his own tasks, knows his job is not really complete until the software is delivered and accepted. Sadly, once a team member understands the big picture, he feels like he's never done. Your job as a manager is to get everybody on the team to see the big picture. The vision and scope document is a valuable tool for this, as are the rationale sections of the use cases and requirements. These tools allow the team members to more fully understand the context that surrounds the work that they are doing. Software project teams are made up of smart people. It's far better to leverage their minds than to treat them like robots. Many people like to throw around the term "grunt programmer," as if there were a lot of programming tasks that were little more than cutting and pasting program recipes. But even the lowest impact programming tasks involve decision-making on the part of the programmer. 10.4.2. Accept Criticism There are two ways that managers encounter criticism from a team member. One way is when the team member disagrees with the way a manager wants work done. The other is when the manager disagrees with how the team member is doing the work. Dealing with criticism is a potentially demotivating situation, but it's also a potentially encouraging one if handled well. Sometimes the team members solve a problem differently than you would. As a manager it is important to recognize the work that has gone into these solutions, even if they contradict your preconceived ideas about that work. Being able to accept the team member's criticism of your solution means that you are making decisions in the project's and organization's best interests, and motivates your team to keep thinking their way through such problems in the future. Everybody solves problems differently, and it's a fact of life in software engineering that most problems have many correct solutions. When you ask a team member to solve a problem, it's likely that she will come up with a correct solution that is different than the way you would solve the problem. If a member of your team offers a solution that is technically correct, but you don't accept it because you would do the work in a different (but equally valid, or even slightly more efficient) way, the team member will feel crushed. A good manager's default action should be to accept, not reject, ideas. You must take it very seriously when you reject somebody's work, and when you do, you should always explain and defend your decision. There are many good reasons to reject a team member's solution. Sometimes it's incorrect, and sometimes it's not well thought out. But people will become very attached to such solutions, even when they are dead-on wrong. In those cases, you must be willing to stick to your guns. When you do, it must be for the right reasons, and you must take the time to explain your reasoning. Criticism goes both ways. Sometimes a manager will want the team to do their work one way, and some team members will disagree. In fact, sometimes the entire team will disagree with a decision and come to the manager en masse. In this case, it is very tempting to just roll over and give in; it is equally tempting to refuse to even consider their opinions. Neither of these options is good, because no real discussion takes place in either case. Instead, a good manager will come up with a real justification for why he wants the work done that way, and will expect the team to do the same. If there is a real, verifiable reason for going with one alternative, everyone should be able to see it. And most importantly, the manager should show that he considered the argument, even if he essentially rejects it. Ultimately, you won't be able to make everyone happy. It's always better if everyone can agree, but there are many times when there is a genuine difference of opinion. In this case, the manager is within his rights to pull rank. However, if he just rejects an argument outright or ignores a valid argument just to get his way, he is abusing his power, and his team will resent him and try to figure out ways to work around him. They will also avoid coming to him in the future, opting to apologize later rather than ask permission now. Another way to help team members accept your decisions is to have written guidelines that they can follow. If you can point to a published document that guides the way that your team does their work, your team members will recognize that and respond to your consistency. It's much easier to work with a manager who is consistent and predictable than with one who may randomly reject ideas with no real justification. The tools in this book are examples of the kinds of guidelines that a team can adopt. For example, a manager may have a written guideline that says that every programmer should follow the Subversion basic work cycle (see Chapter 7). Then, even if a programmer feels that it's not her responsibility to merge changes that occurred since a file was checked out, the manager can refer back to the guideline and show that he is being consistent in his decision to have her merge her changes. 10.4.3. Understand What Motivates Your Team Members Talk to your team about their goals. If an employee's goals are incompatible with his company's goals, he should not be working for that company. However, each person's goals go beyond simply finishing the current project: people want to move ahead in their careers, and part of your job as project manager is to help them achieve their professional development goals. The organization gains when employees improve, because a more experienced employee will deliver superior work. A team with people who have more experience can take on more complex projects and come up with more creative solutions. People work for money. For some reason, many bosses feel uncomfortable with thisthey pretend that people work out of loyalty, love of the job, or blind devotion to the organization's goals. This leads to an unfortunately pervasive attitude where managers act like their employees are lucky to have jobs. Compensation also comes in many forms: in addition to money, some organizations will give flexible hours, training, books, stock options, free lunches, senior titles, access to new technology, or other perks in place of money. But in all of these cases, people need to feel that they are being fairly compensated for the effort that they are putting in. Another motivator is loyalty. Many people naturally develop some loyalty to the organizations where they workit is human nature. This is why teams of people who are poorly managed and undercompensated will still work 80-hour weeks on projects that are clearly doomed to failure. Unfortunately, it's very easy to redirect loyalty, especially through dishonesty. In some cases, a poor manager can keep secrets from the team and lie to them about organizational decisions, in order to redirect the team's loyalty from the organization to him. In other cases, senior management themselves can, through lying, incompetence, and obvious lack of appreciation, lose the team's loyalty. 10.4.4. Don't Be Thrown by Dishonesty People lie. They will say that they have completed things that they haven't, or that they understand things that they don't. They will make commitments, and then claim they never made them. Having a dishonest person working on a project is possibly the most difficult situation a project manager can face. There are some things a project manager can do to discourage dishonesty. By keeping all work out in the open and admitting your own mistakes, you can create an environment where people are more honest. But this only goes so farsometimes people lie, and you'll have to deal with it. The best-case scenario is one in which you have evidence that directly contradicts the lie. If you find that somebody is lying, you need to present him with that evidence. The purpose is not to make him feel bad; rather, it is to help him understand that it's wrong, and that he shouldn't do it again. Don't get caught up trying to understand why someone is being dishonestit could be a misunderstanding, it could be malicious, or it could be something else entirely. Sometimes the person doesn't even realize that he's lying. The key is to have enough information available so that you can set the situation right and keep it from threatening the project. Unfortunately, in some cases, there is no evidence to counter the lie. When this occurs, there may be nothing that you can do about the situation. If you think that someone is lying and you don't have evidence, you can set about collecting that evidence. Usually a lie is about a commitment that was made: the person may have agreed to do a certain task in a certain way, and is now claiming that she never made that commitment. Information about the commitment may be in an email, a project document, or a task definition in the project plan. But if the commitment was less formal (such as a verbal agreement), there may simply be no record of it. If there is not enough evidence, you may have to let the lie pass and live with the consequences. This is a very frustrating situation. In this case, your job is to improve the way you manage your commitments and those of your team, in order to prevent problems like this from happening in the future. You can collect better information, change your expectations, help people feel more comfortable letting you know if there are problems, and, in extreme situations, avoid working with people who have trouble being honest. Note: More information on commitment management can be found in Managing the Software Process by Watts Humphrey (Addison Wesley, 1989). 10.4.5. Address Performance Problems Early It is difficult to effectively manage teams without defining their goals up front. The best way to do that is to involve each person in the definition of his or her own goals. Each of these goals should be specific, measurable, should pertain to their work, and should be attainable. One effective way to do this is to work with each team member to develop a performance plan, which is simply a list of goals that the manager and team member agree to. People need to feel that they understand what is expected of them. The purpose of the performance plan is to set standards that are fair and attainable, and that are developed with the involvement of the team member (when possible). Your team members will feel more comfortable with their jobs if they feel they are being asked to meet reasonable goals and perform within their abilities. On the other hand, when someone does not know what is expected of him, you may feel he is doing a poor job when, in reality, he simply does not know what you expect of him. (You may not know, eitherwhich is another reason a performance plan is useful!) The manager should measure each team member's progress in meeting the goals listed in the performance plan. If the organization's operating environment changes, the manager should work with the team members to change those goals. In many organizations, team members do not report directly to project managers; rather, they report to people who manage development or QA groups in the organization. However, a project team member whose goals are poorly defined or in conflict with the objectives of the project can threaten the project's success. When the success of the project is threatened, it is the project manager's responsibility to remove the threat. This may require that the project manager help the direct manager establish a performance plan. You may find that your project team members' professional goals, set by their direct managers, conflict with the objectives of your project. For example, a programmer on your team may feel that meeting the deadlines for delivering code is more important than carrying out code reviews and unit testing, which he sees as optional, "extraneous" activities. By failing to do code reviews and build unit tests, he meets his personal deadlines, but he causes the project to be late because it spends more time in testing. If the programmer reports to a development manager, for example, it is your job to bring this up with that manager. One way that you can suggest that he fix the problem is by building a performance plan that includes goals that are quality related. It is important to correct performance problems as early as possible. Many project managers make the mistake of waiting until the end of a project to try to address performance issues. If a team member is not doing his job properly, the project manager may not have the authority to fire or discipline the team member. But he can have that team member removed from his project, if he is unable to correct that person's behavior by either dealing directly with the team member or going to the direct manager. By addressing the problem as early as possible, the project manager limits the risk to the project.