The following books have all been instrumental in forging my career as a successful DevOps Lord.
For me, the best measure of a book is whether it changes the way I think. The books in this list are (in no particular order) those which have had such an effect on me, both as a professional, and as a human bean.
Love them or hate? Please leave some thoughts in the comment section below.
Thinking in Systems
Everything is connected, across time and space. Donella beautifully illustrates a number of different systems “Animals” - common patterns that appear in air-conditioner thermostats, the art of steering a car on the road and distributed computing systems. This book taught me to prefer small, calculated moves over wholesale systems changes and to better interpret and respond to measurements over time.
When an IT organization gets large enough, the need for predictability and stability starts to stifle innovation until fast moving, unencumbered startups disrupt them.
Lean Enterprise provides a prescriptive process and plenty of follow up reading to enable large organizations to overcome “inertia” while minimizing cost and risk. The business is divided into three horizons where first, exploration and experimentation take place. Experiments that prove to deliver value are transitioned into the ‘Exploitation’ horizon where an MVP is quickly transformed into a sustainable product. Finally, the ‘Stabilization’ horizon focuses on efficiency and stability; keeping the lights on so new experimentation can get underway.
The Open Organization
It’s no secret I’m a big believer in the power of Free and Open Source Software and open source communities. This book offers an inside look at RedHat’s success as the largest open source vendor in the world, from the perspective of their C.E.O., Jim Whitehurst.
Jim explores how RedHat leverage the power of internal and external communities to build the world class software products that run the New York Stock Exchange and countless other high profile enterprises.
What I found most interesting was RedHat’s adoption of a meritocracy; where community members and their contributions are evaluated on their merits, not their title or pay grade. This has changed the way I take on ideas from my colleagues and has also encouraged me to participate in discussions outside my remit.
Made to Stick
Ever wondered why the latest company strategy is not getting any traction? Why your marketing pitch is falling on deaf ears? Why even clear, concise facts are not enough to persuade people to your way of thinking?
Made to Stick answers these questions in a common-sense manner that has profoundly changed the way I communicate. It offers a very simple checklist (the SUCCESs model) to apply to your own communications to ensure they will be understood, memorable and influence people’s thinking.
I’ve found this book particularly useful in presenting my ideas for new projects, and in writing for my blog.
The Five Dysfunctions of a Team
From the teams on the service desk to the executives and the board, nothing is more critical to the success of a business than effective teamwork. In The Five Dysfunctions of a Team, Patrick Lencioni illustrates the reforming of an executive team using a simple, five tier model which highlights the most common obstacles to being affective as a team.
For me it highlighted some common sense cause and effect in interpersonal and inter-team politics in my own workplace. Where I might have previously strived to encourage people to focus on business outcomes and results, I learned we first need to create a culture of accountability, which first needs unanimous commitment towards common goals, which first needs constructive conflict to take place, which first requires people to trust one another enough to feel vulnerable.
The Phoenix Project
This book is the de facto entry point for anyone interested in understanding DevOps. What I love most, is that it is a management parable, not another inapplicable implementation of Continuous Delivery or Infrastructure As Code.
The Phoenix Project is a very deliberate homage to The Goal and is written in a very similar style, adapted for modern IT audiences. It incorporates elements of The Goal’s Theory of Constraints, Lean manufacturing, Toyota Kata, Agile and Continuous Delivery into a DevOps management recipe and way of thinking.
It focuses primarily on helping the business achieve its goals using IT as a core competency, rather than focussing on the Dev/Ops relationship and automation tools. It helped me to focus and realign my day-to-day activities to those that can be directly linked to successful outcomes for the business as a whole.
For a parable written in the 1984 concerning manufacturing plants, the application of The Goal to modern IT development and operations is incredibly potent and is expanded on further in The Phoenix Project.
This book has really helped me to identify where to (and where not to) invest my time and energy, especially concerning IT automation and process improvement.
I’ve written a full review in The Goal: A challenge to IT Operations
Almost every “improvement” initiative I have ever participated in could be described as an “implementation” of a known methodology. We implement Scrum or Lean or war rooms or silo crushing meetings or Continuous Delivery, etc., etc., etc..
Sometimes the implementations are successful (I.e. a well run Scrum team) but don’t actually benefit the business in any tangible or profitable way and even moderately successful implementations tend to degrade very quickly.
Mike Rother takes a look inside Toyota’s successful Continuous Improvement culture to show why people who copy Toyota’s process implementations typically cannot emulate Toyota’s success.
Toyota’s Lean processes are actually an evolution, more explicitly, an adaption to change, specific to their needs and environment. This book explores how Toyota approaches changes and develops improvements. Their way of thinking and “Improvement Kata” can be applied almost universally; including in IT.
This book has helped me to bake Continuous Improvement into every action I take, rather than approaching it as sporadic and typically unsuccessful projects.
Who Moved My Cheese?
It only took roughly an hour to read this profound little parable from cover to cover. Who Moved My Cheese follows four little creatures, Sniff, Scurry, Hem and Haw, who navigate their way through a maze searching for Cheese, an analogy for the things that make us happy. Most importantly, it explores how each character reacts to changes in the maze and the location of their Cheese.
Change is inevitable in our lives, and especially in IT. This book offers some simple ideas, expressed as Handwriting on the wall of the maze, for how to identify, cope with and adapt to change effectively.
I identify most with the character Sniff. I tend to sniff out change and typically get excited by it. This book has helped me to better understand that others approach change differently and that being a “forward thinker” can actually be perceived as threatening.
I’m making a point of reading this regularly to make sure I don’t get trapped in the arrogance of success or miss the writing on the wall when my comfort zones start to change.
The C Programming Language
Not a programmer? Doesn’t matter. The concepts in this book and the tutorials will be a real challenge for a first time programmer and you may even give up. In fact, I did give up. But I came back a few years later and conquered it cover to cover.
As a Sysadmin, it’s important to understand the difference between the heap and the stack, what a pointer is, what shared memory is for, how memory gets allocated and corrupted, how memory leaks happen, how code patterns affect performance and capacity, how shared libraries are really used, what stack traces mean, etc..
If you can grok this book, all of these concepts become much clearer and you’ll even be able to build small tools of your own, participate better in open source communities and communicate with developers in a common tongue.
Good to Great
Good to Great is probably the most thoroughly researched and well presented work I have ever encountered. Jim Collins dissects the differenciators between companies which outperform the market consistently over fifteen years to those that don’t. The findings are often counter-intuitive but are very well established in the presented facts.
Jim condenses everything down into a tangible framework called The Flywheel which offers stepping stones to replicating the success of the Great companies.
One stage of the flywheel, The Hedgehog Concept complements the idea presented in Made to Stick that succinct, unidirectional strategies are most effective at enabling a company to move forward in unison.
A later stage, First Who, Then What emphasises that “getting the right people on the bus” is the first and most critical part of building a successful company. This idea is echoed as the First Key in First, Break All the Rules.
I’d strongly recommend anyone read this book as it offers a great sense of context around organisational success. More importantly however, the principals of a Level Five Leader should be taken on board by team members at any level of experience or title.
First, Break All the Rules
This book brings together the findings from interviews with more than 80,000 successful managers to find out what makes them so effective.
The following keys are found to be consistent across most of the managers who took part in the study:
- They hire for talent and understand the recurring thoughts, feelings and behaviors that are needed on their team
- They define clear and valuable outcomes and leave the implementation to their employees
- They focus on developing strengths instead of trying to fix weaknesses
- They work to fit people where they belong and can succeed
I’d recommend this book to anyone looking to move into a management or leadership role, anyone looking to expand their team, hoping to land on the right hire, or anyone hoping to understand why their current org-structure is letting them down.
Site Reliability Engineering
This book collects essays from key members of Google’s SRE teams that build, deploy, monitor and maintain Google’s large scale production systems. The essays cover the philosophies, processes, architectures, mantras and mistakes that enable Google to be so successful.
Many of the lessons are directly applicable to much smaller scale IT service providers, like their incident response procedures, on-call rostering and philosophies concerning risk management and eliminating low value “toil”.
Other lessons were less applicable, but equally interesting, such as the design challenges of distributed consensus systems, automated deployment and data processing pipelines.
I’d recommend this book to engineers and operations managers in any IT org. It’s a real privilege to be able to learn from the refined and battle hardened
practices of some of the world’s most talented operators.