High-Performing Engineering Organizations

Accelerate: Building and Scaling High Performing Technology Organizations

Although the software industry has been booming for years and competition in the marketplace is tougher than ever, an increasing number of organizations suffer from slow software delivery performance.

How do we end up moving the slowest the critical moment we need the exact opposite? What could be the root cause, and what can we do to find it, eliminate it, and finally accelerate?

The authors spent four years performing intensive research on measuring software delivery performance and discovering the elements driving it. This book stands out because it doesn’t just present the authors’ valuable findings. It also makes the science behind their research accessible, so that the readers can apply the same reliable scientific methods to their own organizations.

The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win

The prelude to the DevOps Handbook is a humorous novel that will entertain you and and leave you with lots to think about.

Our protagonist, Bill, is tasked with delivering a project critical to the future of the business. But The Phoenix Project is already over budget and past its deadline. Bill has just 90 days to deliver it, otherwise his whole department will be outsourced.

The story’s characters are sort of exaggerated representations of people you meet and interact with in real companies, facing the usual IT problems: mismanaged projects, managers with personal agendas, arbitrary and unachievable deadlines, and above all the failure to understand and respond to customer needs.

Bill’s quest will reveal a number of approaches and tools which essentially are the basis of DevOps. Although in real world scenarios the adoption of such ideas would take significantly longer compared to the book, the lessons are clear and important.

The DevOps Handbook, 2nd Edition: How to Create World-Class Agility, Reliability, & Security in Technology Organizations

DevOps is in the heart of every digital transformation story. Within a true DevOps culture, Development, Operations and Product work closely together toward a common goal: delivering high-quality, reliable software that enables an organization to conduct its business in an agile, reliable, secure and effective way.

The DevOps Handbook is addressed to both technical and non-technical leaders and stakeholders. It provides a rich context about what DevOps is, the problems it tries to solve, plus a number of recommended strategies for adopting it. The 2nd edition (2021) adds Nicole Forsgren as a co-author and brings in fifteen new case studies, deepening the empirical backbone.

Gene Kim and Patrick Debois also co-authored Accelerate, and Gene Kim co-authored The Phoenix Project. For my own take on adoption, see 10 indicators that your tech culture is broken (and what you can do about it).

Team Topologies: Organizing Business and Technology Teams for Fast Flow

Most engineering organizations are accidentally designed: teams form around projects, projects end, teams persist, dependencies pile up, and a few years later your org chart is the thing slowing you down. Team Topologies offers a deliberate alternative.

Skelton and Pais identify four fundamental team types (stream-aligned, enabling, complicated-subsystem, platform) and three interaction modes between them. The vocabulary is precise enough that you can use it in a strategy doc and have an executive team actually agree on what you are proposing. The book also handles cognitive load explicitly, which is something most org-design conversations dance around.

A useful companion to [[accelerate]]. Accelerate tells you what high performance looks like. Team Topologies gives you the org shape that produces it.

The Goal: A Process of Ongoing Improvement

The novel that quietly shaped how an entire generation of operations leaders think about throughput, bottlenecks, and what it means to “improve” a system. Eli Goldratt wrote it in 1984 about a manufacturing plant, but it reads like a software-delivery parable.

The protagonist Alex has three months to turn his failing factory around or it will be shut down. Through a series of conversations with a former physics professor, he learns the Theory of Constraints: any system has exactly one bottleneck at a time, and improving anything other than the bottleneck improves nothing. The book is the source material for [[thephoenix]] and is referenced constantly in modern lean and DevOps writing.

A pleasant read, structured as a story rather than a textbook. By the end you will be looking for the bottleneck in everything you do.

The Goal: A Business Graphic Novel

If [[thegoal]] is on your reading list but you have not made it to the bottom of the stack yet, the graphic novel adaptation is a good fast path.

The story is the same, the characters are the same, the Theory of Constraints arrives in the same shape, but the format compresses the read time from a few evenings into a couple of hours. The illustrations also help with one of the original book’s weaker moments: visualising the queue-build-up-at-the-bottleneck demonstrations.

I keep a copy to lend to colleagues who say they would read more management books “if only they had time”. Nobody refuses a graphic novel.

The Lean Startup

Most entrepreneurial failures don’t come from bad ideas. They come from confidently shipping the wrong version of a decent idea. Eric Ries’s contribution is a deliberate process for finding out what works before you’ve spent the budget building it.

The Lean Startup formalises the build-measure-learn loop, the validated-learning concept, and the discipline of pivoting versus persevering. The methods originated in startups but apply just as well to internal products inside large companies, where the cost of building the wrong thing is just as real.

If you want my deeper take on it, see my extensive review of The Lean Startup.

Clean Agile: Back to Basics (Robert C. Martin)

Many teams and companies have attempted to adopt agile development but failed. Although they follow all the business processes and rituals involved with agile, the result couldn’t be farther from what the agile manifesto describes.

For agile to succeed business processes are only half of the story. There are several engineering practices that need to be embraced and mastered, and these are almost always ignored or underestimated.

The belief that quality and discipline increase speed is a courageous belief because it will constantly be challenged by powerful but naive folks who are in a hurry. – Robert C. Martin

Uncle Bob’s latest released book is packed with useful advice of how to properly approach agile development, free of its misconceptions or marketing-friendly bells and whistles. By the end of the book you will know about all the elements you need to master in order to succeed.

Smart and Gets Things Done: Joel Spolsky's Concise Guide to Finding the Best Technical Talent

Joel Spolsky, father of Stack Overflow and author of the world-famous blog Joel on Software, lays out his secrets on how to find and hire the best programmers.

We all know how terrible the recruiting process of most companies is. Even professional recruitment agencies are more often than not unable to evaluate talent. They mostly base their process on matching keywords or look for X years of experience on technologies that don’t even exist for that long. Joel shows us how the recruiting process is meant to be, and what recruiters and hiring managers need to do to fix it.

Why would this be your concern as a programmer, you ask. Knowing what the recruitment process is meant to be can help you identify companies that do it right. Chances are that these will be great places to work at, not only because they will know their stuff, but also because your colleagues will have been hired through the same reliable process.

On top of that, you will learn how to ask the right questions during the interview, and identify red flags that will help you avoid wasting time at a workplace that is not aligned with what you are looking for.

User Stories Applied: For Agile Software Development

The concept of user stories stems as one of the main elements of Extreme Programming.

User stories represent an efficient means of gathering requirements from the customer. This book gets into the elements of good user stories, and describes how they can be used to properly plan, manage, and test software projects.

The book comes packed with examples of both fruitful and unsuccessful practices of the concept, as well as plenty of questions and exercises to solidify its points.

If you are in any way involved with writing on working with user stories, you need to read this book.

Release It! 2nd Edition

The title is a bit misleading. This book is not so much about the act of releasing software, but rather designing systems that you feel comfortable releasing.

It’s a common trap to design a system and focus only on the happy paths, but that’s only the first (and often easiest) step. Good software is reliable, resilient, and ready to overcome a series of difficulties that may arise.

The book is thought-provoking, engaging, and full of real-world experiences that can really change the way you think about delivering working software.

The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact

Edmond Lau interviewed dozens of senior engineers at companies like Google, Facebook, Quora, and Dropbox to answer a deceptively simple question: what do the engineers who get a disproportionate amount done actually do differently?

The answer, in a word, is leverage: the ratio of impact produced to time invested. The book is a series of practical chapters on how to find leverage in your own work, from optimizing your learning rate, to prioritizing ruthlessly, to investing in iteration speed, to designing reviews and tests that catch problems early.

A useful book for senior engineers in particular, because the gap between “competent” and “leveraged” is the gap that defines staff-and-above careers. Pair with [[staffengineer]].