People typically have the same three questions about DevOps:

  1. What is it?
  2. How do I start?
  3. How do I grow or scale?

Today let’s talk about that first question – what is DevOps?


I think this is the most underrated question about DevOps. No one wants to ask it because they don’t want to appear uninformed. The truth is that it depends. The answer is not simple and it depends on you, your goals, your organization, your situation and your culture. A DevOps presentation might be anything from AWS Lambda to SAFe4.0 to cultural trust surveys. If you do some thoughtful automation and you’re getting impactful business results, you’re probably doing DevOps right for your situation.


The DevOps community reinforces this frustrating ambiguity by purposely not defining it or providing something like a DevOps manifesto. We prefer to talk about it in terms of principles, a movement or a philosophy. I think of it as a continuum ranging from simple automation in a small team to hardcore full-stack at enterprise scale with full cultural buy-in and aligned incentives.


If you think you’re looking at the IT equivalent of a Special Forces team, you’re looking at DevOps. It’s like that famous phrase – “I’ll know it when I see it”. I know I’m looking at DevOps when I see a business value chain, inter-disciplinary teamwork, empathy, and ownership.


Here’s an example.

In a past role at a big bank, my team had automated over 800 applications from source to prod. This included individually analyzing and re-engineering every current build and deploy process to lean it out. We ran a highly responsive platform service team for our internal clients. I recall sitting down with an enterprise architect, who quickly told me “That’s not DevOps”. I thought that was a curious statement, given the huge value and time to market reduction we had created in our division.

As I thought about it, I realized his definition of DevOps was probably full-stack, meaning all infrastructure provisioned along with the applications. We had contemplated doing full-stack at the beginning of the project, but we made a deliberate choice to focus on the things we could control at the time that also had the most impact – the application stack. Like I said – it depends. Results are better than philosophy any day of the week.

Execs – don’t be afraid to ask the question. You might be surprised in the variety of responses (or lack of responses) from your different teams, consultants and vendors. In fact, if the person you’re talking to doesn’t begin their answer with “tell me more about your goals and situation”, you probably want to find another advisor.


Where did DevOps come from?

In case you haven’t figured it out, DevOps is a portmanteau of Development + Operations. Andrew “Clay” Shafer and Patrick Debois discussed agile infrastructure at the Agile 2008 conference. From those discussions, they created a series of DevOpsDays conferences in 2009, which launched our term DevOps. A major originating point of DevOps was a desire to use agile development concepts in the infrastructure world.

Many seasoned IT folks will tell you we’ve used DevOps concepts for years before the term was coined. My team and I were automating full application delivery back in 2005 for a hundred apps in a bank that no longer exists (wasn’t our fault…).


No Manifesto

DevOps is constantly evolving, and this is where the fun starts. A word of caution – if you’re the type of person who likes definitions, structure and manifestos, DevOps will feel uncomfortable. DevOps is intentionally fluid. The founding fathers of DevOps, never wanted anything like the Agile Manifesto. Here is a perfect explanation by Christopher Little (

“If you have a manifesto for something, then all conversation in the domain will, rather quickly, go back to the manifesto for resolution instead of everybody working together. That’s not handy in an ever-fluid, often on-fire, scale-up fast, resilience-oriented, rapidly changing and evolving IT situation.”

He nailed it. Solve together, don’t just check boxes.

We do agree on one thing. Good DevOps has a core of collaboration, empathy and culture. It is about breaking down silos between teams to deliver more value to the customer more quickly. It is about people.

But does a lack of consortium structure mean we’re somewhere between chaos and cowboy? Most definitely not. It simply means we’re self-organizing, picking ideas out of any tool box that help us deliver on our unique business goals. It means we need to be more disciplined, more trusting and more collaborative. These are the really hard parts of Big League DevOps, the Secret Scaling Sauce, and I’ll expand on it in a future article.

The term DevOps is a bit limiting after only 8 years, and this is a tribute to the evolutionary nature of DevOps and our exponentially increasing technology landscape. In 2009, the focus was on helping Dev and Ops work together, and sharing best practices. Today, an accepted scenario for DevOps is to include not just Dev and Ops, but also Security, QA, Audit, Risk, Architecture and the Business throughout the delivery cycle. Let’s throw cloud, microservices, containers and serverless architecture in while we’re at it.

I don’t think the term is going away any time soon, so we’ll use it to mean the entire business value chain of delivery. We definitely take the big picture view. In Gene Kim’s awesome book, “The Phoenix Project”, he describes this as The First Way. It is Systems Thinking, where the system includes Business and Customer.


Let’s recap:

• There is no formal, one-size-fits-all definition of DevOps, and we don’t want one.
• The term was coined in 2009 but many of the concepts are best practices and principles that have existed for years in high-performing teams.
• DevOps is bigger than just Dev and Ops.
• DevOps is about trust, teams, collaboration and removing silos, not just tools.
• DevOps grows and adapts to new problems in culture, process and technologies.

The Final Lap – A DevOps Reference Model

“The code is more what you’d call ‘guidelines’ than actual rules.”

– Hector Barbossa, Pirates of the Caribbean.



In keeping with the spirit of “no manifesto”, I’m going to outline our reference model of DevOps, or perhaps our overarching guidelines. At FlowStates, we use an acronym which is widely known in the DevOps circles – CALMS. Culture, Automation, Lean, Measures, Sharing. There are other variants such as CALMSS or CAMS. This is a great way to make sure you’re considering the most important dimensions. We’ve added depth to each element based on our experiences. Remember, we view DevOps as a continuum, it is adaptive, and the usable form depends on the client.

I’ll briefly summarize our Kingsmen CALMS and dive deeper into it in the next article.

C – Culture – The most important differentiating aspect, but also the hardest to directly control. Teams can’t often move organizational culture, so we focus on changing behavior to influence culture. We expand this to include concepts like behavior, trust, organization, incentives, ownership, and leadership. Most importantly, we include the ‘Why” of what you do. You’re going to pick up a little social psychology along the way.

A – Automation – The technical foundation of your delivery process and services, also called Continuous Integration & Continuous Delivery (CICD). This is a big bucket which could include technical strategy (cloud anyone?), QA, RM, Security, Risk, and Architecture.

L – Lean – Lean Process and Interaction. It can be either in technical automated processes, soft process interaction (Change Management for example), or interactions between people and technical or soft processes. This refers to Value Stream Maps, replacing manual steps with automation, pruning legacy processes, and minimizing delays between steps

M – Measures – You can’t improve what you don’t measure. Meaningful metrics from the beginning. What is our baseline and how do we know what success will look like? How do we know if we’re helping the business? Use Objectives and Key Results (OKRs).

S – Sharing – Share and collaborate everything. Lessons learned, back each other up, Empathy, common incentives, align activity to business unit goals and objectives. Blameless post-mortems. There is no more “Us and They”. There is only “We”. (h/t David Marquet).

Daunting? Don’t let the breadth overwhelm you. DevOps is definitely a journey and not a destination. It is possible to create a roadmap that starts with simple, clear actions while you grow into a DevOps Jedi Master. We’ll discuss that in future articles. That’s probably enough for today. Feel free to ping us at FlowStates or leave comments below if you want to discuss or comment on anything we’ve presented.