The Human Element

The non-technical side of DevOps.

Originally published May 1, 2020

Coming from software engineering into DevOps, I had a blind spot: I thought every problem was a tool problem. Bad deployments? Better CI/CD. Slow releases? More automation. Communication gaps? New dashboard.

It took years to see that a new tool isn't always the answer. As our development pipeline matured, it stopped being the bottleneck. The entire organization became part of the pipeline, and each team interacted with it differently.

The real challenge

Improving operations meant changing habits. That's a different challenge than changing how unit tests run.

The Process

Get Feedback First

Before writing code or changing a process, meet with the people who use it. How do they measure success? Why do they measure it that way? What technology is already in place? You might think you know what's broken. Get feedback first.

Take a Baseline

Measure where you are before you start changing things. You need this to communicate progress and to know if your changes are working. It's like taking a photo before a house project—the before-and-after is satisfying.

Start with an MVP

Pull together a minimal viable solution. I try to avoid writing code in the first iteration—this reduces scope creep, shortens lead time, and improves alignment. Starting without code also helps you see whether automation is needed at all.

Deploy with Support

Roll out the new process with some hand-holding. Monitor engagement, gather feedback in real-time, and document issues you didn't anticipate. Generate release notes for process changes the same way you would for code.

Measure Results and Learn

Take a new baseline. Compare to where you started. Did the change improve things? Did it move the needle on your objectives? Use this data to decide: pivot or persevere.

Remember: They Don't Have Your Context

The people you're rolling changes out to may not have visibility into:

The overall system

How this process fits into it

What's changing

Why it's changing

Explain what changed, show videos if it helps, and include baseline metrics so people know how you'll measure success.

Iterate

New processes rarely take root after the first try. It takes tweaks, improvements, bug fixes, support, and training to get people to adopt and habituate.

Daniel Coyle's research in The Culture Code explains why: shared purpose isn't created by an all-hands presentation about the new pipeline. It's built by small, repeated actions—showing up during Week 1 to troubleshoot, asking for feedback in Week 3, celebrating the first metric improvement in Month 2. Each of those moments sends a signal that says this matters, we're in this together, keep going. That's what turns a process rollout into a habit.

Stage	Focus
Week 1-2	Active support, fix obvious issues
Week 3-4	Gather feedback, refine rough edges
Month 2+	Measure results, decide to scale or adjust

The best DevOps teams don't just ship software—they ship processes that help the whole organization move faster.

Chop wood, carry water. The fundamentals of change management are the same whether you're rolling out a new CI pipeline or a new team ritual.

Rolling out process changes?

I've helped teams adopt new workflows without the friction. Let's talk about what you're changing.

Get in Touch