In the fifty-plus years since I started doing development work, I have worked on, led, managed, directed, assessed, or coached literally hundreds of creative development teams. While I have drawn many lessons and guidelines from this experience, the one clearest message is that leadership makes the greatest difference. Without exception, truly creative work is done by teams with very capable leaders. What is most interesting, however, is that these great leaders are generally ordinary developers like you and me, but when thrust into a leadership position, they do an outstanding job.
What is equally interesting is the converse. When development projects fail, it is almost always because of poor leadership. In this book, I describe the differences between an ineffective leader and one who does a superb job. The objective is to help you understand, anticipate, and correct the most common leadership failings before they cause you or your team problems. I wrote this book because I have seen many smart and dedicated developers make basic leadership mistakes. This is a shame, because it is totally unnecessary. Leadership is not a complex subject and anyone can be a great leader.
When I was first made team leader, I had just joined a development group at my first job and did not know any of the team members or have the vaguest idea what they were doing or why. I didn't even understand the organization or the technology. While things worked out well in the end, it was due more to the marvelous people on my team than to any special insight or skill on my part.
However, I have found that this is not unusual. Given half a chance, your people will be very helpful, even when you are the new boss and they know much more about the job than you do. While there will be occasional exceptions, people want to like and respect you and they want you to succeed. They will tolerate your dumb questions and silly mistakes as long as you are willing to admit your mistakes and laugh at your goofs. Be honest about what you know and don't know, and assume that management had a good reason to make you the team leader.
After I had worked for a few years, I was asked to lead a larger group in another department. I knew the people pretty well and also knew a great deal about the job. This time, however, my reception was not nearly as smooth. One of the more experienced members of the new group was older than I, and he and several team members thought that he should have been the team leader instead. While this situation took a bit longer to straighten out, the team finally came to terms with my new role and we established a good and productive working relationship.
The way teams perform depends to a great extent on how they relate to their leadership. However, I have found that the way your team relates to you will depend on a host of factors, many of which you can influence but some you cannot. In this book, I describe these factors and suggest ways to deal with them. These guidelines have helped me and I hope they will help you.
Who This Book Is For
This book is for people who are now leading or would like to lead a development team. It describes the team leader's job, the essential elements of leadership, and the many issues and problems you are likely to face. While I can't pretend to have all of the answers, I have had a lot of experience leading teams, and I have worked with a great many teams and team leaders. Since every team is different, and most teams grow and evolve over time, there is no magic formula for being an effective leader. However, there are some principles and guidelines. Whether you are a new or an experienced team leader, this book discusses many of the issues you will likely face and has examples, guidelines, and suggestions on how to handle them. It summarizes my observations and experiences in a form that will help you to address almost any kind of team and team leadership situation.
The Kinds of Teams Addressed
While there are many kinds of teams, this book concerns leading development teams. A lot has been written about sports, military, and production teams, but little material is available on development teams and even less is written about leading such teams. Since many of the teams I have worked with have had leadership problems, I have concluded that this book is needed. My intent is to talk about leading any kind of development team, but most of my recent work has concerned teams that were developing software-intensive systems. Therefore, my examples and much of the process discussion concerns these types of teams. In my work at the Software Engineering Institute (SEI) at Carnegie Mellon University, we have developed the Team Software Process (TSP). As the name implies, this process is designed to guide software development teams. The TSP has been used by many teams that included hardware, software, systems, requirements, test, and other professionals. It has also been used by some teams that have done little or no software development. So while the book mentions TSP in many places, you will find that the concepts and much of the guidance applies to any kind of development team. Few things that are worthwhile are free, however, and your people will need new skills to use the TSP. These skills are taught in Personal Software Process (PSP) training.
How This Book Is Organized
The five parts of this book address the principal aspects of teams and team leadership. Part I discusses what management and the team expect from you. It then describes the conditions for team success and the kinds of teams needed to do development work. Following the discussion of what and why in Part I, Parts II through V and the appendices deal with how: how to do what it takes to be a great leader.
Part II starts with a brief overview of the Team Software Process and how it can help you to build the kind of team you need, even if your team doesn't do software development or even any kind of development. It then describes how to form teams and the TSP launch process. Part III discusses teamworking. It concerns following the plan, maintaining focus, and following the process to produce a quality product. Part IV discusses management reporting, project reviews, and your obligation to support and protect your team. Part V concludes the book with a description of how to develop the team and its members and how to best capitalize on your capabilities and your team's capabilities. The book's appendices then provide more detail on the TSP team roles and how to use them. They also discuss the communication and command networks in your organization and how to use them to accomplish your team's objectives.
