Resource Guide To The Unicorn Project (Part 1)

First off, I want to thank everyone so much for all your support, encouragement, teachings, stories, and enthusiasm for The Unicorn Project. I am so delighted that we hit #2 on the Wall Street Journal bestseller list for hardcover business books on the week ending November 30, 2019!

I hope that having The Unicorn Project show up alongside other business books shows that the technology challenges we face today are genuine business challenges that cannot be delegated away to “those technology people.”

In this blog post, I provide resources and further reading for concepts in The Unicorn Project. I first list the books that most influenced my thinking during the development of this book, as well as a chapter-by-chapter list of references to the many many lectures, talks, videos, articles, tweets, and personal correspondences with people I admire that inspired scenes in those chapters.

This post expands upon the citations listed at the end of the book. I added further background, commentary, and additional readings for people interested in learning more about those topics.

(PS: The contents of this blog post will change, as it gets edited for clarity and correctness, and I will likely add to it as I finish up Part 2!)

Books Describing Core Concepts

Before I go into the chapter-by-chapter list of references, I want to describe the books that most heavily influenced The Unicorn Project. In my opinion, these books are the best codifications of the most relevant bodies of knowledge which the DevOps community draws upon:

1. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Dr. Nicole Forsgren, Jez Humble, and Gene Kim (IT Revolution, 2018).
   
   This is the best body of work that summarizes the six years of the State of DevOps Report, a cross-population study now spanning over 35,000 respondents. This is the same type of study that linked cigarette smoking with early morbidity and mortality. This study helped us define what high-performing software delivery looks like, and what factors predict high performance.
   
   I’m so pleased that this book won the Shingo Publication Award in 2019, which is one of the most cherished marks of recognition in the Lean community—a community and body of knowledge that greatly influenced the DevOps community.
   
   You can watch Dr. Forsgren and Jez Humble’s 2018 presentation at the DevOps Enterprise Summit here. (Twitter: @nicolefv, @jezhumble.)
   
2. The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition by Dr. Steven J. Spear (McGraw Hill, 2010).
   
   This is one of the most eye opening and illuminating books about dynamic learning organizations, which is the category that I believe academics and historians will call the next generation of management methods, of which DevOps will be considered a subset of. (To substantiate this claim, please see my references to Dr. Mik Kersten and Dr. Carlota Perez later in this post.)
   
   Over the years, I’ve benefited so much from Dr. Steven Spear’s mentoring and coaching—his works have profoundly influenced my thinking ever since I took his three-day “High Velocity Learning” course at MIT in 2014. You can read my review of his book here.
   
   Since then, the DevOps Enterprise community has been able to learn so much from him—you can watch his DevOps Enterprise London 2019 video here. You can also watch this amazing 30-minute panel about the intersection of Lean, Safety Culture, and Resilience Engineering (along with Dr. Sidney Dekker and Dr. Richard Cook).
   
   (And for those of you who want to see more, here’s the 2.5-hour panel session we had done before that, along with my friend John Willis.) (Twitter: @stevenjspear, @botchagalupe.)
   
3. Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework by Dr. Mik Kersten (IT Revolution, 2018).
   
   Every decade, I read a couple of books that genuinely change my worldview. On my bookshelf, you can tell which books they are, because more than one-third of the pages are bookmarked, each dog-eared page indicating something I felt was truly an important, aha moment or a reminder to myself to study further later. Project to Product is definitely one of these books.
   
   I genuinely admire this book—as in, I wish I were smart enough and had the experience to have written it.
   
   From Dr. Kersten I learned about the four types of work that an engineering team does: features, defects, risks, and debt. These categories are mutually exclusive and comprehensively exhaustive, meaning that doing more of one type of work must be at the expense of the other three.
   
   For me, it provided the first compelling model of the causation of how technical debt is created, and how feature freezes can help pay it down and restore agility. It made sense in light of all the case studies I had been collecting for years, such as Microsoft, Google, Facebook, LinkedIn, as well as one company that didn’t make it — Nokia.
   
   You can read the foreword I wrote for this book here. And you can see Mik presenting on his lifetime of work at DevOps Enterprise Summit 2018 here. (Twitter: @mik_kersten.)
   
4. The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt and Jeff Cox (North River Press, 1984). And Beyond The Goal: Eliyahu Goldratt Speaks on the Theory of Constraints (Glidan Media, 2011).
   
   Dr. Eliyahu Goldratt wrote this seminal book in 1984, a Socratic novel about Alex Rogo, a plant manager who must fix his cost and due date issues in ninety days or his plant will be shut down. This book has been incorporated into many MBA curriculums, has influenced multiple generations of business leaders, and has sold over six million copies to date.
   
   We structured The Phoenix Project to closely mirror The Goal—my co-authors and I studied this book for nearly a decade, getting ready to write. The Phoenix Project was written as an homage to The Goal. We attempted to mirror most of the book structure and plot elements, while making it contemporary, relevant, and hopefully more dramatic.
   
   I wrote an entire blog article in 2013 about Dr. Goldratt’s body of work, as well as how it influenced my work, here.
   
   Beyond The Goal is an amazing tour de force by Dr. Goldratt. In six hours he describes his entire lifetime of learnings, told against the historic backdrop of the manufacturing revolution in the 1980s, his learnings and reflections of having written The Goal, the creation of MRP systems and the digitization of entire organizations via ERP, and his own aspirations for a more scientific way of working and creating value.
   
   (And if you love Beyond the Goal, you’ll likely also like Beyond The Phoenix Project, which John Willis and I created in 2018. In this audio book, we explore the four bodies of knowledge that have impacted DevOps the most: Theory of Constraints, Lean, Safety Culture, and Dynamic Learning Organizations. This was the perfect project in preparation for writing The Unicorn Project! I wrote an entire series of blog posts on this project here. ) (Twitter: @GoldrattBooks.)
   
5. The Principles of Product Development Flow: Second Generation Lean Product Development by Donald G. Reinertsen (Celeritas, 2009).
   
   This is another stunning book because it is grounded in Lean principles, but it reveals how new thinking is required to address the unique challenges (and opportunities) of software development. Unlike the realm of manufacturing and highly repetitive work, software design and development is inherently full of variability and uncertainty. Furthermore, design and development work is often never repeated exactly, so it rarely benefits from the repetition that we see in manufacturing (e.g., high repetition, low variability, and low cycle time), which allows us to manage down certain types of risks in those domains.
   
   This book not only brilliantly describes the problems inherent to software development, and provides a dazzling array of tools and techniques to get better outcomes, primarily through taking an economic view of work: calculating and using cost of delay to prioritize work, reducing batch size, controlling flow, and decentralizing control.
   
   Writing this it occurs to me how it so brilliantly extends the concepts introduced by Dr. Goldratt to knowledge work. In manufacturing and services, the primary business risk we talk about is how downtime impacts production throughput. However, in product development, the business impact is much, much more devastating. In certain industries, such as pharmaceuticals, for each day you can get to market faster, you can often capture upwards of millions of dollars of additional revenue. (This quote is in The Unicorn Project and is from Dr. Steven Spear.)
   
   This is very similar to the dynamic that defines the problems with poor flow in software development, framed so brilliantly by Mr. Reinersten. I re-read this book every several years, and I always learn something on each re-reading. (Twitter: @dreinertsen.)
   
6. Team of Teams: New Rules of Engagement for a Complex World by General Stanley McChrystal, with Tantum Collins, David Silverman, and Chris Fussell (Portfolio, 2015).
   
   This is one of the best books I’ve read in the past decade for so many different reasons. It is the story of how in 2004, the Joint Special Forces Task Force was failing to achieve its mission to defeat Al Qaeda in Iraq (AQI), a much smaller but nimbler adversary. It’s fascinating to see so many of the same forces we feel in business and technology being felt by a military and intelligence agency command, with the charter to protect citizen and warfighters.
   
   What makes this story so amazing are the unique problems suffered by the joint operations of elite units across all the US military agencies: Army Rangers and Green Berets, Navy SEALs, etc. These were some of the most highly trained and experienced teams around, but what they all had in common was that the team was the “boundary of which everyone else sucked.” In other words, members of each team believed they were the best, and that everyone outside of the team sucked. And of course, they all believed that their counterparts in the intelligence agencies were one rung lower than all of them.
   
   This is a story of how General McChrystal and his team were able to create the conditions so that all of these teams could work together toward a common goal (creating a “team of teams”), as well as dramatically decentralizing decision making, pushing decisions down to the lowest possible level so that people on the front lines could quickly make decisions.
   
   One of the most remarkable stories is how after years of work these teams were able to go from “sighting to capture” of high-level AQI leaders in less than forty-five minutes, reversing the situation that had plagued the JSFT for years, where they found itself constantly reacting to and seemingly being outwitted by their adversary, often requiring days or weeks to plan and execute an operation.
   
7. A Seat at The Table: IT Leadership in the Age of Agility by Mark Schwartz (IT Revolution, 2017).
   
   I love everything that Mark Schwartz writes, and like many books written by philosophers, it’s very difficult to describe succinctly what Mark’s books are about. His first book, The Art of Business Value, was like Zen and the Art of Motorcycle Maintenance for technology.
   
   This book brings the same incredible perspective and process of inquiry to technology and business leadership, and questions so much of common wisdom we take for granted. It decisively and logically shows what in that thinking is wrong, and provides alternative ways to think about the problem. (Twitter: @schwartz_cio.)
   
8. Technological Revolutions and Financial Capital: The Dynamics of Bubbles and Golden Ages by Dr. Carlota Perez (Edward Elgar Pub, 2003).
   
   This book by Dr. Carlota Perez was introduced to me by Chris Little (@cshl1) in 2013, and I continue to be dazzled by Dr. Perez’s work. This book describes the astonishing regularity of technology revolutions that seem to happen every fifty to seventy years. Dr. Perez studied the last 250 years and identified the following revolutions: Industrial Revolution, Age of Steam and Railways, Age of Steel and Heavy Engineering, Age of Oil and Mass Production, and Age of Software and Digital (renamed by Dr. Mik Kersten).
   
   She posits that during each age the following cycle happens: there is an intense period of innovation fueled by financial capital, a financial boom followed by a financial crash, then a period of re-regulation of this new technology, and then, ideally, a multi-decade golden age fueled by production capital where this new mode of production is exploited within all industries.
   
   What is exciting to me is each age also results in a new mode of management that emerges to exploit this new means of production. In order, these ages resulted in factory systems, subcontracting, Taylorism, and Fordism. My long discussions with Dr. Mik Kersten and Dr. Steven Spear have convinced me that the new management mode, described so brilliant in Team of Teams and The High-Velocity Edge will be dynamic learning organizations, of which DevOps is certainly a subset of.
   
   
   
   A marvelous description of how Dr. Perez’s work has influenced our thinking is this blog post by Dr. Kersten, which is also an amazing exposition of the Five Ideals. I will most certainly be writing more about Dr. Perez’s work and its implications to technology management. (Twitter: @CarlotaPrzPerez.)
   
9. Transforming Nokia by Risto Siilasmaa (McGraw-Hill Education, 2018).
   
   This is another one of the best books I’ve read in the past decade. I will describe in more detail why this book was so impactful to me later in this post. Mr. Siilasmaa joined the board of Nokia in 2008, when it was the world’s ninth most valuable brand, with a market cap of $90 billion. My first reaction was “what could we possibly learn from a person who oversaw the 93% decimation of the company?”
   
   There are four reasons to read this book. First, he describes the likely all too familiar dysfunctional power dynamics present on the Nokia board, where a “dream team” of directors were unable to see internal problems, where novelty and dissent were suppressed by a very powerful chairperson. Mr. Siilasmaa presents an unflinching assessment of his own performance and reflects on his inability to elevate issues sooner.
   
   The second reason is the importance for business leaders to understand developer productivity and technical debt. He explains how he discovered in 2010 that the Symbian OS build times were forty-eight hours. He recognized that this technical debt and architecture was the death-knell for all near-term profitability and long-term viability. This led to re-platforming to Windows Mobile, which wasn’t successful either, but it was a far better bet than staying on Symbian OS.
   
   The third reason to read this book is the astounding story of how Nokia is acquired by Microsoft for $7 billion (with Mr. Siilasmaa as CEO), because of incredible scenario planning and brilliant execution. This is despite Nokia’s grave cash position. He writes, “Our business was going so badly that we had one foot in the grave and the other on a banana peel…We had bet our entire business on Windows Mobile…and now it would bring Nokia to the brink of the grave or straight into it.” Despite bankruptcy being a distinct possibility, they were still acquired for over $7 billion, with all parties satisfied that it was a fair price.
   
   The fourth reason to read the book is to see how Mr. Siilasmaa has led Nokia to its new chapter (now serving as board chair), having quintupled the value of the company by creating and reinforcing a culture of a dynamic, learning organization. I will write more about his view of data as a critical and core organizational competency in Part 2. (You can watch an hour video he does on machine learning here.) But sufficed to say, this is an incredible book—what Team of Teams did for the military world, Transforming Nokia portends for the commercial world.
   
   In my opinion, this book should be added to the mandatory reading list for the National Association for Corporate Directors. The world will be a far better place if all corporate directors and executives heeded his advice. (Twitter: @rsiilasmaa.)
   

Description of the Remaining Resources

The rest of this blog post and follow-up posts will present additional resources and concepts presented by each chapter. The Unicorn Project has nineteen chapters. I start with Chapter 2, as there are no references in the first chapter.

Chapter 2

• Over the past many years in the DevOps Enterprise community, we’ve been seeking to better understand how to span the divide between business and technology leadership. In this journey, a source of incredible insight has been Chris O’Malley, CEO of Compuware, the famously resurgent mainframe software vendor.
  
  To hear from a CEO of a software company, who lives and dies by the speed of delivery and quality of the software they create, watch this fireside chat with Chris O’Malley (CEO, Compuware) from the DevOps Enterprise Summit Las Vegas 2018. Mr. O’Malley talks about technology and business leaders as John Lennon and Paul McCartney, the two parts of a duality needed to create greatness. In the business context, they must work together to understand what customers are dissatisfied by, find ways to delight those customers, built with greatness in both product and engineering.
  
  However, in many organizations this requires a completely new mindset in leaders and new ways of working that look very different than how we’ve done things in decades past. (I introduce this fireside chat with a reference to the famous “Ones and Twos” post by Ben Horowitz, where he describes the “ones” as the product visionaries, and the “twos” as the executives who create process excellence.)
  
  In 2019, I had the privilege of doing a follow-up fireside chat with Mr. O’Malley and his CFO, Joe Aho, to better understand how we can get conservative financial leaders on board. And what better example of a conservative financial leader than the CFO!
  
  What emerged was a fascinating discussion about the timeless power of the three metrics of employee engagement, customer satisfaction, and cash flow. They both assert and convincingly defend how focusing on these metrics will inevitably lead to success. In The Unicorn Project, these three metrics are prominently featured in Steve’s Town Halls.
  
  The logic that Mr. O’Malley presents is simple:
  
  – Customer satisfaction: organizations exist to serve their customers, and this is a measure of to what extent they are being served.
  
  – Employee engagement: to what extent are people in the organizations energized and engaged in the company mission to serve their customers, and to what extent are the full extent of their creative powers being translated into things that customers care about.
  
  – Cash flow: businesses are not charities, and must manage operations so they don’t run out of cash—and of course, this applies to not-for-profits too (e.g., charities, government agencies, military services). (Twitter: @chris_t_omalley.)
  

Chapter 3

• Elements of Clojure by Zachary Tellman (2019) is an amazing and astonishing book that talks about the principles of great software design. In many ways, it’s more of a philosophy book than a software engineering book.
  
  Like the aforementioned Mark Schwartz, Mr. Tellman has a background in philosophy and takes the reader on a wild ride of exploring names, idioms, indirection, and composition. It is full of surprising insights. From this book comes the observation that building mathematical libraries can be like bridge building, because the fundamentals of mathematics don’t change—however, building a software product for a customer or market is far more difficult, because requirements may drastically change, so it is an endeavor fraught with far more uncertainties. (Twitter: @ztellman.)
  
  Evidence of Mr. Tellman’s point about the longevity of mathematics libraries: Python’s dominance of scientific computing is often attributed by its ability to use the famous high-performance LAPACK linear algebra library, written in FORTRAN in 1992, twenty-seven years ago at the time of this writing. It was modeled after LINPACK, which was also written in FORTRAN in the 1970s, nearly fifty years ago at the time of this writing.
  
  (In this video, “Tricking Sand into Thinking: Deep Learning in Clojure,“ Dave Liepmann speculates that the reason Java didn’t take off for scientific computing was the absence of the ability to use these mathematical libraries. In contrast, the Python NumPy library leveraged the ability to use these great libraries, through FORTRAN bindings and more. Fortunately, there are a number of exciting things happening that are finally bringing these capabilities to the JVM. (Twitter: daveliepmann.)
  

Chapter 6

• The incredible Jon Smart is responsible for the most incredibly pithy, lovely, and absolutely accurate definition of DevOps: “Better Value, Sooner, Safer, Happier.” Watch his DevOps Enterprise Summit London 2019 presentation to see how he’s developed this idea more fully.
  
  You can watch more of his brilliance in his other equally important presentations: “The PMO is Dead, Long Live the PMO – Barclays” from DevOps Enterprise Summit London 2018, where he presented with Morag McCall, Director of Project Management at Barclays. It’s an incredible presentation that describes the bottlenecks that the project management, budgetary planning, and fiscal release processes create. (This was the basis of the contrast between the old way of working vs. the far more dynamic process used to support the Horizon 3 initiatives, described after Chapter 19 in The Unicorn Project.)
  
  You can also watch Mr. Smart’s presentation “Risk & Control is Dead, Long Live Risk & Control” from DevOps Enterprise Summit 2019, which addresses the incredible problem of real-world risk and controls organizations face in regulated companies. I am certain that the implications of these problems will be explored in the years to come in the DevOps Enterprise community.
  
  (Incidentally, I’m so excited to see Jon Smart pouring his unique genius into a new upcoming IT Revolution book!) (Twitter: @jonsmart.)
  

Chapter 7

• Rich Hickey, “Simple Made Easy,” InfoQ, recorded at QCon London 2012, posted June 20, 2012.
  
  So many of the ideas of the First Ideal of Locality and Simplicity were inspired by Rich Hickey, the inventor of the Clojure programming language. I wrote about how his ideas and Clojure re-introduced the joys of coding into my life in my blog post “Love Letter To Clojure (Part 1)”. Learning Clojure also led to a series of revelations about all the invisible structures that are required to enable developers to be productive. These concepts show up all over The Unicorn Project, most prominently in the First Ideal of Locality and Simplicity, but also how those conditions can lead to the Second Ideal of Focus, Flow, and Joy.
  
  Without doubt, Clojure was one of the most difficult things I’ve learned professionally, but it has also been one of the most rewarding. It brought the joy of programming back into my life. For the first time in my career, as I’m nearing fifty years old, I’m finally able to write programs that do what I want them to do, and am able to build upon them for years without them collapsing like a house of cards, as has been my normal experience.
  
  The famous French philosopher Claude Lévi-Strauss would say of certain tools, “Is it good to think with?” For reasons that I will try to explain in this post, Clojure embraces a set of design principles and sensibilities that were new to me: functional programming, immutability, an astonishingly strong sense of conservative minimalism (e.g., hardly any breaking changes in ten years!), and much more…
  
  Clojure introduced to me a far better set of tools to think with and to also build with. It’s also led to a set of aha moments that explain why for decades my code would eventually fall apart, becoming more and more difficult to change, as if collapsing under its own weight. Learning Clojure taught me how to prevent myself from constantly self-sabotaging my code in this way.
  
  To read more about Rich Hickey (Twitter: @richhickey), you can read my blog post “Love Letter To Clojure (Part 1)”. And you can also watch the talk I gave at the 2019 Clojure/conj conference: “Love Letter To Clojure: And A Datomic Experience Report”. And you can find a worthy list of other videos to watch here (selected links from my Clojure love letter) and here (the “Rich Hickey Fan Club” links by Talles L).
  
• Ward Cunningham, “Ward Explains Debt Metaphor,” wiki.c2.com, last edited January 22, 2011.
  
  Here you will find the transcript of Ward Cunningham explaining the history of the metaphor of technical debt, and a lengthy and nuanced explanation of the various aspects of technical debt. I think it is absolutely terrific, and I find Dr. Mik Kersten’s treatment of “debts” as one of the four types of work in the Flow Framework a brilliantly simple way to integrate into the software planning process.
  

Chapter 8

• “What people think programming is vs. how it actually is,” YouTube video, Posted by Jombo, February 22, 2018.
  
  This is the great video that Maxine references which so brilliantly summarizes the way that movies depict how developers work as opposed to the way they really work. It’s only thirty seconds long, but it shows the striking contrast of how programming is portrayed in the movies versus what it actually looks like in real life.
  
  I got particular delight out of the scene where Jared performs the code deployment, resulting in everyone cheering and clapping him on the back. Har har!
  
• Ryan Naraine, “10 Years Since the Bill Gates Security Memo: A Personal Journey (Guest Editorial by Michael Howard)” ZDNet, January 13, 2012.
  
  Bill Gates, “Bill Gates: Trustworthy Computing,” Wired, January 17, 2012.
  
  These articles on the famous Microsoft security stand-down are amazing, describing how Bill Gates, then CEO of Microsoft, responded after the “Summer of Worms” in 2001, when Code Red, Nimda, and SQL Slammer used vulnerabilities in Microsoft software to wreak havoc on the internet. The practice of the stand-down (i.e., “feature freeze”) was informed by the .NET team’s success using techniques such as Security Bug Bashes and their Security Standdown, periods which were solely dedicated to address security issues, which also included broad security training for developers or even finding new security problems!
  
  The first article was written by Michael Howard (author of the book Writing Secure Code), and he describes a pivotal meeting he had with Bill Gates, which led to what became known as the “Windows Security Push,” leading to Bill Gates’ Trustworthy Computing memo (citation above).
  
  This initiative proved to be so effective that it was later adopted by most of the other major Microsoft product groups, such as SQL Server, Exchange, and Office. The outcome was that it changed how engineers and managers across the entire organization thought about integrating information security objectives into everyone’s daily work.
  
• Risto Siilasmaa, Transforming NOKIA: The Power of Paranoid Optimism to Lead Through Colossal Change (McGraw-Hill, 2018) Kindle, 49.
  
  One of the most remarkable parts of this book quoted in The Unicorn Project is when he learned in 2010 about the forty-eight hour build times of the Symbian OS. He described that it felt like “being hit in head with a sledgehammer” and how “all the hopes and promises made by the R&D organization [were] a mirage” of which all near-term profitability and long-term viability hinged upon. He wrote that “if it required two days for anyone to determine whether a change worked or would have to be redone…[revealed] a fundamental/fatal flaw, dooming our near-term profitability and long-term viability.”
  
  In my mind, this is one of the most incredible evidence points of how important “code build/code deployment lead time” is, which every business leader (and board director) needs to understand.
  
  I think this serves as a stark contrast to how technical debt almost killed every one of the tech giants (e.g., Facebook, Amazon, Netflix, Google, Microsoft), but they were able to survive by eradicating it. (See the comments on Microsoft security stand-down above.) These near-extinction events show us how important acknowledging and managing technical debt is:
  
  – Ebay (1999)
  – Microsoft (2002): Bill Gates memo
  – Google (2005): Automated testing culture
  – Amazon (2004): Jeff Bezos memo
  – Twitter (2008): Fail Whale
  – LinkedIn (2009): Project Inversion after IPO
  – Etsy (2009)
  
  You can read some Twitter threads I wrote that gush about how much I love this book here and here. I especially love Sam Guckenheimer’s insightful comment about Nokia in the 2000’s: “It wasn’t that Nokia didn’t do the right thing; it was that it did the right thing for too long.” What a great summary of the innovator’s dilemma! (tweet)
  
• John Cutler (@johncutlefish), “Case in point (from actual org) * In 2015 reference feature took 15-30d. * In 2018 same (class of) feature took 150-300d primarily bc of 1) tech debt, and 2) fast track silver bullets to drive success theater and/or acquisitions (for same effect) Cc: @realgenekim @mik_kersten” Twitter, September 29, 2018. (Link to tweet)
  
  
  
• John Allspaw, “How Your Systems Keep Running Day After Day – John Allspaw,” YouTube video, posted by ITRevolution, from the DevOps Enterprise Summit Las Vegas, 2017.
  
  In this amazing video, the famous John Allspaw describes so many of the new concepts that are showing up in the incredible vibrant Chaos Engineering and Resilience communities. He talks about concepts such as “above and below the line,” the notion that incidents are unplanned investments made without your consent, and that we are responsible for maximizing our return on those unplanned investments. (Twitter: @allspaw.)
  
• Charles Duhigg, “What Google Learned From Its Quest to Build the Perfect Team,” New York Times, February 25, 2016.
  
  “Guide: Understand Team Effectiveness,” ReWork, accessed August 21, 2019.
  
  These are wonderful articles that describe Project Aristotle, which was started in 2012 to understand what made great teams great. One of the stunning findings was the the top factor was psychological safety.
  
• Team of Teams: New Rules of Engagement for a Complex World by Gen. Stanley McChrystal, with Tantum Collins, David Silverman, and Chris Fussell (Portfolio, 2015). Described at top of this article.
  
• The Principles of Product Development Flow: Second Generation Lean Product Development by Donald G. Reinertsen (Celeritas, 2009). Described at top of this article.
  
• The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition by Steven J. Spear (McGraw Hill, 2010). Described at top of this article.
  
• “Convergence of Safety Culture and Lean: Lessons from the Leaders,” YouTube video, posted by IT Revolution, from DevOps Enterprise Summit San Francisco 2017.
  
  In Beyond The Phoenix Project, John Willis and I describe the shoulders of giants that the DevOps movement is standing upon, including Dr. Eliyahu Goldratt, Dr. W. Edwards Deming, as well as the Lean and Safety Culture movements.
  
  As aspiring students of both Lean and Safety Culture, John and I observed that there seemed to be many commonalities between these two movements, such as the need for psychological safety, a scientific method for the improvement of daily work, systems thinking, and so forth. However, instead of these movements seeing the other as mutually supportive bodies of knowledge, they seemed to view the other with suspicion or even in diametric opposition.
  
  Over the last four years, John and I have had the privilege of interacting with many of the most influential thinkers from these two movements. In 2017, John and I filmed a half-day panel with Dr. Richard Cook and Dr. Sidney Dekker from the Safety Culture movement, and Dr. Steven Spear from the Lean movement.
  
  As John will tell you, on the one hand it was amazing to see such an intellectual tour de force of argumentation, citing philosophy, physics, management and social sciences, medicine, ethics, economics, and even theology. On the other hand, it was at times a pretty stressful and wild ride, and at one point, John and I wondered whether we should have let this stay buried in the desert, so vehement was the discussion.
  
  However, by the end, it was clear that many principles and values span both Lean and Safety Culture. I can’t think of a better demonstration of this than the thirty-minute panel I moderated with Dr. Cook, Dr. Dekker, and Dr. Spear at DevOps Enterprise Summit 2017. I agree with my friend Charles Betz, who said, “This panel will go down in history as a watershed moment for the digital profession. Notable, in the fullest sense of the word.”
  
  I write about the making of this panel in this blog post.
  
• Jeffrey Snover (@jsnover) tweet, “I literally (and yes I do mean literally) wanted to hide under my desk. I knew that they wouldn’t be able to tell who did it (downside of DomainOS) so … making the phone call was one of the hardest things I’ve every done.” Twitter, November 17, 2017.
  
  Maxine’s story about how she accidentally deleted the source code repository is based on Jeffrey Snover’s story.
  
• “Paul O’Neill of Safety Leadership,” YouTube video, posted by Steve Japs, February 7, 2014.
  
  “Paul O’Neill The Irreducible Components of Leadership.wmv,” YouTube video, posted by ValueCapture, Mar 22, 2012.
  
  In The Unicorn Project, the story of Steve as a champion for physical safety in manufacturing plants is based on the story of Paul O’Neill and his tenure as CEO at Alcoa. Watch these amazing videos on how he talks about workplace safety as a precondition of work, how his board of directors initially thought his notions were outlandish, and the harrowing stories of how he dealt with workplace injuries and fatalities during his tenure at Alcoa, and how he later brought them to the US Federal Government when he served as Secretary of the US Department of the Treasury.
  
  Be forewarned: I found myself tearing up during many portions of these videos, and I watched them many, many times.
  

End of Part 1: Part 2 is Coming!

In the interest of getting something posted before 2019 ends, I am posting Part 1 now, which covers many of the major books that served as inspiration for The Unicorn Project, and a chapter-by-chapter listing of references for Chapters 1 through 8.

Part 2 will cover the books that I didn’t cover in this post, as well as completing the list of references for Chapters 9 through 19.

Again, thank you for all your interest, enthusiasm, and support. Have a wonderful 2019, and may 2020 be even more joyful and prosperous than 2019!

And for your researching and viewing pleasure, you can find a YouTube playlist of the videos I’ve selected here—this includes videos from Part 1, as well as the upcoming Part 2.

- About The Authors

Gene Kim

Gene Kim has been studying high-performing technology organizations since 1999. He was the founder and CTO of Tripwire, Inc., an enterprise security software company, where he served for 13 years. His books have sold over 1 million copies—he is the WSJ bestselling author of Wiring the Winning Organization, The Unicorn Project, and co-author of The Phoenix Project, The DevOps Handbook, and the Shingo Publication Award-winning Accelerate. Since 2014, he has been the organizer of DevOps Enterprise Summit (now Enterprise Technology Leadership Summit), studying the technology transformations of large, complex organizations.

Follow Gene on Social Media

• 
•