Buy A Bundle And Save
About the Book
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.
Roy is doing a workshop on Elastic Leadership in NYC this November.
-------------------------------------------------------
NEW:This book is also available as an audio book.
-------------------------------------------------------
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
------------------------------------------------------------
-
Feedback
Share this book
Table of Contents
-
- Audio Book Available
- Acknowledgments
- About Roy Osherove
- Books Mentioned in This Book
- Foreword
- Preface
-
I Elastic Leadership
-
1 Striving toward a Team Leader Manifesto
- 1.1 Why should you care?
- 1.2 Don’t be afraid to become management
- 1.3 The Team Leader Manifesto
- 1.4 Next up
-
2 Elastic Leadership
- 2.1 The role of the team leader
- 2.2 Growth through challenge
- 2.3 Crunch time and leadership styles
- 2.4 Which Leadership Style Should You Choose?
- 2.5 Leadership Styles and Team Phases
- 2.6 The three team phases
- 2.7 When does a team move between phases?
- 2.8 Next up
-
1 Striving toward a Team Leader Manifesto
-
II The Survival Phase
-
3 Survival mode
- 3.1 Are you in survival mode?
- 3.2 Getting out of survival mode
- 3.3 Making slack time—required actions
- 3.4 Why slack?
- 3.5 Command and control leadership
- 3.6 During transformation you will likely need to…
- 3.7 Next Up
-
3 Survival mode
-
III The Learning Phase
-
4 Learning to learn
- 4.1 Embrace ravines
- 4.2 Challenge your team into ravines
-
5 Commitment Language
- 5.1 What does non-commitment sound like?
- 5.2 What does commitment sound like?
- 5.3 Is it under your control?
- 5.4 Commit to things under your control
- 5.5 Turn an impossible commitment into a possible one
- 5.6 So how do you get them on board?
- 5.7 What if they fail to meet their commitments?
- 5.8 Finishing the commitment conversation
- 5.9 Look for by, not at
- 5.10 Where to use this language
- 5.11 Next steps
-
6 Growing People
- 6.1 How did I react the first time I got challenged?
- 6.2 When to use problem challenging
- 6.3 Don’t punish for lack of trying or lack of success
- 6.4 Homework
- 6.5 Pace yourself and your team
- 6.6 Do you have enough learning time to make this mistake?
- 6.7 Are there situations where you should not grow people?
- 6.8 Next steps
-
4 Learning to learn
-
IV The Self-Organization Phase
-
7 Use clearing meetings to advance self-organization
- 7.1 The Meeting
- 7.2 What just happened?
- 7.3 What is integrity again?
- 7.4 Keeping the meeting on track
- 8 Influence Patterns
-
7 Use clearing meetings to advance self-organization
-
V Notes to a software team leader
- 9 Feeding Back by Kevlin Henney
- 10 Channel conflict into learning by Dan North
- 11 It’s Probably Not a Technical Problem - Bill Walters
- 12 Review the Code by Robert C. Martin (Uncle Bob)
- 13 Document Your Air, Food, and Water by Travis Illig
- 14 Appraisals and Agile Don’t Play Nicely by Gary Reynolds
- 15 Leading Through Learning: The Responsibilities of a Team Leader by Cory Foy
- 16 The Core Protocols Introduction by Yves Hanoulle
- 17 Change your mind: your product is your team - Jose Ramón Diaz
- 18 Leadership and the mature team by Mike Burrows
- 19 Spread your workload - John Hill
- 20 Making your team manage their own work - Lior Friedman
- 21 Go see, ask why, show respect by Horia Slushanschi
- 22 Keep Developers Happy, Reap High-Quality Work by Derek Slawson
- 23 Stop Doing Their Work by Brian Dishaw
- 24 Write code, but not too much by Patrick Kua
- 25 Evolving from Manager to Leader by Tricia Broderick
- 26 Affecting the pace of change by Tom Howlett
-
27 Proximity Management by Jurgen Appelo
- 27.1 The first approach: move your ass
- 27.2 The second approach: move your desk
-
28 Babel Fish by Gil Zilberfeld
- 28.1 A team leader needs to communicate in multiple channels
- 29 You are the Lead, Not the Know-It-All by Johanna Rothman
- 30 Actions speak louder than words by Dan North
- 31 Creating Team Trust - Johanna Rothman
About the Author
Roy Osherove is the author of The Art Of Unit Testing, and has been in leadership roles for most of his professional life, acting as team lead, CTO and architect in many places. He's had many failures to learn from but also some great successes, that he likes to share by doing training courses and mentoring. You can read his blog at 5whys.com
About the Publisher
This book is published on Leanpub by Team Agile Publishing .
Team Agile Publishing is Roy Osherove's publishing house.
About the Contributors
-
Johanna Rothman
