Richard Whitehead

As an effective software development manager, you know the importance of mentoring and developing your immediate staff and encouraging them to do the same.

In particular you know the importance of the mentoring and supporting the newly appointed software team leader or development manager. Its the person who yesterday was a development practitioner (and most likely a good one too) but who now is faced, for the first time, with leading a team and achieving results largely through other developers.

It's often a daunting challenge - for the newly appointed team leader and for the development manager!

Wouldn't it be nice if there was a handy resource that would provide our newly appointed team leader with some insight, some practical insight, and sound advice on what makes for success and how to overcome the inevitable problems he or she is likely to meet.

Well, the handy resource is available in the form of 'Leading a Software Development Team' by Richard Whitehead.

Whether the challenge is 'how do I earn the respect of my team', 'one of my team members is an expert in an important aspect of the project, I feel like a fool trying to lead on this issue', or 'I'm not getting the support I need from my management, what can I do about it?, the new team leader will find 'Leading a Software Development Team' provides wisdom and a wealth of practical steps to deal with the issue.

Written is an easy to read style and extensively cross-referenced, this book can be dipped into as a handbook to get advice when difficulties arise.

However, this reviewer suspects that many readers will be sufficiently hooked by the questions posed under such headings as 'The New Leader' (I'm taking over the leadership of a new project where do I start?), 'Project Management' (How can I do a good job when our procedures are so bad?) and Stress and Conflict (My team seems to spend too much time arguing, what can I do?) that more extensive reading will be the order of the day.

A valuable and insightful read and though clearly aimed at the new team leader many a seasoned software development manager will, I suspect, find the questions posed and the recommendations given a useful refresher and worth reading before passing on to the intended audience!

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 written in 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 titles 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 and 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 sinking.

The author's web site is up and running with a (short) errata and 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 having "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!

I just wanted to thank you and reinforce what a great job you've done - particularly in the area of social dynamics within software development.

I can see that we are both fans of Steve McConnell and Tom de Marco, etc. You have made a valuable contribution to the literature, and really, yours is the book that I will recommend first. Keep on writing!

Taking the first step on the ladder from code-writing grunt to head of IT usually involves becoming a project team leader. Instead of making decisions that affect only your own output, you now have responsibility for making decisions about the architecture of the application, developing the software and leading teams of other engineers. Decisions made now will impact on the whole project.

Team leaders are almost invariably drawn from the ranks of software engineers and are usually chosen for their technical expertise. Unfortunately, there is little in cutting code that prepares one for the challenges of project management. This book aims to prepare readers to meet those challenges and be able to prove themselves not just on their ability to design and write code, but on their ability to satisfy the demands of customers and users the project is designed for, and to successfully lead a team.

Aimed at teams of four to eight people, Leading a Software Development Team is based around sets of questions that someone new to the role of team leader is likely to ask. These include: "Where do I start?", "How do I draw up a project plan?" amd "How do I earn the respect of my team?". There are also practical guides on capturing the project's requirements, stress and conflict management, decision-making, design and analysis, and project release.

One of the most interesting chapters is on relationships with management - an area that many management books overlook. Answers to questions such as, "My boss is useless, how can I put up with this?" will be useful to managers at any level. While well written and practical, this book has only limited appeal for those not involved in project team leadership.

I believe its a very useful book and its worth to be known by lots on Software Engineers with good techincal skills but little knowlege about leading a Software Project, customer/management relationship and people leading. I've been leading software projects (5) for the past 12 months. If I could have read your book before, I would probably have avoided some of the problems that arised in that projects life. Upon reading your book and realizing that the strategies I was using on my work were the correct ones I was left with a stronger feeling of selfconfidence. In other words, I got a clearer picture of the figure of the project leader, my position!!!

This book is important. It 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 to make the most of their development skills by delegating some of the vision. This book is a mentor, guiding the technical staff who acquire leadership responsibility – through aspiration, sudden ‘promotion’ or just being in the wrong place at the right time – to understand the difference between a group of programmers and a team of software engineers. And it is practical in its presentation and content. Its contents are clearly aimed at the technologist who has moved from cosy 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? Well, the book does not have to be read cover to cover . It is very well divided into real-word lifecycle stages. In fact, you could view it as a paper 'agony aunt' given its spread of topics and the questions fitting each one. 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 but without losing the formality of instruction. It does this with an almost ‘paper hypertext’ design. Cross referencing between sections is encouraged (keep book marks handy but you shouldn’t run out of fingers). It draws on the lessons well learnt in technical writing circles and gets behind the mind of the reader by presenting ‘use case’ issues, categorised in 'Frequently Asked Questions'.

Who else should read it? 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 organisation?’ and one of the answers that course delegates regularly give is, ‘Yes! My manager!’. And so it is with this book. Senior managers needs 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 and the people need leadership. Is it the book perfect? You're asking a quality manager who always looks at opportunities for improvement so . . .

A checklist to 'take away' at the end of each section is desirable and 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. And if you really want to get picky, it seemed that every index reference that I followed up was one page out. [I can't find this problem in my copy! - RW] Too petty? Well quality managers are people too you know!

Deep insight into psychological ins and outs of teamwork leadership combined with exceptional viability of technological advice. Most of all (from where I stand) this work is valuable not only for those already in a shoe of newly born team leader, but also for those actually ON a team - seeing things from a different perspective, especially that of your mentor/boss, helps to better recognize their motivation and actions, thus providing chance for more constructive collaboration in achieving common goal - the successful project. Extending this same concept to areas beyond SW development would pose even more vital guidelines to socially constructive stand - practical, fair and responsible attitude towards others while making your living.

Thank you.