The closest thing I have to a regular column on this blog site has been reviews of books related to digital transformation. Seeing the extent to which the terms ‘digital’ and ‘agile’ have suffered from over-exposure by bullshit merchants, I am now cringing somewhat at the title. But given that this is my third post in this series, I am going to stick with it, and trust you will forgive me. (see here for previous posts)
The 4 Stages of Psychological Safety
Timothy Clark
The first book on my list is a bit different to the recommendations that will follow. At face value, what is a book on psychological safety doing amongst books on cloud, agile and all things digital? The obvious reason is people are at the heart of digital success. Digital transformation and business innovation inherently harness the creativity, transformation, delivery and execution of its participants. These in turn are individuals, all buffeted and driven by their own personal needs, biases, insecurities and values. It is these needs, aspirations and values that need to be harnessed for any transformation to succeed.
In a previous post, I described how Google had launched a wide-ranging project, called Project Aristotle to determine what made a team successful or high-performing. They found that the best performing teams were not those with the best qualified individual team members, but those which exhibited the greatest confidence in taking on risks without fear of being embarrassed or ridiculed. In these teams, members felt safe proposing risky ideas and were prepared to be vulnerable in front of each other.
This is known as Psychological Safety, a term that has been around since the 90s, but has really taken off since the findings of the Google study became well known. In ‘The 4 Stages of Psychological Safety’, Tim Clark, a cultural anthropologist, explains how any organisation that relies on innovation for success needs to provide its teams with psychological safety. The book shows how treating employees and colleagues with respect, empathy and humility is not only the moral or right thing to do, but it is also the only way to succeed in the knowledge economy.
Clark describes his four stages, from inclusion safety on to learner safety, contributor safety and challenger safety, each building on the other, much the same as Maslow’s hierarchy of needs. The book draws on loads of high school examples, bringing home the universality of what it means to be empowered with trust, to be excluded from a group or simply to fear ridicule from your peers.
Any organisation hoping to drive transformation successfully should offer all four levels of safety. Change in the digital age brings about great uncertainty, and a need to continually learn new skills. Above all, leaders need to acknowledge that mistakes will be made, often with things going worse, possibly a lot worse before things get better. Having a culture of psychological safety is essential to navigating such changes without an unacceptable toll being inflicted on your team members’ well-being. At a personal level, this book is possibly the one that has had the greatest impact on me personally and which I’d recommend to anyone, irrespective of their interest in tech.
Rethinking AGILE
Klaus Leopold
We are advised not to judge a book by its cover, but I must admit that I bought this book on the strength of its title alone – ‘Rethinking Agile – why agile teams have nothing to do with business agility.’ This is a favourite theme of mine (if you’re interested in my thoughts, read here). Whilst I wouldn’t go as far as saying that agile teams and business agility have nothing to do with each other, they are often wrongly assumed to be the same thing, with many organisations feeling that they have achieved agility simply because they have implemented team-level agile.
In this richly-illustrated book, Klaus Leopold first starts off by describing an anonymous case study of an agile transformation at scale, where the company does all the right things, establishing cross-functional teams, making work visible, holding retrospectives and so on. In many ways, it feels like textbook agile. Nevertheless, the transformation quickly grinds to a halt to the consternation of the leadership team who established the programme.
Leopold explains how when hundreds of people are involved, a pure team-based agile rollout is simply not going to work. For any tech organisation of more than 30 people, while you may wish to reduce dependencies between individual teams, there is no way of avoiding them. Focusing on optimising team performance will simply result in sub-system optimisation at the cost of overall system performance.
So what’s the solution? Leopold proposes introducing three models of communications, which he calls Flight Levels, overlaid upon each other, aimed at optimising performance over different time horizons and spans of influence. The lowest Flight Level is effectively team-level agile. Flight Level 2 introduces inter-team coordination and dependency management, while Flight Level 3 is aimed at mapping the company’s strategic priorities onto a top-level portfolio.
Now, none of this is particularly original, and any experienced SAFe (Scaled Agile Framework) will recognise these approaches. Nevertheless, as an easy-to-digest warning of the pitfalls of agile over-simplification and some top-level guidance on how to get your agile transformation back on track, you cannot go too wrong with this book. Oh, and did I mention the illustrations?
Team Topologies
Matthew Skelton and Manuel Pais
If there was a book that I would single out as having resonated with me over the past couple of years, it must be Team Topologies by Matthew Skelton and Manuel Pais. At its essence, the authors demonstrate how organisational design and system architecture are, whether you like it or not, intrinsically linked. They can be considered to be mirror images of each other.
Of course, this is nothing new. In the 1960s, Roger Conway, a computer programmer stated that the structure of computer systems will tend to reflect the communications structure of the organisation that produced it. This book builds upon this adage. If this principle holds true, then how best should companies organise their technology teams to produce outcomes that best meet their business needs? The answer, in the authors’ view, is the ‘Reverse Conway manoeuvre, where companies should organise their teams according to their desired architecture. In particular, teams should be structured in a way to allow most communications to take place within a team, rather than in between teams. This can only be achieved if the team boundaries closely match the boundaries of the microservices, the software components that make up a modern software system.
Where this book excels is in giving real-world examples on how to structure your teams and your software, to best meet the demands of your business. The default orientation proposed is described as a ‘stream-aligned team’, often referred to as a product or feature orientation. These teams are focused on creating end-user experiences, and as such contain the expertise necessary to bring software to end-users. This is strongly at odds with the traditional functional or specialist orientation of many technology organisations, but the authors argue that this is the only way to achieve speed in product delivery. Other topologies are described, including platform teams orienting around platforms, where the aime is to maximise the reuse of software by other teams.
What sets this book apart from others in this vein is the way in which the approaches are grounded in the fundamentals of how we work as humans. The limits of cognitive loads when dealing with complexity, context-switching, and the criticality of forming strong working relationships and effective communications act as the guiding narrative throughout the book. This is a book I revisit frequently.
Reaching Cloud Velocity
Jonathan Allen & Thomas Blood
This book was recommended to me by Patrick Bartsch, a former colleague at Jaguar Land Rover, and a self-professed AWS ninja. Firmly positioned as a guide to CIOs and CTOs migrating to the cloud or wanting to make more out of their cloud investment, this book provides an excellent 360-degree view of how to succeed in building your business using public cloud technology
Although all the examples relate to AWS, Amazon’s cloud offering, most of the lessons will be equally relevant should your organisation be using Microsoft Azure or Google Cloud Platform. All the tech fundamentals of modern cloud platforms are covered here, including how best to manage cloud migrations, make the best use of the latest technology in terms of containers, machine learning and edge compute and how to design for scale, resilience, security and compliance. Whilst most companies have a focus on the software that drives business value and customer features, it is normally the behind-the-scenes efforts to simply keep the lights on that are more likely to keep CTOs awake at night, and this book does justice to these.
However, where I thought this book was particularly strong was in its treatment of the management, leadership and cultural drivers of success. Covering the leadership principles used at Amazon, the book takes Peter Drucker’s axiom that ‘culture eats strategy for breakfast’ to heart. The authors cogently argue that cloud computing will do nothing for your business if your operating model, leadership style across the entire business do not come together to drive business agility in its broadest form. The book starts off with an oft-repeated quotation that ‘friends don’t let friends build data centres.’ By the time you are done with this book, you will realise that it is not just data centres that cloud providers will take care of, but a large chunk of your software and operations activities. And that is not a bad thing.
Doing Agile Right
Darrell Rigby, Sarah Elk, Steve Berez
This list is brought to a close by a book whose tagline I love, ‘Transformation without the Chaos.’ It was indeed this tagline that brought me to overcome my bias against books written by consultants. In this case, all three authors being partners at Bain & Company.
Doing Agile Right is a book targeted at senior leaders, and starts off in a rather surprising way. It describes how agile really works, what is at the heart of team-level iterative product development. The reason is simple – many of the leaders who are accountable for digital programmes have never themselves participated in an agile team.
The authors then go to outline the challenges when scaling it across the enterprise. Like ‘Rethinking Agile,’ an appropriate emphasis is placed on managing interdependencies, but sensibly, rather than proposing their own tools and methodologies, the book outlines and critiques the current more popular ones being used. The strongest sections relate to agile leadership, a topic that is in my opinion under-explored. Agile leaders need to reconcile their natural tendency to give bold targets and direction, with the bottom-up planning and team empowerment that is the bedrock of the agile philosophy. The authors describe how for an agile journey to be successful, leaders need to reappraise how they add value, and how they give their teams the space to succeed and fail.
Without explicitly mentioning at any point, the book leans heavily on the principles of psychological safety described above. Leaders are asked to over-communicate, embrace and live the change they want to see adopted across the organisation and accept that there will be many failures along the way. As would be expected from a book written by consultants, due focus is given to the mechanics that need to be put in place to support agile delivery, from planning and governance through organisation design and processes. Anyone looking for a one-stop view of what an organisation-wide agile journey looks like can do a lot worse than reading this book.