Skip to main content

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.

Comments

Popular posts from this blog

from zero to production in eighty days

When I mean zero, I literally mean zero. A brand new project, a PO that's new to IT, no existing processes in place and a small team of four including myself and the PO.

The departmental organisation we were working for doesn't have any developers, scrum masters, product owners working for them. Everything they did was either done by another department or outsourced completely.

This is a story how we went from zero to production in eighty days.

My first time speaking at a conference

Since time immemorial we humans have valued the art of public speaking. Today, I want to share with you my experiences in speaking at conferences for the first time. Recently, I spoke at both DDD Melbourne and DDD Perth. Both of which were positive experiences that I learnt a lot in.


Have You Ever Produced Negative Value in a System!?

As developers we encourage our product owners to order the priority of their backlog in order of value. However, every time a new feature is implemented by a development team, there is a certain degree of risk associated with the introduction of that new code. Namely, risk of breaking another part of the product and maintenance cost. When a development team pulls in a new feature to implement there is a certain acceptance of this risk. In many cases, the risks that arise due to additional code complexity doesn't justify the value added by the new feature itself, so the development team can start implementing it.

Are there scenarios where the value added to a software product can be negative though?