Opens in a new tab
11 min 15 sec
Available in:English

Accelerate: Building and Scaling High Performing Technology Organizations

Shows why the fear engineers feel before a release says a lot about an organization. It also explains how continuous delivery, flexible architecture, tool freedom and customer feedback make software delivery faster, more reliable and less stressful.

Table of Content

Many technology teams treat a nervous release night as just part of the job. In Accelerate, Nicole Forsgren, Jez Humble and Gene Kim argue that it is a warning sign. How anxious engineers feel before pushing code live is one of the clearest signals of how well an organization delivers software and how its people are doing.

Their central claim is that speed, reliability and calm come from the same place. The technical habits that let a team ship software quickly and safely are the same habits that protect the team. The authors follow that link from the code itself to architecture, tool choice and the way products are managed.

Along the way there is a Microsoft engineering group whose satisfaction with work-life balance nearly doubled, and a warning sign any leader can watch for: developers who say they have never given deployment a single thought.

The knot in an engineer’s stomach before a release looks like a personal problem. The authors treat it as hard data about the whole company, and one Microsoft number shows what happens when that knot loosens.

Most teams know they should test more and automate more, yet release day still means late nights. The authors describe a way of working where finished means something specific, and the payoff reaches well beyond the code.

Some teams have excellent habits and still crawl, stuck behind approvals and coordination meetings. The cause is often hidden in how the software is put together, and it changes how much teams need to talk.

An approved tool list sounds like good governance: cheaper contracts, fewer surprises, legal peace of mind. The authors found that it carries a cost most managers never see, and they explain when standards still earn their place.

Many teams call themselves agile while waiting months for budgets and approvals. The authors connect real feedback loops with profit and market share, and show how good delivery and good product management feed each other.

Accelerate rests on one bet: the way a company builds software and the way its engineers feel about their work are a single system. Code tested constantly and released in small pieces, an architecture that lets teams move on their own, tools they chose themselves, customers they can actually hear. Each of these makes delivery faster and more reliable, and each also reduces the stress that wears people down. The Microsoft engineers whose work-life satisfaction went from 38 to 75 percent got there through engineering changes: work that fit inside working hours and far fewer deployments done by hand.

That gives any leader a place to begin. Listen to how people talk about release day, and treat dread or blank looks as data. Automate the most repetitive step between finished work and a live release. Count the approvals a team needs before it can ship, and remove one. Then ask engineers which tool slows them down most, and take the answer seriously.

When release day stops being something people fear, the organization has usually fixed much more than its release process.

About this book

What is this book about?

Many technology teams accept slow, nervous release days as part of the job. Updates wait on approvals, other teams and manual steps, and engineers carry the stress home. Nicole Forsgren, Jez Humble and Gene Kim argue that this pain is a measurement. The anxiety around a release reveals how well an organization delivers software, how healthy its culture is and how it performs overall. Drawing on their research into software delivery, the authors show that speed, reliability and well-being come from the same practices. These include continuous delivery with constant testing and automation, an architecture that lets teams change and release their part without waiting on others, freedom for engineers to choose their tools, and lean product management built on early customer feedback. Readers get a clear model of what high-performing technology teams do differently, plus questions to find where their own delivery is stuck. One example is Microsoft, where engineers' satisfaction with their work-life balance rose from 38 to 75 percent after the shift.

Book Information

Rating:

Genre:

Management & Leadership

Topics:

Operations, Organizational Behavior

Publisher:

IT Revolution

Language:

English

Narrator:

Caleb

First published:

March 27, 2018

Pages:

257

Length:

11 min 15 sec

Get the book:

Amazon

Who it's for

  • Managers with approval bottlenecks

    Engineering managers whose teams dread release day and wait on endless approvals.

  • Hoping for faster delivery

    CTOs and founders who want software delivery that is faster and steadier without burning out their people.

  • Developers and ops staff

    Developers and operations staff trying to make the case for automation, testing and team autonomy.

Listen to Preview

About the Author

Nicole Forsgren

Nicole Forsgren led the research behind some of the largest DevOps studies and holds a PhD in Management Information Systems. She later became vice president of Research and Strategy at GitHub and then a Partner at Microsoft Research. Jez Humble co-wrote Continuous Delivery, taught at UC Berkeley and co-founded DORA, which Google acquired in 2018. Gene Kim spent 13 years as founder and CTO of Tripwire, wrote The Phoenix Project and has organized the DevOps Enterprise Summit since 2014. Accelerate won a Shingo Publication Award.

Ratings & Reviews

Ratings at a glance

3.9

Overall score based on 156 ratings.

What people think

Listeners find this book to be a must-read for engineering groups, commending its thorough investigation and beneficial statistics. Furthermore, the work offers functional guidance and tips, with one listener highlighting its real-world utility supported by data and examples. Additionally, listeners like how technical methods connect to company-wide performance, as one review mentions the focus on shifting culture and leadership styles. The text is accessible and well-crafted, and listeners appreciate the strategy for steadily advancing the quality of software delivery.

Top reviews

Pranee

Finally, someone brought real science to the art of software engineering. For years, we have relied on gut feelings and anecdotal success stories to justify our technical choices. This book changes the game by providing a rigorous, data-driven framework that links technical practices directly to organizational success. I particularly loved the focus on how continuous delivery and lean management are not just 'nice-to-haves' but are actually predictive of high performance. It’s incredibly validating to see that things like trunk-based development and automated testing have a measurable impact on a company's bottom line. The authors do a fantastic job of moving beyond the buzzwords of DevOps to explain the 'why' behind the 'how.' Every leader in the tech space needs to read this to understand that culture and performance are deeply intertwined. It is an essential addition to any modern engineering library.

Show more
Evelyn

This is the definitive guide for anyone looking to build a high-performing technology organization. What I appreciated most was how the authors didn't just focus on tools, but emphasized the cultural and leadership transformations necessary for success. The breakdown of how transformational leadership styles influence team outcomes was particularly profound. It is one thing to say 'we do DevOps,' but it is another thing entirely to prove it with the level of rigour presented in these pages. I found the sections on continuous integration and delivery to be clear and actionable, even if I was already familiar with the concepts. It bridges the gap between the 'what' and the 'so what' beautifully. If you want to stop guessing and start measuring what actually matters for your delivery pipeline, this is the book for you. It has already sparked several productive conversations within my own engineering leadership team.

Show more
Connor

Wow, this completely changed how I think about team performance and the metrics that actually matter. For too long, we've used vanity metrics like lines of code or velocity, but this book shows why those are fundamentally flawed. The research presented here is robust and gives me a lot of confidence in the recommendations provided. I especially liked the discussion on how to foster a climate of continuous learning and how that directly impacts software delivery. It is a dense read, but the clarity it brings to the DevOps conversation is worth every minute spent. The authors managed to take complex statistical concepts and make them accessible to a general audience. This is a must-read for anyone who wants to move beyond the 'cargo cult' of Agile and actually improve their delivery outcomes. It’s a rare book that manages to be both academic and deeply practical at the same time.

Show more
Teng

As someone who has struggled to explain the value of DevOps to non-technical stakeholders, this book is a godsend. It provides the hard evidence needed to show that technical excellence drives business value. The four key metrics—lead time, deployment frequency, mean time to recover, and change failure rate—are now my go-to benchmarks for our teams. I will admit that the prose can feel a bit dry at times, and some of the statistical explanations in the second part felt like a slog to get through. However, the insights into Westrum’s organizational culture were eye-opening and provided a clear roadmap for improving team dynamics. It’s not a book you read for entertainment, but rather one you study to improve your craft. While it repeats several points from the State of DevOps reports, having them consolidated into a single volume is very convenient for reference.

Show more
Clara

Ever wonder why some software teams seem to move at light speed while others are stuck in a cycle of endless bugs? Accelerate answers that question with actual data rather than just the usual industry hype. I picked this up hoping for some practical tips on CI/CD, and while it delivered those, I was more impressed by the sections on architecture and team autonomy. The authors demonstrate that a loosely coupled architecture is a huge predictor of performance, which is a great argument for microservices when done right. Personally, I think the middle section on research methodology was a bit too long for the average reader, but I understand why they included it to prove their validity. It’s a solid, evidence-based look at what makes tech companies thrive in a competitive market. Even if it feels a bit like reading a textbook, the information is too valuable to ignore.

Show more
Piyanart

The methodology section in the middle was a bit of a slog, but the overall message is vital. We often talk about 'culture' in tech as this vague, untouchable thing, but this book actually measures it. By looking at how information flows within an organization, the authors show exactly how a 'generative' culture leads to better software. I found the practical tips on how to implement these changes very grounded, even if they aren't revolutionary to seasoned practitioners. To be fair, if you are already an expert in Lean or Agile, you might find the technical advice a bit basic. However, the way it connects those practices to organizational performance is where the real value lies. It’s a short read, but it’s packed with insights that you’ll find yourself highlighting for future meetings. It definitely deserves a spot on the shelf of any aspiring CTO or engineering manager.

Show more
Montri

Gotta say, the insights into Westrum organizational culture were worth the price of the book alone. It's fascinating to see how the way we handle failure and information impacts our ability to ship high-quality code. The book does a great job of explaining how technical practices like trunk-based development actually support a healthier culture. My only real gripe is that it can feel a little repetitive, as if they were trying to stretch a long white paper into a full-length book. Some of the charts and graphs could have been better integrated into the text to avoid the 'read the picture' feeling that some reviewers mentioned. Regardless, the data is too compelling to dismiss. It’s an excellent resource for anyone who needs to build a business case for technical debt reduction or infrastructure investment. It provides a level of rigour that is sadly missing from most management literature today.

Show more
Aey

After reading so many anecdotal 'best practice' books, it was refreshing to see someone use real science. This book takes the State of DevOps reports and expands on them to show how technical capabilities lead to organizational performance. I found the section on transformational leadership particularly relevant for our current company transition. It’s not just about the tools we use, but how we lead and support the people using them. Look, the writing is a bit dry and it feels very academic in Part 2, but the takeaways are essential for any modern software team. It’s a great way to align different departments around a shared set of goals and measurements. Even though it recycles some material from other sources, the synthesis of ideas here is powerful and well-presented. I've already recommended it to several colleagues who are looking to improve their delivery speed without sacrificing quality or stability.

Show more
Darius

Truth is, I found parts of this incredibly repetitive and a bit too academic for my taste. If you have been keeping up with the annual State of DevOps reports over the last few years, you might find that there isn't much 'new' material here. The book often falls into the trap of telling you that a certain topic will be covered later in chapter X, only to give a surface-level explanation when you finally get there. I was hoping for more deep-dive use cases or specific implementation stories rather than just high-level statistical correlations. That being said, the research itself is undeniably important for our industry. It’s a useful tool for convincing skeptical management that we need to invest in automation and architectural improvements. I just wish the writing style was more engaging and less like a formal research paper. It works better as a reference guide than a cover-to-cover read.

Show more
Film

Frankly, if you've been in the industry for a decade, much of this will feel like common sense. We already know that manual testing is a bottleneck and that small batch sizes are better for flow. I was disappointed that the book spent so much time on the 'what' and 'why' without giving enough 'how' for complex, legacy environments. The case study at the end was a bit underwhelming and felt more like a tour of a specific office than a deep dive into solving hard problems. Not gonna lie, I found myself skimming through the parts that just repeated information from the authors' previous books like 'Lean Enterprise.' It’s an important book for the industry because it provides the data to back up our claims, but it isn't exactly a page-turner. If you want to win an argument with a project manager about why we need automated deployments, buy this. If you want a deep technical manual, look elsewhere.

Show more
Show all reviews

Questions about this book

Nicole Forsgren, Jez Humble and Gene Kim argue that the practices that make software delivery fast and reliable also make engineers less stressed. Continuous delivery, constant testing, automation, loosely coupled architecture, freedom to choose tools and early customer feedback all improve performance and morale together. The anxiety teams feel before a release, which the authors call deployment pain, is a strong signal of how well an organization is doing.

Deployment pain is the fear and stress engineers feel when releasing new code to users. The authors trace it to friction between software development and IT operations, which often use different environments, processes and vocabulary. The more severe the pain, the more likely an organization has weak delivery, a poor culture and lower overall performance. Developers who have never thought about deployment at all are another warning sign.

The authors describe building quality in from the start, breaking work into small batches, letting machines handle repetitive tasks, always looking for improvements, and making everyone share responsibility for the whole outcome. In practice this means automating the steps that build, test and release software, merging work into the shared code often, and testing constantly, so that work counts as done only after it passes every test.

According to the authors’ data, teams that choose their own tools deliver better results and help the organization move faster. Standards still help in areas like system architecture and security, where a common approach makes problems easier to fix. The condition is that shared tools must be easy to use. The authors suggest treating internal tools like products and asking engineers what they need.

Start by asking how people feel before a release and whether developers understand how deployments happen. List the manual steps between finished work and a live release, then automate the most repetitive one. Count how many teams must approve a change before it ships and try to remove one. Finally, trace a recent change to see how quickly a real customer saw it.

AUDIO SUMMARY AVAILABLE

Listen to Accelerate in 15 minutes

Get the key ideas from Accelerate by Nicole Forsgren, plus 5,000+ more nonfiction titles.

  • 5,000+ titles
  • Listen as much as you want
  • 7-day free trial
  • Cancel anytime

Accelerate

Preview · Full summary 11 min 15 sec
Home

Discover

Open app

Log in