Book Review: Leading by Alex Ferguson

Alex Ferguson was Manchester United FC’s manager for 27 years. During this time he managed the club to multiple titles while leading some of the most hard working, talented, and high performant players on the planet. I thought I’d give this book a shot to see what I can get out of it in my everyday life. Whether you like Alex (Or Manchester United FC) or not. It is clear that Alex was successful in his tenure at United and Aberdeen.What aspects of Alex’s experience will I take into my software delivery life? And what aspects I won’t?

Source: Google Books

The first two chapters of the book are: listening and watching. Two of the most important behaviours a leader must develop. Ferguson makes it very clear throughout his book that when buying or scouting for players he wanted to understand everything about them, including their hardships, privileges, and family life. This is a trait that’s important for any leader looking into the future as Ferguson did with United’s academy. The book is filled with personal anecdotes of how to connect, and whilst not using the word explicitly, empathise with people who he is leading or potentially about to lead. This is a trait that I myself see as very important within software development. The ability to step back and understand as much as possible prior to expressing an opinion is something that should be developed in any software development practitioner regardless of their leadership status.

The sheer diversity of skill that Ferguson had was remarkable. He would negotiate pay, direct coaches on football drills, communicate with media, write articles, market his team, trade players, and scout. Without doing any injustice to Ferguson’s skillset, one would even argue that he is a T-Shaped person with his core skill-set (the vertical bar of T) being football coaching. His negotiation, financial, trade and other multitude of skills being his general skills (the horizontal bar of T). Likewise, a leader in software delivery must become a generalist. They have to be across a variety of technologies and technology stacks, subject matters, and build relationships with people across the professional spectrum. It is not an easy feat. It requires constant context switching, learning, and understanding of different business areas.

There are many other things in the book which are universal across multiple leadership disciplines. At the same time, there are things that aren’t and shouldn’t be taken into your software development lives. These include: controlling the diet of those you lead, asking player’s partners to cook certain foods, playing favourites, and the silent treatment. As such, if you read this book make sure it is read in a context where you are able to recognise aspects of leadership that are universal and aspects that are not applicable to you.