Why This Book Was Written As software engineering matures as a profession, the position of team leader -- the person responsible for the technical direction of the project and the work of the other engineers on the team -- is becoming increasingly recognized as crucial to the success of a software development project. This book provides the help needed by team leaders to enable them to rise to the responsibility of leading a project. It is a practical book, containing tried and tested advice and techniques to help leaders overcome common problems, lead other people, make good decisions, and get projects out on time. Who This Book Is For This book is for anyone whose work involves both of the following: making detailed decisions concerning the architecture, design or coding of software products, or performing hands-on software development; leading, managing or mentoring other people who are developing software. This book is especially relevant for someone who finds themselves leading a software development team for the first time, or who feels that their skills with people are not as good as their skills with technology, and wants some help and direction. This book is most relevant for someone leading a medium-sized team, say 4 to 8 people. It should also prove useful, to a lesser extent, to the leader of a single-person project, or to a leader of a larger team or of a team of teams. This is a practical book for practising engineers.

It is not intended to teach management theory, nor to contain the very latest thinking in every field. It promotes those practices that have been shown to work in the real world. About Being a Software Team Leader A really good software team leader needs to be totally competent with technology, and also very good at getting the best out of other people. It#146;s a unique position, combining detailed hands-on software knowledge and skill, and yet requiring the leader to be able to step back from the details and see the broader picture. The way that a team is led has a critical impact on the success of a software project. The team leader makes a vital contribution to the quality of the software, the appropriateness of the technical decisions made, and the quality of team-spirit and motivation that the team members enjoy. Becoming a team leader forces you to have a different perspective on software development. As a developer, you know that you will be judged mostly by the quality of the designs and the code that you produce.

But as a leader, you will be judged in two different ways: By your bosses, you will be judged on how quickly and cheaply your project is completed and by how satisfied the customers or end-users are. By your team, you will be judged on the soundness of your judgement and on the way you work with people. This book aims to help you be better at these things and so to earn more respect both from your bosses and from other team members. Leading a software development team can be stressful, and it can be risky. It might not be as stressful or as risky as, say, managing a football team; but it does share some of the same stresses and pressures of trying to satisfy many people who are hungry for success, with there being no prospect of getting a second chance if things go wrong. Not surprisingly, it#146;s a job that not many people can do well. The difficulty of the task makes it all the more rewarding when you know you are doing it well. Once you have led a successful project, you will want to keep doing it and you will want to keep getting better at it.

I hope that you find this book useful in helping you to achieve and to build on success. How This Book is Organized The book is organized around real-world problems faced by leaders in their everyday work, such as #145;how do I draw up a project plan?#146; and #145;how do I earn the respect of my team?#146;. Many real problems have both people aspects and technical aspects, and the book approaches these together, as different dimensions of a given situation, rather than as completely separate issues. However, as can be seen from the contents page, the sections have been collected into groupings according to the major aspect of each, so you can start reading about a particular aspect of the job if you feel the need to do so. The individual sections are quite self-contained, and include references to other relevant sections and to the bibliography where relevant, so they can be read in any order. About Job Titles Such As #145;Team Leader#146; and #145;Project Manager#146; in this Book The software industry does not have a universally recognized set of job titles; they tend to vary from one organization to another. In this book, I have used the following job titles: Developer : Someone who does the hands-on job of making software. Making detailed technical decisions, designing, coding, testing, documenting.

May be responsible for their own area of development but not for the project as a whole. Team leader : Someone who makes technical decisions concerning the architecture, design or code of a software project. Responsible for the technical success of the project as a whole, and for directing and reviewing the work of other team members. Critically responsible for the quality of the software produced. Has extensive and current development experience. May do hands-on development. On a small project, may act as Project Manager as well. Project manager : A person who is responsible for planning, budgeting, liaising with management and negotiating with customers.

May have technical training, but does not do development. In a larger project, or a multidisciplinary project, would direct the work of several Team Leaders. Critically responsible for the delivery of the project on time and within budget. Software manager : The line manager for the developers. Responsible for hiring and firing, training and developing staff, also for procedures and working practices. Sets the strategic technical direction for the organization. Part of the management team. If your work (or part of your work) includes the role of Team Leader as defined above, this book is for you.

It doesn#146;t matter whether you have been given responsibility #145;officially#146;, or you just find yourself leading other technical people because that seems the best way to organize things. It doesn#146;t matter what your job title is. The boundary between these jobs is not very distinct. Most team leaders do some development, and every team leader has to do some planning and other #145;project management#146; activities. In this book I haven#146;t distinguished between tasks on the basis of who should do them. I#146;ve just tried to give the best help with a task that I can, for those people who need it. Contacting the Author If you wish to comment on any aspect of this book, you can do so by visiting my website,http://www.richardwhitehead.

com. Acknowledgements I would like to thank Robert Sander, Oemer Karacan and Donald Matthews, the reviewers of this book, for all their hard work and words of wisdom. Thanks to Mark Birdseye for giving me a copy of #145;Why the Neanderthals Became Extinct#146;. I am very grateful for the helpfulness and encouragement shown to me by everyone at the publishers, Pearson Education, who have kept me going and helped me to get it right. Thanks also to my friend David Krause for his detailed reviewing, helpful criticism and late-night e-mails. I must also thank my sons, Thomas and James, for tolerating all the times that Daddy spent #145;scribbling#146; when he should have been playing. Last but not least, I thank my wife Susan, without whose love and support I would never have completed this book. 0201675269P06182001.