Review By: Danny Dresner
04/14/2003

This is a leadership manual. In the tsunami of software technology, there is a limit to how long good developers can continue before they need to take on some team leadership responsibility by delegating some of the vision. The book is practical in its presentation and content. Its contents are clearly aimed at the technologist who has moved from cozy code cutting into “doing and managing,” but the book is not about project management. It is about the day-to-day people issues that must be tackled and applied to create a good environment for pragmatic, quality controlled, software development.

So, when should an aspiring team leader read this book? It is very well divided into real-word lifecycle stages. Although it is built on sound, standard phases of the software lifecycle, it doesn't pay homage to any method, but rather it gives a clear path to where methodologies fit. So the more famous doctrines such as DSDM or V-lifecycles are referenced without details, so that the book presents an independent approach with enough hooks to connect with in-house or proprietary processes.

Perhaps key to its likely uptake in the short-attention-span, hypertext-hopping world of electronic publishing is the way that the book competes very well with modern media. It maintains an almost conversational tone without losing the formality of instruction. Cross-referencing between sections is encouraged. It draws on the lessons well learned in technical writing circles and gets behind the mind of the reader by presenting use case issues, categorized in the Frequently Asked Questions section.

NCC courses use traditional feedback techniques to help marketing and quality improvement. One of the final questions is “Would this course benefit anyone else in your organization?” and one of the answers that course delegates regularly give is, “Yes! My manager!” And so it is with this book. Senior managers need to understand the day-to-day people issues that are managed by the team leader. Technology roles are not interchangeable without due regard to the fact that software developers are human too. They may give the impression of impartial, productive software creators, but expecting them to chop and change roles and tasks on a whim or pressure of the moment is courting disaster. This book is a recipe for supporting staff retention. Software development is not a “Von Neumann” process of technology that begets technology. It takes human intervention to create innovative software designs from requirements. This requires leadership.

A very helpful checklist appears at the end of each section. The bibliography may be complete as a record of the author’s research but could benefit from additional references. The bibliography could also be improved by better connection between the listed books and the references to them in the text.