DevOps Hierarchy of Needs

I’ll start with a disclaimer: I am not a psychologist.

My sister is a psychologist, but I checked — and it turns out having a qualified relative doesn’t transfer any credibility to you.

Maslow’s Hierarchy of Needs (1943)

Many of us have heard of, or at least seen Maslow’s Hierarchy of Needs, which was first proposed by psychologist Abraham Maslow in 1943.

The hierarchy describes five tiers of needs from physiological (basic needs) to self-actualization (growth needs), with the basic premise being that the next higher level cannot be satisfied until the complete needs of the lower level is met.

Maslow’s Hierarchy of Needs (Source: Wikipedia)

Essentially: love and belonging cannot fill your needs if you are suffocating. And even if they did, it is (or is soon to be), moot.

Therefore, basic physiological needs are necessary to achieve any psychological needs.Whilst this might be true, some Internet psychologists (though I haven’t seen any diplomas) believe they’ve amended Maslow’s hierarchy to include a far more fundamental need to modern society:

Wifi Needs (Source: whatsthepont.com)

So where does DevOps come into this? I hear you ask.

DevOps is nebulous. It is not as simple as using Jenkins or Puppet. DevOps is an idea, a philosophy, a mantra.

There are many paths to DevOps success, but they all have a common set of needs.

Here at Forest Technologies, we believe that DevOps has its own hierarchy of needs. In fact, we’ve simplified it into the punchy slogan:

People, Process, Tools.

A hierarchy of DevOps needs?

I was interested to find out what others in the DevOps arena believed to be the essential DevOps needs.

After hours confined to a library conducting extensive research several minutes Googling, I managed to find a few pre-made examples of a DevOps Hierarchy of Needs, describing basic requirements to achieve DevOps with each level building upon the last.

Here’s the first:

Source: Martin Croker — martincroker.wordpress.com

This is a good start. There is a well defined path to achieve Continuous Deployment, with each level building upon the rest. You cannot achieve true Repeatable Delivery until you have Defined Environments and some kind of Configuration Management.

However, it fails to mention the people or the process involved in a DevOps transformation: the cultural aspect is missing.

The above diagram suggests that once you achieve Continuous Deployment you have achieved DevOps, which is, at best, only one third of the story.

So, we move onto hierarchy two:

Source: Aaron Suggs — Kickstarter

This is a much better definition. The hierarchy is not solely focused on tooling, but also includes people and culture.

This hierarchy very closely follows Maslow’s Hierarchy: it starts with physiological needs (Hardware) and security (Encryption, Vulnerabilities etc.), then progresses to more psychological needs such as Team Happiness.

The main problem in my mind, is that DevOps is not a human being. The Hierarchy is upside-down.

The Forest way is:

People OVER Process OVER Tools

People are more important (in a DevOps transformation) than processes, and processesare more important that tooling. Let’s face it: it doesn’t matter that your MTTP (Mean-Time to Production) has been reduced, if the change management board will only allow for one release to production per quarter.

So, what should the hierarchy look like?

Since DevOps is a cultural change, it follows that in order to succeed, we start with culture: with people.

  1. A DevOps culture (people) will allow proces sto be looked at and improved upon.
  2. Adapting process to be more “DevOps” is essential for any impact from tooling.
  3. Tools can only be looked at once there is a culture willing to adopt them, and the processes behind them are measured and understood

Here’s what we suggest the DevOps Hierarchy of Needs should look like (taking elements from both examples above):

  1. This hierarchy uses Culture as its base.
  2. Once culture is in place and is accepted, you can move on to Understanding. In this case, understanding covers not only your applications themselves (in terms of logging) but also any and all processes: both technical and business.
  3. The Improvement tier focuses on improving the processes that have been identified (we can’t improve them until we understand them).
  4. Idempotency comes next: the idea that the same actions should always have the same results. This is crucial for concepts like elasticity and microservices: if we aren’t 100% sure that our servers will be identical when they’re provisioned, we can’t be sure our applications will work.
  5. The very tip of the pyramid is home to Transformation, the land of Unicorns, such as Netflix or Etsy.

At the top, you are in a state where you can (or will soon be able to) deploy to production multiple times per day (or could, even if you didn’t).

Disclaimer: We do not believe that you can’t use tools early in your transformation: only that the effects of them are reduced or mooted until you have achieved the other upstream needs.

We believe that even with the best designed application and well-managed tooling, a DevOps transformation is not possible until people and processes — which are quite often the bottleneck in many IT projects — are on board.

If you want to find out more about the way we help organisations to implement and deliver effective DevOps, check out our solutions pages.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.