Every now and again some one who is good at their job is told, 'you should write a book about it!' I think this is what has happened here. Written as the author sees it from the inside; this is a book by a Software Team Leader not a management guru, psychologist or some other 'ologist. However, it is writtenin a calm style, obviously some time later.

The book is divided into sections, each looking at broad areas of project control from the technical to the personal. The chapter tiles are all questions such as 'My team is doing *** what do I do about it' or 'The management have said it MUST be finished next week' and 'Why am I so stressed!!!!' The advice is calm, sensible and has options but not so many that you get swamped. None of it is dogmatic. Therefore it guides gently to a point where you should be able to see the way ahead to achieve your goal, or at least stop you going down a known wrong route.

Some of the sections are not strictly team leading, such as prioritising and stress management, but do go with the territory. Other sections 'requirements and analysis (are they really necessary?)' and 'The customer keeps asking for changes and improvements; can I really say 'No'?' are well known problems to the old timers.

There is a section on subversion (Relationship with management), which makes this book as useful to managers as team leaders. This is apart from the obvious man management sections of dealing with Engineers (not once does it mention a cattle prod!)

The appendices cover OOP and UML in about 18 pages, so it is a brief introduction. This is all that is required to understand some of the analysis design parts of the book. You need to know what in order to manage the why. Having said that most of this book is as applicable to a COBOL maintenance project as a C++/OOP/UML project. Risk analysis is also lightly covered (people can make a career out of it) but it is enough to stop you from sinking.

The author's web site is up and running with a (short) errata and a discussion forum. I recommend this book to any new (or potential) team leader. Also, from my experience, anyone who has to manage Software Team Leaders could do with it as well.

There are many grains of wisdom in this book and it should become for Team Leaders what the Mythical Man Month has become to Engineers.

I think this book would benefit from being on a CD with hypertext links. There are forward and backward references that would benefit from being hyper-linked. Also the style reminded me of electronic documents. Team leaders could have it on line and refer to it as needed without have 'The Manual' on the desk! I recommend this book. It's only real fault is the author published it 20 years too late for me!