This Sunday, I read in one sit my review copy of Notes to a Software Team Leader by Roy Osherove. Despite not being a team leader myself, this book will be useful to any programmer who has now management responsibilities (that is, being responsible for the productivity of someone outside of yourself.)

The Structure

Notes is composed of two parts: a first half explaining the responsibility of the team leader to develop people inside the team, and the various phases in which a team can transition along with their goals and next steps (think of phases such as solid, liquid, gas: an occasionally reversible transformation).

The second half of the book is composed by the notes themselves, short concepts or patterns each written by a different team leader or coach. Reading the book in one sit of several hours was possible thanks to this organization, where the first part is more book-like in its comprehensiveness and the second is a series of lighter lessons.

It's nice also to see the influence of books such as Management 3.0. This book is up-to-date with Agile management literature. Moreover, it has been grown on Leanpub as an incremental and iterative project, reflecting Agile even in the process of writing the book itself.

Pragmatic

These days you find endless papers and books by Agile consultants urging you to adopt methodology X or practice Y, telling you that everything would be fine thanks to the magic wands of hardcore TDD and Scrum.

Notes to a Software Team Leader isn't a book written to sell consultancy hours: it is grounded in reality. So it recognizes that:

• programmers cannot learn a new practice immediately, and while they train they will took several times the original allotted slot to complete a task.
• Before being able to learn at all, a team must transition out the survival phase by putting fires out and allocating time to learn, even sacrificing schedule explicitly.
• Not all teams in the world are out of the survival phase where fires are put out everyday; quite the contrary.
• Not every organization can accept this concepts and change.
• Not at all times coaching and doing the right thing is appropriate.

Finding out when these last few things can be done and how is the content of the book. I appreciated very much the pragmatic tone of the book and the practical things you can find in it, down to the phrases you can use as mantra to guide your coaching.

Selected Quotes

The goal and the way we measure our work is the overall growth in skills of self-organization and self-maintenance in each member of our team and the team as a whole.

[...] today I believe the role of a team leader is vastly different from simply solving problems and getting out of the way.

The book Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency by Tom DeMarco talks about “learning time” being up to 10 times slower than normal productive time.

Eventually, you realize that in life you always have to get uncomfortable before you learn new skills [...]

When the ship is sinking, the captain doesn’t call a meeting. The captain gives orders.

This problem of hiding important information is very prevalent in our industry because we, the technical folk, like to believe in miracles. We also don't like confrontation. Telling someone what they don't want to hear is a form of confrontation.

[...] if the team member is not even a little frustrated or annoyed about how it's not their job to do X, you might not be truly teaching them something new.

[...] balancing time spent writing code versus other leadership activities. In an extreme case, writing no code leads to a lack of specific context for any strong directions you might push the team. [...] too much code probably means other important leadership activities are being neglected and any broader technical issues remain unresolved.

Conclusions

Notes to a Software Team Leader is a must read for a programmer turned (partially or fully) to manager of at least one other person. It does not assume an ideal world and guides you through the phases of finding time to learn and challenge the other people in your team so that they can become independent.

Now it's time for me to come back to work and experiment with the lessons taught me by this book. If you find it more difficult to work with people instead of machines, it's normal; what are you going to do about it?