Includes the following:
License for this book for up to 10 readers.
Includes the following:
License for this book for up to 100 readers.
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.
It is hard to explain this book better than the foreword, written by Dan North, so I'll just use it here:
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.
Read More Read Less
Table of Contents
- Audio Book Available
- About Roy Osherove
- Books Mentioned in This Book
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
Read More Read Less