Blogs about Jazz

Blogs > Jazz Team Blog >

DevOps Culture – Thriving at the edge of chaos

Tags: ,

In my previous post on building robust teams, I mentioned the need to have some people in a team with an appetite for risk and some who are risk-averse. Some people take risks because they are too inexperienced to know better but some experienced people know that it’s important to take risks.

NetFlix continuous delivery gurus, Cory Bennett and Ariel Tseitlin, wrote in a recent blog post: “We have found that the best defense against major unexpected failures is to fail often. By frequently causing failures, we force our services to be built in a way that is more resilient.” The resiliency in software that Bennett and Tseitlin refer to is not that different to the robustness in teams that I wrote about. Whether it’s software, teams, or any other kind of system, you have to take risks if you want to survive and thrive in a competitive world and taking risks means sometimes making mistakes.

This means you must have a culture in which it is okay to make mistakes in the pursuit of pushing boundaries. Google’s culture of innovation accepts mistakes as a normal part of the research and development process. According to Eric Schmidt, Google’s Chairman: “The way you say this is: ‘Please fail very quickly – so that you can try again’.”1 Larry Page, Google’s CEO, said to one employee, upon hearing from her that she had cost the company several million dollars, “I’m so glad you made this mistake. Because I want to run a company where we are moving too quickly and doing too much, not being too cautious and doing too little. If we don’t have any of these mistakes, we’re just not taking enough risk.”2 Shona Brown is no longer with Google but she was an ex-McKinsey consultant who was at one time Google’s Senior Vice-President of Business Operations and known to some as the company’s “Chief Chaos Officer.”  She co-authored Competing on the edge: strategy as structured chaos with Kathleen M. Eisenhardt, Professor of Strategy and Organization at Stanford University, in which they wrote: “Mistakes occur because systems at the edge of chaos often slip off the edge.  But there is also quick recovery and, like jazz musicians who play the wrong note, there is the chance to turn mistakes into advantages.”3

Jazz musicians do indeed know a lot about performing at the edge of chaos. Miles Davis is supposed to have said “There are no mistakes in jazz – only opportunities.” If we play it safe all the time the music quickly becomes boring and predictable. When we take risks interesting and exciting things can happen but we have to allow for the possibility that something might not turn out as we expect it to. When that happens, it’s not the “mistake” that matters but how we cope with it that’s truly important.

In the course of managing both our development and our continuous delivery transformation in the Collaborative Lifecycle Management Project (CLM) we’re often trying to identify risks and we will even track these by adding custom fields to work items to track things like risk and confidence. It’s good project management to do that and to focus on those risks and what needs to be done to mitigate, reduce, and eliminate them. However, if the picture shows that there’s little or no risk at all then it’s quite possible that we’re simply not pushing hard enough and that may be the biggest risk of all.

I think the idea of taking more risk is good food for thought. Are you making enough mistakes on your project?

Adrian Cho
Program Director, Continuous Delivery Evangelist
IBM Rational
Author of The Jazz Process: Collaboration, Innovation, and Agility


1 The rise and fall of corporate R&D: Out of the dusty labs.” The Economist. March 1, 2007.

2 Lashinsky, Adam. “Chaos by design: The inside story of disorder, disarray, and uncertainty at Google. And why it’s all part of the plan. (They hope.)” Fortune. October 2, 2006.

3 Brown, Shona L., and Kathleen M. Eisenhardt. Competing on the edge: strategy as structured chaos. McGraw-Hill Ryerson Agency, 1998, p. 28.