Highly recommended.

So you think you can lead a team? is a very authentic and practical book. The author has written about his own journey, starting from humble beginnings to becoming a team leader developing internal software for a company in the tourist industry.

The best part of this book is how it shares personal experience, including mistakes while running your own business and developing applications for mobile devices.

I remember Paul back from ACCU conferences in Oxford (a long time ago), and his articles in the Overload magazine about programming in Java, which were very instructive at that time.

His personal story, gently unwound between lines, gives a special flavour of authenticity to the whole text. The book is divided into several sections, which give a good instructional overview on how to lead a team efficiently.

Paul has defined the difference between accountability and responsibility while showing his team-leading armoury. What drew my attention specifically was how he describes that the ownership of results, accountability, is the role of the Team Lead.

The author also provides some good reasoning, why as a team leader we need to step down from writing the code and delegate these tasks to the team members. In addition, he explains how to find a new model for personal and professional satisfaction and growth in the context of modern software development.

There are clear examples in the book of how to support team cohesion through talking to them openly. The author has correctly identified mutual trust as one of the most important conditions for successful teamwork. Nowadays, most communication is performed through online messaging channels, which brings an additional level of complexity to the communication process. I think it can be harder to understand the intentions behind messages sent via such platforms, as opposed to speaking face to face.

The triangle of trust – Code, Talk, and Show – is a great way to describe that constant trust-building process between members of any group or organisation.

Every software development team has its own disagreements over how to achieve its desired outcome. The author perfectly suggests that certain things need to be let flow, and some other disagreements are worth solving. Having a personal sounding board (for example, the product owner) and understanding the commercial goals of the company or client gives better positioning and evaluation of the importance of different disagreements.

The author correctly identifies that every team leader should perhaps have a deputy in the person of a senior engineer from the team. I’m personally a big believer of continuous dialogue, and it is well known that a triad of engineers – for example, software developer, business analyst, and tester – can deliver much more value quicker.

That brings me to one comment. I’m simply not certain whether I would decide to start the personal relationship between team leader and team members with a more informal communication style. The idea of having an informal chat every day simply seems to me unnecessary. Of course, that doesn’t mean not talking to and relying on your subordinates, but starting with that professional relationship could craft that dedication to the team mission better, in my opinion. However, different Team Leads and teams prefer developing team dynamics differently.

The book ends with a few well-known references, such as Dale Carnegie’s How to Win Friends & Influence People. It shows Paul’s enthusiasm for the subject matter, which is nothing surprising in his case.

Concluding, this is a very useful and acute exploration of team leadership, and I believe that we will hear more about Paul’s findings about team leadership through ACCU journals and conferences.

Thanks to Ian Bruntlett for organising the review process.

Website: http://paulgrenyer.com/