devops graph

What Exactly is DevOps and Why Should We Care?

- Updated March 14, 2018

Imagine yourself on a typical Software Development team. What might you see?

You might imagine a chaotic cycle.  Misalignment between people and groups.  Building the wrong things based on politics.  Walled gardens or “silos” where managers have carved off their fiefdoms.  Resume-driven projects.

You may also imagine a tighter, healthier environment.  One where teams move fast in exciting, creative ways.  Products will be iterated over and improved.  Building the right thing at the right time. Work is productive and energizing.

If you’ve been around Software Development long enough,  you will undoubtedly experience some or all of what I described.

Wouldn’t it be great if we could incentive the good, healthy behavior and depress the bad patterns that turn up so often in our organizations?  Why do we fall into these bad systems of working together?

DevOps is both The Culture and the The Practice that aims to promote better Product Development through continuous improvements, systems thinking, prioritization, and a dash of Automation Engineering.


It’s The Culture, Stupid

Some people struggle to define DevOps because it is process, thought, and culture.  But, it is also Engineering:  tooling for Continuous Delivery, Containerization, Serverless, Automation, etc.  And, it is also all these things.

How many times do we see: “We do DevOps at our organization because we have a DevOps Engineering team”?  A staffed DevOps Engineering team is not a sufficient, nor a necessary, part for an organization “to be doing DevOps”.

When I test a team on how well they are doing DevOps, I score based on things like:

  • Do the Development teams know what the Operations teams are working on?
  • Do the Operations teams know what the Development teams are working on?
  • Do the Operations teams know what the Development Roadmap looks like?
  • Do the Operations teams know why/how the Development Roadmap is set?
  • Do the Development teams know why/how the Development Roadmap is set?
  • Can the Operations teams draw a clear line from their work to major Business Objectives?
  • Can the Development teams draw a clear line from their work to major Business Objectives?
  • How do projects get approved?
  • Who can propose projects?
  • Which team members can vanish today without disrupting the Roadmap?
  • Which team members can map out the entire flow of an idea from proposal, approval, development, release to customer, and maintenance?
  • Who is responsible for continuously improving this flow?
  • Which team members can explain all the different ways customers supply feedback and how is that data collected and provided back to the organization?
  • How much time is set aside for each person to continually improve their daily work?

Take a minute to answer these questions for you or your team.  Share these questions with your teams and see how they respond.  The answers, and sometimes the difficulty in finding the answers, will be surprising.

In short, a well-functioning DevOps team will always:

  • Consider their work as part of a larger whole of the organization (called Systems Thinking)
  •  Understand how and why feedback is collected and distributed through the organization (called Amplifying Feedback Loops)
  • Strive to Continuously Improve the quality and speed of the work done (a Culture of Continual Experimentation and Learning)
  • Apply these concepts to both Product Development AND their team’s own Operations.  This is why it is called “DevOps” as both Development and Operations have something to learn from one another.

Tools and Patterns

After an organization is participating in good DevOps culture, common tools and patterns emerge.  Today, many organizations shortcut directly to the tooling before getting the culture in order.  This is a dangerous approach and can lead to counter-intuitive returns, complicated and slow workflows, and ultimately Bad Product Development.

However, get your house in-order first, and all the good DevOps Engineering practices will fall into place.  Features such as:

  • Continuous Delivery
  • Automated QA
  • Automatic Security (commonly “SecOps”)
  • Site Reliability Engineering
  • Cloud or Hybrid Cloud Architecture
  • Microservices
  • Infrastructure-As-Code
  • Serverless Architectures
  • Containerization
  • Cluster Computing
  • Data Science and Data Engineering

will all become available organically and at the right time for your organization to maximize the benefits.


There’s a lot of misunderstanding around DevOps.  Many find the water muddy and feel uncertain of when and how to get started.  Others are unsure if they are doing DevOps correctly.

From experience, I can say that start with getting the right culture established.  Focus your team on building great things for both your customers and for themselves.  The best place to start is with cultivating transparency at all points of the Software Lifecycle for all participants on the team — both Developers and Operators.  Build communication channels between these two areas of Engineering and prioritize understanding the other side.

Do these things and soon The Culture of DevOps will take hold throughout your organization and, with it, better Product and better collaboration.