| author | layout | title | date | comments | categories | |||
|---|---|---|---|---|---|---|---|---|
post |
Book Review: Notes to a Software Team Leader |
2014-10-20 21:34:24 +0200 |
false |
|
After leading several teams Roy Osherove shared his stories about being a tech leader. If you are interested about the common challenges which teams, leaders and team members face then this book is for you.
It's a book by Roy Osherove about technical leadership. The book divided into two parts. The first part contains the author's personal view about technical leadership, the second part is a collection of notes from other authors and professionals.
I really liked the personal tone of the book. He lists all the things that worked for him when he was a technical leader and also the things which did not work for him. The preface starts with the the "There are no Experts. There is only us." tag line. I recalled these sentences several times since I've read the book, they made me confident.
I was curious about other tech leads experiences that's why I started reading the book. At meetups I really like the presentations which about personal experiences and mostly about failures, I learn a lot about war stories. I was looking for similar stories when I opened the book.
When he started leadership he thought that the role of the team leader is the following
A team leader should provide to their team everything the team needs and then get out of their way.
the problem with this that it does not scale. You will be the bottleneck if you are solving other people problem. He realized later that he was wrong, he didn't payed attention to people. After several years of practicin software leadership his role today is growing people on his team. You have to create an environment for this, it's not happen from day one, the book gives you examples about this process.
The main concept of the book is about elastic leadership. There are three leadership styles and three phases of the team. Team phases are the following:
- Survival mode
- Learning mode
- Self-organization
Teams are shifting between these phases, the forms are similar to the norming, forming, performing phases. In my interpretation it's about control on the things. In the survival phase you are overloaded with issues and tasks, you don't really have time which you can use for learning. The leader's goal is to move out team from this phase and create room for slack time. If you can achieve control over the urgent things then you can pay attention to the important ones, learning one of the most important. The goal is to achieve self organization phase when the team can solve their own problem and they don't need a leader. Your goal should be to maintain this pase.
The book covers the command and control, challenging and facilitating leadership styles. You should match these styles to the team's phase. You should use different styles for these phases.
- Challenging people
- Command and control leadership
- Facilitiating leadership
One interesting thing for me was the survival mode addiction. You fix the urgent thing, next time when an urgent thing occurs you decide more quickly and do the same, without thiking about it. You really should thinking about long term solution and not to just hot-fix things.
Another interesting part of the book for me was when he talks about commitment language. It seems a very simple thing, it really is but it's really hard to practice. Despite this I failed several times with using it.
How can you detect non-commitments? Here are some samples:
I’ll fix these five bugs as soon as possible.
We should take care of that.
I think I can do this today.
...
We did not say that that it would be absolutely done. We just said it might be done. This is where we fail. So how does it sound to be committed to something. It's simple, just use the following formula.
I will [perform a certain action] by [a certain date].
Other fields where I can see failures is when we commit ourselves to uncertain things. For example fixing 3 bugs for tomorrow. We don't know what causes the bug, what the consequences of those bugs are. In this case it helps if we commit ourselves to the thing which we can control. "I will work at least 4 hours each day for the next week to solve these bugs."
The book is written in a really informal style. Like having a chat after a meetup with a guy who shares your problem. For me it was much more digestible in this form.
It gives you tools and methods which you can start to use right away. I really recommend this book to every developer who would like to spot common anomalies in their team's processes or just want to make them better.