Elastic Leadership

Growing self-organizing teams

Roy Osherove

• Publisher: Manning
• Year: 2016
• Print ISBN: 9781617293085
• eBook ISBN: 9781638351085
• Topic: Computer Science
• Subtopic: Project Management
• Index: Computer Science

Summary 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.Purchase of the print book includes a free eBook in PDF, Kindle, and ePub formats from Manning Publications. 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. What's Inside

• 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. Table of Contents

PART 1 - UNDERSTANDING ELASTIC LEADERSHIP

• Striving toward a Team Leader Manifesto
• Matching leadership styles to team phases
• Dealing with bus factors

PART 2 - SURVIVAL MODE

• Dealing with survival mode

PART 3 - LEARNING MODE

• Learning to learn
• Commitment language
• Growing people

PART 4 - SELF-ORGANIZATION MODE

• Using clearing meetings to advance self-organization
• Influence patterns
• The Line Manager Manifesto

PART 5 - NOTES TO A SOFTWARE TEAM LEADER

• Feeding back
• Channel conflict into learning
• It's probably not a technical problem
• Review the code
• Document your air, food, and water
• Appraisals and agile don't play nicely
• Leading through learning: the responsibilities of a team leader
• Introduction to the Core Protocols
• Change your mind: your product is your team
• Leadership and the mature team
• Spread your workload
• Making your team manage their own work
• Go see, ask why, show respect
• Keep developers happy, reap high-quality work
• Stop doing their work
• Write code, but not too much
• Evolving from manager to leader
• Affecting the pace of change
• Proximity management
• Babel Fish
• You're the lead, not the know-it-all
• Actions speak louder than words

Part 1. Understanding elastic leadership

You can’t depend on your eyes when your imagination is out of focus.

Mark Twain

Chapter 1 introduces this book’s overall value system and manifesto; everything in the book ties in with this first chapter. Chapter 2 discusses the concepts of elastic leadership and how to use the book’s value system in real life in what I call the elastic leadership model. Chapter 3 talks about bus factors—the first low-hanging fruit that can be changed to improve your work environment.

Chapter 1. Striving toward a Team Leader Manifesto

The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.

George Bernard Shaw, Man and Superman

This chapter covers

• Principles of leadership
• How to become and remain a good leader
• Developing other leaders from your peers—growing people

This chapter outlines the principles for becoming, and remaining, a good leader, and also developing other leaders from among your peers.

Leadership in general—and team leadership in the software business in particular, where little training, if any, is provided—isn’t easy to accomplish, or indeed to measure. We can begin with the assumption that most people in software—like you—have no idea what they’re doing or what they should be looking at when leading their software teams. Yes, that was me too.

This book springs from my personal experience of what worked for me and what didn’t work for me when I was leading software teams.

One thing is certain: the way we work with our teams must improve. We must become better adjusted to the current reality and needs of our team, our business, and ourselves.

A few years ago, I was speaking at a programming conference. The person who introduced me also mentioned that I was looking for a job. At the end of the talk, a woman came up to me and said, “We want to hire you as a developer.” Boy, was I proud of myself that day. I began working there, and the woman became my team leader.

My first job was to write code that uses the local network and searches for specific data on remote hard drives (no, it was not a virus). I worked on it alone. As the day went on, I struggled and struggled. It was harder than I thought. Another day came and went, and I was still at it. My ego wouldn’t let me ask for help. They had hired me off a conference stage because I was supposed to be an expert. How bad would I look if I said I didn’t know how to solve this problem—the first problem I had been given at that job? No. I was determined to work on it until I figured it out.

To add to my grief, there were no daily stand-ups, and every few days my team leader would pass by me and ask lightly how things were going. I would deliberately say it was “in progress” and move on with a solemn face. A week went by and I began avoiding people’s eyes in the hallways. I pretended to be busy and pensive, but I was drowning inside. Every day that went by, it became harder to admit I was stuck. Every day that went by made it harder to ask for help; I would look more stupid with the little progress I had made during all that time.

At some point, I took sick leave for a few days. I couldn’t handle the silent pressure. When I came back from the leave, my team leader approached me and said, “Hey, by the way, that thing you were working on? One of the devs and I sat on it and made it work in a few hours.” They had found a simple way out of my mess, and I felt both betrayed and foolish. I was fired from that company shortly after with a budget-cut excuse, but I knew better.

There were many things that could have prevented this Greek tragedy:

• I could have been a bit more courageous and said, “I don’t know how to fix this,” early on.
• We could have had daily stand-ups where my predicament would have been discovered early.
• We could have had a rule whereby no one was allowed to work on something on their own for more than a day.
• My team leader could have approached me and done one-on-one meetings weekly or biweekly to discover what was up.

But nothing happened, until the worst happened.

The values I introduce here, and throughout this book, can help prevent such tragedies from transpiring, or at least make them very unlikely. I hope they can help spark a desire in you, the reader, to become better at what you do.

Why should you care

You might feel helpless in leading your team to do the things you believe to be “right.” This book can help.

You might feel like you want to keep your head above water. This book will help you accomplish much more. You might feel clueless as to what it is you’re supposed to be doing with your (future) team. We’ll tackle that too. You might be broken and scared because you have no idea how you’re going to get out of a bad situation at work. Welcome to the club. I hope I can help. I hope I can because I’ve been there—clueless and scared. I was lucky enough to have some good mentors along the way who challenged me to do the things that I was afraid to do, to get out of my comfort zone, and to learn things I didn’t even know I didn’t know.

I think team leaders around the world all suffer from some of the same basic bad experiences. Most of us weren’t taught how to do this type of work, and most of us are never going to get mentors to help us through it. Maybe what we’re all missing are some good, old-fashioned people skills. Maybe we’re missing some direction, some overall purpose for our leadership role. I feel that if we go uninformed into a leadership role in software, without a sense of purpose and strategy, we’ve already lost the battle to create real teams. Yes, our head might be above water, but are we there to slog through another day? Are we supposed to be this helpless? We want to be leaders who create not only real value but also happy teams, both fulfilled and loyal.

Don’t be afraid to become management

A lot of developers who are promoted to leaders, or who are offered the opportunity to become team leaders, seem to be resistant to becoming management. I can understand some of the reasoning, but I don’t accept it. You might be afraid that your time will be sucked up by meetings, that you won’t have time to do the things you love the most (like coding), and that you might lose friendships with people you currently work with. I agree that there’s a basis for those fears. We’ve all seen (or been) that person who doesn’t have time to do what they love, or fumbles a friendship because they’ve turned into a boss from hell, and so on.

Paraphrasing Jerry Weinberg in his book Managing Teams Congruently (Weinberg & Weinberg, 2011): Management, done wrong, can make these fears manifest into reality. But management done right negates them. Management, done right, is a very tough job. That’s why you get paid more.

I’ll return to this concept later in this book.

You can make time for the things you care about

A good leader will challenge the team and the people around them to solve their own problems, instead of solving everyone’s problems for them. As people gradually learn to solve their own problems, your time frees up more and more to do the things you care more about, and the things that matter more (sitting down with people, coding to keep in sync with what’s going on in the team and the code). Doing your job as a leader and challenging or asking people to accomplish tasks may indeed feel weird, but in my experience, doing it will garner more respect for you, not less. Yes, some things will change, but change is inevitable. You might as well own and control how things change.

It also takes time to challenge people, time that most teams don’t have in abundance. Making slack time to grow the team’s skills will be necessary.

Take the opportunity to learn new, exciting things every day

Nothing beats gaining new skills. You and your team should always be getting better and going out of your comfort zone to learn new things. This is essential to what a team leader does. Becoming a team leader requires personal growth, rising to the challenge of knowing your team and what you can expect from them.

Experiment with human beings

Yes. I said it. You have a team, and you can experiment with goals, constraints, and the different leadership styles described in this book. Experime...

Table of contents

• Copyright
• Brief Table of Contents
• Table of Contents
• Preface
• Acknowledgments
• About this Book
• Part 1. Understanding elastic leadership
• Part 2. Survival mode
• Part 3. Learning mode
• Part 4. Self-organization mode
• Part 5. Notes to a software team leader
• Index
• List of Figures