Drawing on my work with dozens of leading technology organizations for inspiration, I have synthesized three keys to encouraging innovation and growth. I call these Shlomo’s Keys to Technology Innovation. They are meaning, creativity, and habits.
Meaning
Connect the work people do with the values they personally identify with. People change only when they see meaning in their efforts to do so.
Jody Mulkey, CTO of Ticketmaster, exemplifies this. In the introduction to his talk at DevOps Enterprise Summit 2015, Jody shows how he personally identifies with Ticketmaster’s mission—to connect fans to live experiences—and how this fuels his passion for improving Ticketmaster’s technology.
As Jody demonstrates, driving change doesn’t begin with providing a reason, but by connecting to the values that the person holds dear. That is, meaning.
Creativity
Enable people to tap into their innate fountains of energy in pursuit of the meaning they seek. There are two aspects to enabling creativity: Helping people discover their creative energy, and establishing a fertile environment for its expression. Curiosity is the key to identifying your personal creativity catalyst. Do your talented people know their curiosity? Do your talented people pursue their curiosity within the parameters of their work, or despite their work? Get these two aspects of your organization right, or your talented people will leave for more creative pastures.
Habits
Establish those regular routines that support the pursuit of your goal. We all want to become more intelligent and successful overnight, and we also want to sleep soundly that same night. Unfortunately, it doesn’t work that way. Habits both simultaneously create the granite rock face of the status quo and serve as the drops of water that wear it away over time. Just as the rock face was built up gradually over a long time, significant change can only be effected through repeated, dedicated, accumulated small efforts.
Your organization delivers software, so it should be obvious that improving your software delivery means improving your organization. But how to improve your software delivery organization? I’m going to tell you how, and you’ll be amazed at its simplicity: To improve an organization’s performance you need to improve all the components of the organization. And, you need to know how to improve each component.
An organization is made of…
An organization is composed of people, process, and artifacts.
An organization is made of three types of ingredients: people, process, and artifacts.
People
People includes you and your staff, the relationships among them and between them and others, and the culture that shapes these relationships. When we talk about “improving people,” we mean developing peoples’ skills and shaping the organizational culture.
Process
Process includes the path that work follows through the organization as value is added at each step along the way to the customer. Improving process focuses on optimizing this flow of value to the customer.
Artifacts
Artifacts are the inputs that flow into the processes, the outputs that result from them, and the tools and technologies utilized in processing.
A model for improvement
The Lean methodology for improvement: build, measure, learn, repeat.
The Lean Startup movement inspired a very effective model for rapidly improving in uncertain and risky business situations. By rapidly iterating through successive Build-Measure-Learn cycles, you systematically reduce risk and uncertainty. Each iteration through the cycle examines and eliminates the greatest remaining risk as the organization learns how to reduce its shape, size, and probability. Over time, the business carries less risk and delivers better products and services, with increasing precision (to the right customers), reliability (service quality), and control.
Improving the components of your organization
By applying the Lean model to each component of the organization, we can arrive at a prescription for improving all of them.
Build people
By “build people” we mean improving peoples’ skills and the overall culture. Several methods are effective:
Model new behavior. Leaders adopt, demonstrate, and reward the new behavior. This is the quickest way to change culture.
Exercise the new skills. This is the most effective way to acquire new skills.
Train.
Provide a mentor.
Measure people
The extent to which a person’s skills have delivered the expected results can be measured by:
Review by others.
Test.
Learn what to improve next in people
By “learn” we mean identifying the next area that needs improvement. Two ways are effective:
Conduct retrospectives and blameless postmortems.
Analyze the results of the reviews and the testing (performed in the “Measure” step).
Build process
To build—that is, to improve—process you mercilessly simplify it. For example:
Reduce redundancy, handoffs, and re-work.
Reduce batch sizes and cycle times so less work is in progress but is completed more quickly.
Increase visibility so the current status of all work is obvious.
Empower people to use their judgment.
Shift the drudgery to automated tools.
Process improvement cannot be delivered in isolation, however. The people and the artifacts needed to support the process must be developed in order for the process to have the desired result.
Measure process
To measure the extent to which a process has achieved its desired result, audit the process. Look for evidence that the process was followed and that the desired results were obtained.
Learn what to improve next in process
To identify the next area of process improvement to pursue:
Conduct retrospectives and blameless postmortems.
Analyze the results of the audit performed in the “Measure” step.
Build artifacts
To build (improve) your inputs, tools, and outputs:
Reduce variance.
Increase tolerances.
Raise standards (i.e., decrease margin of error).
Measure artifacts
To measure the extent to which your inputs, tools, and outputs have improved:
Test (ideally automated).
Survey customers, internal and external.
Learn what to improve next about artifacts
To identify the next area of process improvement to pursue:
Conduct retrospectives and blameless postmortems.
Analyze the results of the tests and surveys performed in the “Measure” step.
Applying it
Try the above model for improving your software delivery organization. Like my other clients, you will see your software delivery performance improve dramatically. Contact me if you need help.
You may have heard that the goal of DevOps is to rapidly deliver and reliably operate high quality software-based services. But that is only partially true. True, that is the desired result. But fostering the habits that produce that result consistently is integral to the goal.
Habits foster results. The goal is both.
In my work with clients I have found several cornerstone habits essential to creating DevOps results, and I have helped software organizations embrace these habits and earn the payoffs. Let’s explore the cornerstone DevOps habits and why these habits are as much a goal as the results they promote.
Habits come in two flavors, and the first flavor of habits is practical.
Habits of Practice
Habits of practice are the behaviors we routinely engage in, often without thinking about it. We buckle our seatbelt when sitting in a vehicle, or we stash our wallet in the same pocket or the same place in our purse. What today is an unconscious habit once began as a conscious choice to behave in a certain manner. Perhaps we were reminded by our parent to fasten our seatbelt, and we complied, consciously, until repetition forged an unconscious habit. Perhaps we were alarmed at the thought that we would forget our wallet or keys someplace, so we patted down our pockets, consciously, like Peter Falk in the final scene of The Princess Bride, until that, too, through repetition, became an unconscious habit. Whether conscious or unconscious, these habits of practice create the results that we are safer while sitting in the car, and that we do not forget our wallet.
Habits of practice lead to results.
Habits of practice create results. In DevOps, we want to deliver high quality software-based service rapidly. The habits of practice that create these results include, generally, automation, measurement, and sharing.
The particular practices of these general categories vary with each organization, as each has its own business situation to contend with. But it is impossible to deliver high quality, reliable service without these practices, especially as the scale of the operation grows to significant size.
We want to foster these habits of practice. In order to successfully develop them we need the other flavor of habits.
Habits of Mind
Habits of mind are the manners of thinking and the internal monologue we conduct inside our own heads. Just as our behavior can be habitual, so can our thought patterns. Habits of mind are important because they can create and change habits of practice. For example, we all know the feeling of frustration when something in our lives isn’t working for us. It grates at us, it taunts, and it refuses to budge. Frustration is a sign that we need to change something about our lives. Our internal monologue upon encountering frustration influences whether we will change and what kind of change we will make in response. When our thoughts reflect passivity, I always have bad luck, we are not motivated to change. When our thoughts are empowering, this is an unfortunate but temporary setback, we are moved to change something about our situation—to try again, to try in a different way, or perhaps to let off steam and simply get over it.
In order to consciously create a new habit of practice, you need to have certain essential habits of mind. The essential habits of mind drive you to change your behavior over time, until you have improved your habits of practice. Without the supporting habits of mind, habits of practice are created by default, without our awareness, and these default practices seldom are the most effective at reaching our desired goal. Even once you have changed your practice, you can only improve by honing those practices, and the drive to improve your practice stems from your habits of mind.
Habits of mind foster habits of practice, which create results.
In short, habits of mind create habits of practice create results.
Culture drives the practices of automation, measurement, and sharing, which yields DevOps results: High quality, reliable software-based service.
In the DevOps field the factors that influence practice have been collectively termed “culture.”
But culture is an opaque term that does not lend itself to scrutiny. It is more useful to consider the habits of mind that foster habits of practice.
Shlomo’s Four Cornerstone Habits of Mind for DevOps Practices
The four cornerstone habits of mind necessary to foster DevOps practices and DevOps results are agency, awareness, respect, and healthy selfishness. Read on for more details on each of these habits of mind.
Agency
Agency means thinking that you can change things, that you can improve your lot through your actions, that you are an agent in your own life. If you believe you are able to change things then you can summon the motivation to try to change your behavior. On the flip side, if you lack agency—if you believe nothing you do will change anything—then you will be disheartened and won’t bother taking any of the steps necessary to change behavior. The more agency is ingrained as a habit of mind, the more you will feel in control and able to change your behavior.
This is a cornerstone habit of mind for DevOps because DevOps habits of practice require constant refinement, and you must believe that you can change and improve the current situation in order to do so. In an organizational setting agency is sometimes called “empowerment.” Organizations, too, cannot improve their practices unless members believe that they can change the way things are done. This is why agency as a habit of mind is so important for cultivating DevOps habits of practice.
Awareness
Awareness is the mental habit of perceiving what is around you. We are not aware of everything that transpires in our lives, and often we do not recognize that our practices can be improved. We cannot change our habits of practice if we aren’t aware that they need changing. This is true in life in general and with DevOps in particular.
Respect
Respect means acknowledging the feelings and opinions of others. Organizations consist of, and exist to serve, individuals with varied feelings and opinions. If you want to change habits of practice you must acknowledge the feelings and opinions of others who are involved. This doesn’t mean you need to feel those feelings yourself; it only means you need to believe that those feelings exist and are valid.
Healthy Selfishness
Healthy selfishness is thinking of your interests so that you can help others. It means thinking about how to overcome your obstacles to success and enabling yourself to do the same for your teammates. It means wanting to make your world better so you can make the world at large better. It is the driving force behind economic and technological progress. And healthy selfishness is essential for DevOps because it is the motivating force behind improving habits of practice.
What About Empathy?
Empathy is the ability to understand and share the emotions of others. It requires lowering your emotional defenses and allowing yourself to be vulnerable to the stirrings of another’s heart. Within the context of a supportive friendship or life partnership, empathy is vital. Understanding and sharing your partner’s emotions is essential to support them through pain and adversity and to grow together with them—in fact it is the essence of such a long-term relationship.
But empathy’s importance for DevOps has been drastically overstated. At our jobs we do not need to open our hearts to feel pain. Demanding that someone exhibit empathy evokes alarm and raises their defenses. Even professionals who do directly confront emotional pain, the psychologists, counselors, and ministers, do not allow themselves to be moved by the emotions they are exposed to in the course of their work. They maintain their emotional defenses. For the rest of us who do not deal directly with pain at work, which includes everyone in the IT and software industry, respect—acknowledging feelings and opinions of others—is enough for the professional setting. Insisting on empathy at work is irresponsible.
The Habits Are the Goal
DevOps is the continuous improvement of practices to rapidly deliver and reliably operate high quality software-based systems. Continuous improvement means regularly, consciously, and intentionally developing and honing those skills. In other words, DevOps is more than just the goal of delivery and operations. It is also the habits—of mind and of practice—leading to continuous improvement.
Shlomo’s cornerstone habits of mind, agency, awareness, respect, and healthy selfishness, foster the habits of practice, automation, measurement, and sharing, that drive the results of DevOps: high quality, reliable software-based service.
Fostering the three DevOps habits of practice—automation, measurement, and sharing—requires the four cornerstone habits of mind: agency, awareness, respect, and healthy selfishness. In all, those are the Seven Habits of Highly Effective DevOps.
The classic formulation of DevOps, Culture, Automation, Measurement, Sharing—”CAMS”—is an expression of habits of mind and habits of practice: culture is a habit of mind, automation, measurement, and sharing are habits of practice. To succeed at a DevOps initiative, you and your team members must exhibit these four habits of mind. They are the keys to forming productive habits of practice and, ultimately, the results you want to achieve: rapidly delivering and reliably operating high quality software-based services.
This podcast series explores topics of interest to OpenStack practitioners, focusing on the ecosystem in Israel.
In this episode I speak with Mårten Mickos, Head of Cloud Business at HP, formerly CEO of Eucalyptus and of MySQL AB. Some highlights of our discussion:
HP has made loud public commitments to OpenStack. What does HP’s acquisition of Eucalyptus in September 2014 mean for both OpenStack and for Eucalyptus? HP’s commitment to OpenStack is unwavering. Eucalyptus has always been focused on the very specific use case of Amazon-compatible clouds, and in 2013 Eucalyptus decided to integrate with OpenStack because OpenStack solves a more general use case than Eucalyptus, in a complementary manner.
On a technical level, there is still a lot to do to integrate.
OpenStack’s “more general use case” is to be an all-encompassing platform for private, hybrid, and managed clouds, and is therefore open to lots of variation and customization. One technology cannot support both that general OpenStack use case and the specific, out-of-the-box Amazon-compatible use case that Eucalyptus supports. Both can use the same underlying components—the same object store, for example.
Eucalyptus is to OpenStack as InnoDB is to MySQL.
OpenStack should have spent a lot more time in the design phase early on. They jumped in and started coding, and are now spending a lot of effort to address those design shortcomings. No project is ideal on the first try, but the design phase is supremely important for OpenStack because it is a distributed system, which is incredibly complex and difficult to diagnose and reason about issues once it’s live.
What will you do in order to help your developers tackle the complexity inherent in building these distributed systems? The easier a product is to use the more difficult it was to design. The HP Helion group has hired experienced distributed systems experts from the major cloud providers and also newer developers who live and breathe DevOps and agile development, and this combination is the right ingredients for solving the problems.
Will Eucalyptus end up being a set of microservices that can be deployed alongside an OpenStack deployment, providing heightened AWS compatibility? Quite possibly. There are many different tactics we can take toward technical integration, and in fact we already have run Eucalyptus inside OpenStack. Certainly, Eucalyptus will not become a wrapper around OpenStack. As eager as everyone is to hear about the technical direction Eucalyptus will take to integrate with OpenStack, we must move slowly in this design phase and ensure we’re doing it right.
It will be 2015 before any design commitment is made.
If you are involved in OpenStack and Eucalyptus, please reach out to Mårten and his folks at HP with any opinions about what you want to see from Eucalyptus’s integration with OpenStack.
What is the relationship between Eucalyptus and the new use cases that OpenStack is being pulled to address, such as telecom carriers’ Network Function Virtualization? There is any relationship you want. AWS compatibility and NFV can be used together or not, independently. HP can provide both.
In 2009 when Eucalyptus came out, we mistook people’s initial interest and learning as an indication of the existence of a market. It wasn’t a market. The market hasn’t taken off yet. It’s only now beginning to do so. So we have refocused on the use case of dev/test and Continuous Integration/Continuous Delivery, and seen heightened interest in our offering as a result.
I am often asked by CEOs and CIOs to explain the ROI of cloud computing. My answer goes something like this.
How well do you see? The main consideration in evaluating the ROI of cloud computing is your eyesight. What is the scope of your vision? What do you believe about the future? Ask yourself, as we create the ideal future for our customers, what kinds of changes will my organization need to accommodate? Think about how these changes will impact your use of computing – and indeed your entire operation. Consider the four major dimensions that change will include: technological, economic, organizational, and risk.
Cloud computing is a way of incorporating changes in technological, economic, organizational, and risk considerations into your use of computing. The value of cloud computing, when properly deployed, is in being able to support the changing technological, economic, organizational, and risk landscapes while keeping rock-steady focus on your business’s raison d’être: delivering great products and services to your customers. If you can see that future clearly, and appreciate the changes your organization will need to accommodate along the way, then you can make effective cost and value (ROI) decisions about cloud computing. You’ve got to see change in order to experience the sea change.
Do you need help painting your vision of the future and appreciating the changes necessary to get there? Contact me.
This podcast series explores topics of interest to OpenStack practitioners, focusing on the ecosystem in Israel.
In this episode I speak with Mark Shuttleworth of Canonical. Some highlights of our discussion:
The role Ubuntu and Canonical will play in OpenStack’s future.
OpenStack is the next phase of Linux: Linux at large scale. The majority of OpenStack deployments are on top of Ubuntu.
The mission is to bring regular, seamless releases of OpenStack to Ubuntu users. To do what Ubuntu did in the public cloud space – making it easy to operate at large scale – in the private cloud.
Looking back at Ubuntu, here is what we did that resulted in Ubuntu becoming ubiquitous in the cloud.
Took the cloud seriously from very early on. Noticed that many interesting, smart people were doing stuff with it.
Evaluated what people were doing and the difficulties. Noticed that classic OSes were built to assume the machine would be long-lived.
Changed Ubuntu to work very well in the cloud environment, beginning back in 2007.
The next frontier is in getting applications to be more widely operable, allowing organizations to share and reuse tooling to deploy and scale applications. That’s what Juju is all about, and it’s not Ubuntu-specific.
Developers use Chef and Puppet, and Juju is a distant third in the orchestration automation space.
Juju is a one of a newer generation of tools, so adoption is naturally lagging behind the older technologies. The growth rate of the Juju community indicates it is strong and healthy.
Juju “charms” can be used to wrap Chef or Puppet configuration management and turn it into automated orchestration.
Canonical uses Juju to glue together OpenStack and orchestrate it.
Juju began as orchestration automation for EC2 and then it was ported to other clouds.
Containers are very interesting. They are poised to become the unit of deployment for PaaS systems. They are also being used like hypervisors, providing multitenancy in environments where the priority is performance over isolation.
Ubuntu looked at OpenStack seriously from the very beginning, and threw its own weight behind the project when it moved away from another cloud infrastructure platform. Ubuntu contributed leadership around governance of large scale distributed open source projects. Much of the mystique around OpenStack will disappear over the next two years as it becomes more well-understood and proven to be easy to deploy. Now Ubuntu’s focus is to get OpenStack to be an economically viable alternative to public clouds.
Does OpenStack need a Self Appointed Benevolent Dictator for Life?
Moving some of the technical leadership positions into the OpenStack Foundation would help resolve some of the deadlock we see in the area – but this is not a demand, nor a necessity. OpenStack will thrive nonetheless.
And the project should encourage a healthy dialog about how its governance can be improved.
The Foundation has been wise to limit its staff, stay small, and stay focused during this period of incredible hype and willingness on the part of vendors to buy a role and ride the hype with fat checks. As vendors understand OpenStack and how they can contribute to it, those pressures will lessen.
It would be wise to take a narrow view on what OpenStack really is: Nova, Neutron, and Cinder — a very tight collection of resource management capabilities, with some additional glue around them for identity, security, and other bits and pieces.
If the technical leadership were brought into the Foundation, the pace of progress on this core of OpenStack would improve.
The Foundation has excellent governance, and in fact is long on governance but short on leadership. We need a Compute “Moses”, a Storage “Moses”, and a Networking “Moses”.
This podcast series explores topics of interest to OpenStack practitioners, focusing on the ecosystem in Israel.
In this episode I speak with Benny Schnaider, Chairman and co-Founder of Ravello Systems. Some highlights from the episode:
The history of virtualization in two minutes, and why it is still important today.
Virtualization provides separation, deployability, and mobility. What virtualization has done for VMs, Ravello is doing for collections of VMs – that is, entire applications.
How is this different from a platform-as-a-service? IT is currently interested in infrastructure, and will continue to be for the foreseeable future. The cloud provider will always be interested in using VMs as the isolation unit between tenants, and a PaaS environment will not be uniform across providers, so IaaS will continue to be attractive from both sides of the market.
OpenStack is interesting for Ravello because the more standardized the IaaS features are, the easier it is for us to expand our support for more cloud providers. And, we allow OpenStack developers and operators to create OpenStack deployments within the public cloud, speeding up development and testing.
How do you keep up with what’s going on in the OpenStack ecosystem? Blogs, reading, attending events, and attending the summits, where it is important to go to meet the people.
Docker is gaining attention – what do you think of it and similar container technologies? If you can live with the limitations of a container, then that’s great. But Ravello can run Windows VMs and other OSes, which containers cannot do.
Ravello is used to host OpenStack and deploy it on top of a public IaaS cloud, and provides full Layer 2 networking capabilities, which containers can’t support.
OpenStack won’t be the only IaaS solution in the future.
This podcast series explores topics of interest to OpenStack practitioners, focusing on the ecosystem in Israel.
In this episode I speak with Dagan Gilat, Senior Manager of Cloud Platforms at IBM Haifa Research Lab.
Highlights from the podcast:
The major areas of focus of the IBM Haifa Research Center.
How cloud computing workloads have changed over the years.
As workloads need to bridge the gap across from traditional style to cloud style architectures, OpenStack becomes more interesting….
IBM’s initial contributions to OpenStack were in the areas of enabling IBM storage products, and maintaining HA despite certain kinds of hardware failures. Later contributions include the areas of resource management and VM placement, storage – Swift and Cinder – including secure multitenancy, on-demand data migration, and networking contributions.
Interesting lesson from the OpenStack Summit in Altanta last week: OpenStack is a mature system that can handle a fairly complex and heterogeneous environment that includes many types of computational abstracts – containers, vms, bare metal servers – and many types of hypervisors.
The initial challenge with OpenStack was in climbing the learning curve. It was difficult to bring up the environment, networking configuration was complex, automation tools were lacking. These areas have improved, and several alternatives are available – so the challenge today is to choose a solution wisely. The key to choosing is to evaluate the options carefully, with the help of an experienced partner.
Most companies will choose a distribution instead of adopting the vanilla OpenStack project.
The main obstacle facing OpenStack today is its complexity. Each subproject within OpenStack will succeed or fail based on the quality of its technical leadership.
From IBM’s experience in keeping large clusters of OpenStack up and running, it’s important to ensure you only upgrade to stable versions, and it’s equally important to ensure that, like the technology, your operational processes are mature.
This podcast series explores topics of interest to OpenStack practitioners, focusing on the ecosystem in Israel.
In this episode I speak with Nelson Nahum, CEO and founder of Zadara Storage. We talk about:
What does Zadara Storage do and how do you use OpenStack?
How easy or difficult have you found it to keep up with the changing APIs across releases, especially in the early days of OpenStack? What should OpenStack users do to keep up
What challenges have you had with using OpenStack?
What do you think of RedHat’s acquisition of Inktank, creators of storage provider Ceph that is popular in OpenStack deployments?
What lessons have you learned from your experience operating several large scale OpenStack deployments?
How can we get an OpenStack Summit to happen in Israel?
