Some weeks ago, we stumbled upon Lukasz self-published ebook “Memoirs of a Team Leader”. Lukasz picked my interest by professing: “This is the book I wanted to read after I had become a software team leader.“ Having been a team leader for a good part of the last 5 years, I found Lukasz’ book to be quite enjoyable for not only team leaders, but people willing to be become one day, and more generally developers working in teams.
Here is my quick (and 100% biased) review, mostly in the form of some highlights. I won’t list the content here, you can check it yourself on Lukasz’s site.
The first (and maybe most valuable) thing I found in those “Memoirs” is actually the table of contents. As Stéphan says, what you get with experience is a series of checklist: facing various problems or situations, we don’t have the solutions but we know where to look. The book get a real value here just to check that you do not forget anything crucial unconsciously. From leadership to best practices, from recruitment to deployment, Lukasz covers most of what make the life of a software development team leader (and more generally of a software development team).
In my recent work coaching TagTagCity’s technical team, I’ve also found this to be often my “best value”: facing any problem, having been there before brings a series of automatisms that you just can’t invent by yourself.
Most of the points in Lukasz book fall under the "common knowledge" category. Meaning “common knowledge” among the people that do know, so quite useful to someone starting. I saw too many teams fail just because no one ever shown/tell them that there was a better way. Several times during my read, I thought “this is something I could have written". Fact is (as most people), I did not
Lukasz tone is often personal, showing the way he found to be working, without imposing it as the one and only truth (he actually advise to try most of the advices, but keep it only if it works). Among those, a very practical approach to leadership summed as “Know your stuff, know your staff, don’t be a jerk, don’t be weak”. Simply explained, not that simply done, but already a potent recipe: If you manage to do that, you’ll probably do fine (those interested can get my version here).
Another point that resounded with me is about conflict management “don’t initiate conflicts if you don’t expect them to be beneficial”. This is something I like a lot, as it is not about not having conflict at all - you need some, at least on the idea level. A team where everyone always agree with you is most probably missing its true potential (it is supposed to be more than just hands). As someone that built a career on the motto “Never be unnecessary conflictual”, this is a part I found myself often nodding.
Lukasz invests a good sized part on development good practices, including version control usage, unit tests and code review. Lukasz mention the option to automate a part of the review, insisting that software can be useful but should complement rather than replace human review - an opinion we do share. If those practice are a given to you, great. They are not to everyone, and even for convinced people & practitioners like me, a review on the subject is always welcome. It is also a good source to explain those practices to other people.
Again, most of them are not things you discover by yourself. As most developers, I was shown (more than taught) those by people I worked with. Barring a more senior developer, Lukasz’s book would give you a nice intro, mostly about the benefits.
One of the book last advices is for me a very important one: always question why you are doing things. This will help doing them better, notably in quite a lot of situation by not doing them at all. As told in the Agile Manifesto: we believe in simplicity - maximizing the work not to do.
Should I’ve read those “Memoirs” when starting as a team leader, it would certainly have helped me a lot. Even today, it sounded like exchanging ideas with another team leader, something I come to like and value very much.
Not everyone has the chance to have someone to observe/exchange experience with. Lukasz’s book is a rather good companion for that - including the multiple parts where I disagree.
Funny story: the week we discussed about his book at 8th color (and before we even bought it), Lukasz reached to us with an offer for our readers, as he found our blog to be an interesting place to talk about those issues.
Should you be interested to buy it yourself, you can use the “8thcolor30” code to get a 30% discount (valid until the end of the 7th January 2013.). Thanks Lukasz!