What is DevOps

I feel like there's still a lot of misunderstanding in 2025 about what DevOps actually is. This article will attempt to clear up some of the confusion. I’ll walk through the history, key concepts, and practical advice for how DevOps should be applied in your organization.

A Brief History

Although many contributed to the rise of DevOps, two of the most influential figures are:

• Patrick Debois, often called the Father of DevOps, who coined the term and organized the first DevOpsDays conference in 2009.
• Gene Kim, co-author of The Phoenix Project and The DevOps Handbook, who helped bring DevOps into the enterprise world.

In 2018, I was asked by the VP of Information Technology at Schweitzer Engineering Laboratories (SEL) to introduce DevOps across the company. I was new to the concept, but after attending trainings, reading books, and diving deep into the topic, something clicked:

DevOps is Toyota Manufacturing Principles and World-Class Manufacturing applied to software engineering and operations.

DevOps Is a Mindset

At its core, DevOps is a culture—a way of thinking. For organizations stuck in traditional silos, this is a massive shift. Many still operate with an outdated model: developers write code, then “throw it over the wall” to operations to deploy and maintain it.

This handoff model creates bottlenecks and communication breakdowns that slow delivery and introduce risk.

At SEL, this cultural shift was smoother than most—our manufacturing teams had already internalized world-class production practices. I focused on building the same mindset across software engineering: I ran live training, wrote documentation, published internal blog posts, and embedded across teams to mentor engineers and help them adopt DevOps principles organically.

Shift Left: Empowering Developers

The idea of "shifting left" means giving developers more control and responsibility over traditionally “ops-owned” tasks—like infrastructure, testing, and deployment.

But this only works when:

1. Culture Comes First

Operations teams often resist giving up control—not out of spite, but due to trust and risk concerns. That’s why leadership buy-in is essential. A DevOps transformation must come from the top (C-suite, VP, Directors) and be reinforced throughout the org. Without it, pockets of resistance will remain, and DevOps won’t fully take root.

2. Tooling Is Shared

Having CI/CD tools, Kubernetes, and source control isn't enough. Engineers must be empowered to use and configure these tools—within reason—without filing tickets or waiting days for access. That means embedding DevOps ownership across teams and shifting toward Infrastructure as Code, GitOps, and self-service workflows.

Example:
A dev team needs a firewall rule change. Instead of submitting a ticket, they update a config file in Git. Thanks to code ownership rules, someone from the networking team reviews the change. Once approved, automation handles the deployment through the CI/CD pipeline—first to a dev environment, then production.

3. Automate with Intention

Automation isn’t about pressing fewer buttons. It’s about enforcing consistency, reducing risk, and embedding security, review, and compliance directly into the deployment process.

The term DevSecOps is often used to emphasize this, but if you’ve implemented automation correctly—with gated PRs, signed builds, access control, and repeatable pipelines—security is already baked in.

Core Principles in Practice

Let’s take a look at three key concepts that underpin a strong DevOps practice.

Work in Progress (WIP)

In manufacturing, WIP refers to unfinished goods stuck in the process. In software:

• Long-lived branches create integration headaches. Keep branches short-lived and focused.
• Delays in code review slow down delivery and cause frustration.
• Multitasking often results in context switching and unfinished work.

One fix? Dedicate time daily—perhaps the last 30 minutes—to pull request reviews. Prioritize small, focused PRs to avoid review fatigue and keep work flowing.

If WIP piles up, engineers start fire-fighting bugs more than delivering features. This is the beginning of what I call the death spiral—a vicious cycle of instability, inefficiency, and developer burnout. If left unchecked, it can paralyze your team.

Technical Debt

Debt isn't always bad—it can be used strategically, like delivering a must-have feature quickly. But it must be paid down.

Otherwise:

• The codebase becomes fragile and slow.
• Vulnerabilities go unpatched.
• Dependencies rot.
• Performance suffers.
• Developers waste time debugging instead of innovating.

Eventually, you reach a point where you're so underwater with bugs and architectural rot that the only way forward is a full rewrite—or worse, your software becomes irrelevant and your business falters.

Yes, technical debt can kill companies.

This is true for operations as well: unpatched servers, outdated Kubernetes clusters, aging infrastructure. If not addressed, these too become risks to uptime, security, and innovation.

Automation

Automation is critical—but only when you first understand the manual process. Build it by hand, debug it, learn it. Then automate it.

A broken manual process, when automated, becomes a fast-moving disaster.

Automation should:

• Include CI/CD pipelines with integrated security gates
• Enforce version control, testing, and reviews
• Reduce risk and protect against human error

Summary Table