It is both relatively detailed and broad. It can be skimmed in 3-4 hours but also serves as a reference book that can be revisited topically. There is a good amount of DevOps through an Etsy lens. According to the author effective DevOps is "an organization that embraces cultural change to affect how individuals think about work, value all the different roles that individuals have, accelerate business value, and measure the effects of the change". This does sum up the book well as its main sections are:

• What is DevOps?
• Collaboration
• Affinity
• Tools
• Scaling
• Bridging Devops Cultures

What I got from it: 

• Reminder that the autonomy and space a team and individuals has to improve things is key. To trust developers to identify and address inefficiencies. That said, it has presumably to be pre-guided by strategic direction/metrics.
• Call out of the heroic failures, and need more distributed ownership.
• Cross discipline outage remediation (not just service /tech team)
• Avoidance of folk-model ( buzz-word /meme which leads to poor communication) - so dont argue over meaning, spend less time on that
• Call out to Dekker The Field Guide To Understanding Human Error ( human error is the cause of trouble, mistakes are made by bad-apples, that need to be thrown out. Blameful culture. Malice, incompetence. Blame, shame, fire. Versus Human error is a symptom of trouble deeper in the system, structural rather than personal issues. Share stories of failure and embrace them to learn together, not shame them, leading to fear and hiding issues. ( I agree with this 95%, I still some times bad apples or incompetence is a problem, especially in the sense of fairness, who is working hard versus slacking etc, so yes macro culture should be blameless but individuals still need accountability and management to goals and sometimes are not a fit).
• Rock climbing, Scuba diving... etc analogies of good team work to shared goal, where indivudal performance matters a lot, as does trust and competence, but also there needs to be slack and support etc etc.
• Shout out to XP and Crystal Clear by Cockburn (frequent delivery of usable code, deploy more often, reflective improvement, osmotic comms - chat more in slack on remote teams to have a chance to get this ruminations)
• Good history of devops call out to the 10+ Deploys a Day ( Flickr: Dev & Ops Cooperation at Flickr) - John Allspaw, Paul Hammonds.
• Switch from What to Why as a focus - leads to better critical thinking and job satisfaction. push on the why.
• Great definition of Continuous Deployment - deploying changes to production by defining the set of tests and validations to minimize risk. The faster we do this the sooner individuals see their changes in effect, visibility of work impact increases job satisfaction, and overall, happiness with work, leading to higher performance.
  
• Not a panacea - more change != more value ( has to actually please customers... but a good proxy assuming you know how to please customers... or are measuring that).
• Great XKCD reference on time spent versus saved
• Devops antipatterns ( Blame culture, Silos, Root Cause Analysis -- suprised me, Human Error)
• Slightly reductionist Cognitive Styles - but very useful to remember
• Trust but verify - super important
• The value of social capital - rockstar versus superflocks.
• https://hbr.org/2012/04/the-new-science-of-building-great-teams
• https://www.youtube.com/watch?v=V-QR3thHm5c

Thoughts it led to:

• With super distributed teams osmosis of collocated teams does not happen as much, and lets face it, will never be back to what it was. Encouraging more active threads and transparency around releases, post-mortems, learnings, in slack, wikis etc - how to boost and replace the loss from osmosis?
• Remember to shut up more, I can definitely talk over people and talk too much, bad traits as a leader. I do it sometimes out of a sense of urgency to conclude matters when I already know the direction or outcome, but to grow others you need to stop and listen, and sometimes my assumptions when rushing are wrong too. Its hard to change but is a reminder.

...This is an unfinished review, Effective DevOps remains a book that I refer to from time to time on my shelf.

Recap: