Click the table of contents to start reading.
A real inspiration. Reading this book made me rethink the way I lead projects.
Elastic leadership is a framework and philosophy that can help you as you manage day-to-day and long-term challenges and strive to create the elusive self-organizing team. It is about understanding that your leadership needs to change based on which phase you discover that your team is in. This book provides you with a set of values, techniques, and practices to use in your leadership role.
Part 1: 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.2.1. You can make time for the things you care about.
1.2.2. An opportunity to learn new, exciting things every day
1.2.3. Experiment with human beings
1.2.4. Be more than one thing
1.2.5. Challenge yourself and your team
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.2.2. You're the bottleneck
2.3. Crunch time and leadership styles
2.4. Which Leadership Style Should You Choose?
2.4.1. Command and control
2.5. Leadership Styles and Team Phases
2.6. The three team phases
2.6.1. Survival phase (no time to learn)
2.6.2. Learning phase (learning to solve your own problems)
2.6.3. Self-organizing phase (facilitate, experiment)
2.7. When does a team move between phases?
2.8. Next up
3. Bus factors
3.1. Bus factors
3.1.1. A single point of failure
3.1.2. A bottleneck that slows things to a crawl
3.1.3. Reducing morale and inducing job insecurity
3.1.4. Discouraging team growth
3.2. Removing bus factors
3.2.1. Pairing and coaching
3.2.2. Bus factor as teacher
3.3. Avoid creating bus factors
3.3.2. 1-1 code reviews
3.3.3. Rotation (support, scrum master, build)
3.3.4. Pushing people out of their comfort zone instead of asking the veterans to do it
3.4. Next up
4. Survival mode
4.1. Are you in survival mode?
4.1.1. The survival comfort zone
4.1.2. The survival mode addiction
4.2. Getting out of survival mode
4.2.1. How much slack time do you need?
4.3. Making slack timerequired actions
4.3.1. Find out your current commitments
4.3.2. Find out your current risks
4.3.3. Plan a red line
4.3.4. How do you remove commitments?
4.4. Why slack?
4.4.1. Remember why you’re doing this
4.4.2. The risk of losing face with upper management
4.4.3. The risk of failing
4.4.4. This is what you’re being paid to do
4.4.5. Realize that you’re going to break your own patterns
4.4.6. Do not fear confrontation
4.4.7. Don’t despair in the face of nitpickers
4.5. Command-and-control leadership
4.5.1. Correct bad decisions
4.5.2. Play to the team’s strengths
4.5.3. Get rid of disturbances
4.6. During transformation you’ll likely need to…
4.6.1. Need to start spending more time with the team
4.6.2. Need to take ownership of your team
4.6.3. Learn how to say no by saying yes
4.6.4. Need to start doing daily stand-up meetings
4.6.5. Need to understand the notion of broken windows
4.6.6. Need to start doing serious code reviews
4.6.7. What if your team is large?
4.6.8. What if you’re part of a "wide team"a team that's distributed?
4.7. Next up
Part 2: Survival Mode
5. Learning mode: learning to learn
5.1. The baby ravine
5.2. Embrace ravines
5.2.1. How can you tell it’s a ravine?
5.2.2. The intern
5.3. Challenge your team into ravines
5.4. Next up
Part 3: The Learning Phase
6. Commitment language
6.1. What does noncommittal sound like?
6.1.1. A way out
6.1.2. Wishful speaking
6.2. What does commitment sound like?
6.3. Is it under your control?
6.4. Commit to things under your control
6.5. Turn an impossible commitment into a possible one
6.6. How do you get them on board?
6.6.1. Launch a commitment language initiative at a team meeting
6.6.2. Measure by feeling
6.6.3. Fix just-in-time errors
6.7. What if they fail to meet their commitments?
6.8. Finishing the commitment conversation
6.8.1. Can commitments drag on forever?
6.9. Look for 'by,' not 'at'
6.9.1. Where to use this language
6.9.2. Next up
7. Growing people
7.1. Problem challenging
7.2. How did I react the first time I got challenged?
7.3. When to use problem challenging
7.3.1. Day-to-day growth opportunities
7.3.2. Daily stand-up meetings
7.3.3. One-on-one meetings
7.4. Don’t punish for lack of trying or lack of success
7.5.1. Homework is a personal commitment, not a task
7.5.2. Homework has follow-up
7.5.3. Homework examples
7.6. Pace yourself and your team
7.7. Do you have enough learning time to make this mistake?
7.8. Are there situations where you shouldn’t grow people?
7.9. Next up
8. Using clearing meetings to advance self-organization
8.1. The meeting
8.2. What just happened?
8.3. What is integrity again?
8.3.1. The structure of the meeting
8.3.2. The meeting
8.3.3. Your closing words
8.3.4. The overall point of this meeting
8.4. Keeping the meeting on track
8.5. Next up
Part 4: Self-Organization Mode
9. Influence patterns
9.1. What about using my authority?
9.1.1. An imaginary example, using an influence force checklist
9.2. Next up
10. The Line Manager Manifesto
10.1. The Line Manager Manifesto
10.2. Survival mode
10.2.1. Projects in survival mode
10.2.2. Teams in survival mode
10.2.3. Individuals in survival mode
10.2.4. Sharing responsibilities is caring: team leads and managers
10.3. Learning mode
10.3.1. Projects in learning mode
10.3.2. Teams in learning mode
10.3.3. Individuals in learning mode
10.4. Self-organization mode
10.4.1. Self-organizing projects and teams
10.4.2. Self-organizing individuals
10.5. Other burning questions:
10.6. Next up
Part 5: Notes to a software team leader
11. Feeding back by Kevlin Henney
11.1. Roy's analysis
12. Channel conflict into learning by Dan North
12.1. Roy's analysis
13. It's probably not a technical problem by Bill Walters
13.1. Roy's analysis
14. Review the code by Robert C. Martin (Uncle Bob)
14.1. Roy's analysis
15. Document your air, food, and water by Travis Illig
15.1. Document your air, food, and water
15.1.1. Enable team members to help themselves
15.1.2. Give new team members confidence in the team
15.1.3. Provide visibility into your team
15.2. Find a location and tend the document
15.2.1. Document as questions arise
15.2.2. Pass it by exiting team members
15.2.3. Give it to new team members
15.2.4. Update as changes occur
15.2.5. Keep your document fairly lightweight and easy to maintain
15.3. Roy's analysis
16. Appraisals and agile don't play nicely by Gary Reynolds
16.1. Roy's analysis
17. Leading through learning: the responsibilities of a team leader by Cory Foy
17.1. Roy's analysis
18. Introduction to the Core Protocols by Yves Hanoulle
18.1. Roy's analysis
19. Change your mind: your product is your team by Jose Ramón Diaz
19.1. The product will be as good as your team is
19.2. Roy's analysis
20. Leadership and the mature team by Mike Burrows
20.1. Roy's analysis
21. Spread your workload by John Hill
21.1. Roy's analysis
22. Making your team manage their own work by Lior Friedman
22.1. Making your team manage their own work
22.2. Teach them how to do it
22.3. Roy's analysis
23. Go see, ask why, show respect by Horia Slushanschi
23.1. Roy's analysis
24. Keep developers happy, reap high-quality work by Derek Slawson
24.1. Roy's analysis
24.1.1. Coding standard
24.1.2. Dedicated learning time
24.1.3. Prioritize quality over quantity
25. Stop doing their work by Brian Dishaw
25.1. Roy's analysis
26. Write code, but not too much by Patrick Kua
26.1. Roy's analysis
27. Evolving from manager to leader by Tricia Broderick
27.1. The letter
27.1.1. Perfection versus learning
27.2. Roy's analysis
28. Affecting the pace of change by Tom Howlett
28.1. Ten years
28.2. Why so long?
28.3. Team-based ideas
28.9. Roy's analysis
29. Proximity management by Jurgen Appelo
29.1. The first approach: move your ass
29.2. The second approach: move your desk
29.3. Roy's analysis
30. Babel FishGil Zilberfeld
30.1. A team leader needs to communicate through multiple channels
30.2. Roy's analysis
31. You're the lead, not the know-it-allby Johanna Rothman
31.1. Roy's analysis
31.1.1. Being the bus factor
31.1.2. Coaching versus command-and-control leadership
32. Actions speak louder than words by Dan North
32.1. Roy's analysis
About the Technology
Your team looks to you for guidance. You have to mediate heated debates. The team is constantly putting out fires instead of doing the right things, the right way. Everyone seems to want to do things correctly, but nobody seems to be doing so. This is where leaders get stuck. It?s time to get unstuck! Elastic leadership is a novel approach that helps you adapt your leadership style to the phase your team is in, so you can stay in step as things change.
About the book
Elastic Leadership is a practical, experience-driven guide to team leadership. In it, you?ll discover a set of values, techniques, and practices to lead your team to success. First, you?ll learn what elastic leadership is and explore the phases of this results-oriented framework. Then, you?ll see it in practice through stories, anecdotes, and advice provided by successful leaders in a variety of disciplines, all annotated by author and experienced team leader, Roy Osherove.
- Understanding why people do what they do
- Effective coaching
- Influencing team members and managers
- Advice from industry leaders
About the reader
This book is for anyone with a year or more of experience working on a team as a lead or team member.
About the author
Roy Osherove is the DevOps process lead for the West Coast at EMC, based in California. He is also the author of The Art of Unit Testing (Manning, 2013) and Enterprise DevOps. He consults and trains teams worldwide on the gentle art of leadership, unit testing, test-driven development, and continuous-delivery automation. He frequently speaks at international conferences on these topics and others.
placing your order...Don't refresh or navigate away from the page.