Day #1 – Before the Tools: Understanding DevOps Culture

Introduction

Hi, there! Last time, I shared how I found my way into tech from a totally different world and started exploring the cloud. From getting my head around AWS to eventually discovering that Linux isn’t just a penguin. That first blog was about curiosity: the kind that led me to open up CPUs as a kid and fumble through cloud certifications later on.

Since then, I’ve been slowly but steadily exploring the world of DevOps—reading, breaking things, fixing them (sometimes), and trying to connect the dots.

This time, I want to focus on a question that kept echoing in my mind: What is DevOps, really? Rather than a dry definition or a list of tools, I’ll share the story behind it—the culture, the teamwork, and why it’s become such a game-changer in how software is built and delivered.

If you’re curious about how DevOps fits into the bigger picture and why it matters, this blog is the next step in our journey together.

So, what is DevOps really about? Maybe the best way to explain it is to start with a story.

It’s the middle of the night—quiet, calm, the kind of silence you only get at 3 A.M. Somewhere, a deployment has just gone live. Somewhere else, a dashboard turns red. And one very tired ops engineer sits up in bed, staring at their phone.

The 3 A.M. Wake-Up Call

A developer is working late into the night, trying to push out a last-minute feature before a deadline. After hours of effort, they finally deploy the code, breathe a sigh of relief, and go to sleep.

But a few hours later, the phone rings. Someone from the operations team is being woken up—because the app just crashed.

It turns out, the new deployment broke something in production. No one caught it in testing. Now it’s 3 A.M., customers are angry, dashboards are red, and the team is scrambling to fix it before anyone at the top finds out.

By morning, frustration has set in:

• The developer’s asking, “Why didn’t operations catch the issue?”

• The ops engineer is wondering, “Why would you deploy something that late without testing?”

Both sides are pointing fingers—and both are exhausted.

But underneath the chaos, something more fundamental is broken. It’s not just about one bad deployment or a missed alert. It’s the fact that the developers and operations teams are working on the same product, but not on the same page.

They’re chasing different goals, working in isolation, and only crossing paths when something goes wrong.

And that’s exactly the kind of gap DevOps was created to close.

DevOps: More Than a Role—A Cultural Shift

So what is DevOps, really? Is it a job title? A set of tools? A magical script that fixes production at 3 A.M.?

Not quite.

DevOps is what happens when teams stop blaming each other and start building together. It’s less about a single role and more about a shared responsibility — a culture shift that changes how we develop, deploy, and operate software.

In reality, DevOps is a culture. It’s a new way of working—one where developers and operations don’t sit in separate rooms, but come together to build, deploy, and maintain software as a team.

Let me break it down:

Traditionally, developers wrote code and tossed it over the wall to operations. Operations made sure the servers were stable and the app was running. If something broke, it was ops' problem—even if it was caused by a recent code change.

DevOps says, “That wall? Tear it down.”

Now, both sides share the responsibility:

• Developers don’t just write code—they care about uptime, logs, and performance.

• Operations don’t just monitor infrastructure—they’re involved earlier in the development cycle, offering insights and constraints.

It's a bit like a relay race where everyone runs together instead of handing off the baton. The finish line isn’t "code complete"—it’s delivering value to the user.

Understanding that DevOps is a culture, not just a role or a set of tools, was a mindset shift for me. But even after grasping the why, I still found myself wondering about the how.

How does this all play out day to day? How do teams actually put DevOps into practice?

That’s when I came across something simple, visual, and surprisingly powerful: the DevOps loop.

The DevOps Loop: A Moment of Clarity

The moment DevOps truly started to make sense to me was when I watched a video by Techworld with Nana. Her explanation of the DevOps loop wasn’t just informative—it tied all the loose threads together.

Now, you’ve probably seen the above diagram before: two interlocking loops forming an infinite cycle, usually with words like Plan, Code, Build, Test, Release, Deploy, Operate, Monitor written along the curve.

But here’s the thing—this loop isn’t just a graphic. It tells a story:

1. Plan: Everything starts with a plan. Whether it’s fixing a bug, launching a new feature, or improving performance, the team gathers ideas and creates a roadmap.

2. Code: Once the plan is in place, developers start writing code. But in a DevOps culture, they don’t do this in isolation—they’re thinking about how this code will behave in production.

3. Build & Test: Code gets compiled or packaged and then tested—ideally with automated pipelines. This ensures it works before it ever touches a user’s screen.

4. Release & Deploy: The working code is now released to staging or production environments. Continuous integration tools handle much of this, allowing for safer, faster deployments.

5. Operate & Monitor: Operations teams keep the system running and track how everything performs. Metrics, logs, and alerts offer real-time feedback.

And then—it loops.

Everything learned in the monitoring phase flows back into the next planning session. That’s the magic of the loop: it’s continuous. It never stops improving.

And it made me realize: DevOps isn’t a one-time process. It’s a living, breathing cycle of learning and delivering.

DevOps and the Cloud: A Perfect Match

At this point, I started to understand why DevOps kept showing up in cloud computing circles.

Think about it: before the cloud, setting up infrastructure meant dealing with hardware, long provisioning times, and manual processes. You needed different teams just to set up servers or load balancers.

The cloud changed all that.

Now, a single developer can deploy scalable infrastructure in minutes. Tools like Terraform, AWS CloudFormation, or Pulumi make infrastructure code-based. And when everything becomes code, DevOps practices become even more essential.

The cloud gave us speed and flexibility. But DevOps taught us how to use that speed wisely because

It taught us how to automate safely, test continuously, and collaborate across teams so that we don’t just move fast, but move fast without breaking things.

With the cloud making infrastructure faster and more flexible, it quickly became clear why DevOps and cloud computing go hand in hand. But while the cloud gives us powerful tools and speed, there’s a bigger question that often comes up next: can you actually hire “DevOps” like a role or team?

Can You “Hire” a DevOps Team?

This question puzzled me for a long time. You see job titles like “DevOps Engineer” all the time. But how can you hire for a culture?

Here’s the reality: you can hire engineers who practice DevOps—people skilled in automation, CI/CD pipelines, cloud infrastructure, and observability. But DevOps isn’t something one person or team can “own.” It has to be adopted by everyone.

It’s like trying to hire a team to be responsible for "teamwork." You can’t outsource empathy, shared goals, or a sense of ownership. You can only build it.

So yes, you can have DevOps-minded engineers. But DevOps itself is something your whole engineering organization must buy into. Otherwise, it's just a fancy title with no impact.

The most effective DevOps engineers don’t just write scripts or set up servers. They advocate. They teach. They connect people. They make the developer experience smoother, and the operational load lighter.

So…Where do you start?

This is something I asked myself a lot in the beginning. The DevOps landscape is vast—there’s cloud, containers, CI/CD, observability, IaC, SRE principles, and more. Honestly? It felt like standing in front of the ancient one, wide-eyed, whispering:

But you don’t have to know everything all at once.

Start with principles, not tools. Understand why DevOps exists. Learn how teams collaborate, how they deploy code, how they monitor and respond to failures. Then, based on your interest, dive deeper. Maybe you love infrastructure—then Terraform and Kubernetes might be your thing. Maybe you’re a developer—then focus on building reliable pipelines and writing better deployment strategies.

Final Thoughts: DevOps Is a Story of People

At the heart of it all, DevOps isn’t just about tools, pipelines, or automation scripts. It’s about people.

At the end of the day, whether you’re a developer, an operations engineer, a platform specialist, or just someone starting out—the real goal is the same: delivering value to your customers.

That could mean pushing features faster. Or making systems more stable. Or automating painful manual tasks. Or helping someone else do their job better.

If my first blog post was about the chaos of starting, this one is about finding clarity.

DevOps is about collaboration over silos. Empathy over ego. Shared success over blame.

It’s not a product. It’s not a checklist. It’s a journey—just like mine, just like yours. And while the path might look different for each of us, the destination is the same: shipping better software, faster, and with a lot more human connection.

Thanks for joining me again. In the next post, I’ll dive deeper into some tools I’ve started exploring and how they fit into this DevOps loop. Until then—keep learning out loud.