This book is meant for software team leaders, architects and anyone with a leadership role in the software business.

• Read advice from real team leaders, consultants and everyday gurus of management.

These include, among others, Johanna Rothman, Uncle Bob Martin, Dan North, Kevlin Henney, Jurgen Appelo, Patrick Kua and many others. Each with their own little story and reason to say just one thing that matters the most to them about leading teams.

See what it'll feel like if you do things wrong, and what you can do about things that might go wrong, before they happen.

This book will try to be the book I wish I had when I first became a team leader.

-------------------------------------------------------

NOTE: This is an old edition of this book. The 2nd edition can be found at http://TeamLeaderBook.com

-------------------------------------------------------

It is hard to explain this book better than the foreword, written by Dan North, so I'll just use it here:

Foreword:

The career of a programmer is a complicated one. The early days or years are straightforward enough. You start as a junior, learning at the elbow of people more experienced than you. You make the mistakes everyone makes and come up with a few new ones of your own. Then you find your feet and gain confidence and experience, and you start to enjoy the feeling of just knowing how to solve this one, because it's just like the one you had on that other project. Over time you start helping the newbies, remembering what it was like to be one yourself. You achieve the heady heights of senior developer.

And then one day it happens. You end up in charge of a team. Maybe not as their manager but as their technical team leader. They look to you for technical guidance. Your job is as much about creating and sharing a consistent vision as it is about delivering great software. Personality clashes within the team are suddenly your problem. You have to mediate heated debates about curly bracket placement or whether tail recursion is better than iteration. Should we hack this into the legacy system or bite the bullet and do it properly in the new one? Becoming a software team leader is hard.

I'm really pleased Roy has written this book. It's all the advice I wish I’d had when I started leading software teams. As well drawing on as his own wealth of experience, Roy has invited contributions from people across the software delivery world, and the result is a companion and compendium you can dip into to find advice and direction, some of it contradictory, some of it counterintuitive, all of it valuable.

-- Dan North, independent consultant and troublemaker.

http://dannorth.net, @tastapod

------------------------------------------------------------