DevOps with Water

Influencing Change Without Authority

The Solo DevOps Challenge

You’re the only DevOps engineer at your company. You see the problems, you know the solutions, but you don’t have the authority to mandate change. Every proposal feels like pushing against a wall. Teams have enough on their plate and resist new solutions, processes get stuck in approval loops, and your best ideas die in meetings.

Sound familiar? There’s a better way — one that flows like water.

What You’ll Gain

Water doesn’t force its way through rock. It finds the path of least resistance, carves channels over time, and eventually shapes the landscape. This is how you can approach DevOps transformation:

Build organic adoption: Instead of mandates, create followers who believe in your solutions
Flow around obstacles: Use freedom spaces (test servers, your own time) to demonstrate value
Show, don’t tell: Let success speak for itself through quick wins in early adopter projects
Influence through substance: Start small, prove value, then scale naturally

The Water Approach

I learned this firsthand when I set up a Grafana stack as a side project on a test server. Starting with logs, I added features incrementally whenever I had time. Developers started using it and telling colleagues about it. More and more adopted it. Recently, a colleague added metrics to his application; I scraped them, and now we plan to present it to the other developers so they can adopt it too. All of this happened without an official rollout from management — just natural, organic adoption that flowed from a small test server project.

Don’t Play with Fire

While water flows and adapts, fire forces and burns. These approaches create resistance:

“Everyone must adopt this now” — Creates resistance, management blocks, colleagues feel forced
“I know better, just do it my way” — No buy-in, no allies, no organic growth
“I can’t do anything without budget or approval” — Passive waiting, no demonstration of value, no leverage

Find Allies

Identify Early Adopters

Not everyone will resist change. Some developers are naturally curious, some teams are struggling with pain points you can solve, and some managers are looking for quick wins. These are your early adopters — your allies.

In Practice:

Look for teams complaining about deployment issues
Find developers asking about automation or monitoring their application
Identify projects with technical debt that’s causing pain
Connect with people who’ve shown interest in DevOps concepts

Show Quick Wins in Their Projects

Once you’ve identified potential allies, don’t ask for permission to transform their entire workflow. Instead, offer to solve one specific problem. Make it small, make it fast, make it visible.

Example:

“I can automate your deployment in 2 hours. Interested in testing it with me?”
“Let me set up monitoring for your critical service - no changes to your code needed.”
“Want me to create a simple CI pipeline to automate that daily 5-minute task?”

Let Success Speak for Itself

When your quick win delivers value, don’t celebrate alone. Let the team celebrate. Let them tell others. Your success becomes their success, and suddenly you have advocates spreading your ideas organically.

I built a small deployment automation and asked a team lead to try it with me. No big announcement, no mandate — just a working solution. It did what it promised. He liked it, so we improved it together. Soon, he was using it across more projects. Over time, that simple automation evolved into a unified pipeline: dependency updates, tests, deployments — everything in one place. Eventually, I presented it to more than 60 colleagues. Now, people come to me asking how they can use it.

No policy. No enforcement. Just proven value, flowing outward.

Convince Through Substance

Let People Try It Themselves

Instead of presenting slides about a new tool, set it up and let people use it. Hands-on experience beats presentations every time.

Example: Docker Logs Dashboard

I started by scraping logs with Grafana Loki and building a basic dashboard. Instead of SSHing into different hosts to grep files manually, developers could finally see and filter container logs across all servers in one place. I showed it to one colleague and he instantly liked it, showed it to his team, and adoption grew organically from there.

No presentation. Just a working solution which made their lives easier.

Organic Growth > Top-Down Mandate

When something works well in one project, other teams will notice. They’ll ask how you did it. They’ll want the same solution. This is organic growth — much more sustainable than forcing adoption through policy.

Carve the Way

Make the Right Thing Easy

If your solution requires 200 lines of configuration, people won’t adopt it. If it requires 5 lines, they will. Make the right thing the easy thing. Like a template to set up Docker-in-Docker and build your Docker Images:

1
2
3
4
5
6
7
include:
  - component: gitlab.com/gion-io/templates/docker/docker-build@main

build-job:
  extends: .dind_base
  script:
    - !reference [.docker_builds, default_build]

For the full technical breakdown, see: One Template to Rule Them All

Onboarding of new projects: 2 days → 2 hours.
Adoption: 50+ projects.
No mandate needed—just easier than the old way.

Immediate, Tangible Benefits

People adopt solutions that solve their immediate problems. If your DevOps improvement saves them 10 minutes today, they’ll use it. If it only helps “the organization” in some abstract way, they won’t.

Practical examples:

Time saved: “Your deployment takes 15 minutes manually? This script does it in 2. Want to try it?”
Pain removed: “Tired of SSH-ing into 4 servers to check logs? Here’s one dashboard with all of them.”
Visibility gained: “Can’t tell why your app is slow? This metric shows you exactly where the bottleneck is.”
Risk reduced: “Lost data before? This automated backup runs every night. Set it and forget it.”

Flow Around Obstacles

Start Small, Without Approval

You don’t need a company-wide mandate to improve a test server. You don’t need approval to automate your own workflows. Start where you have freedom, prove the concept, then let it grow.

Freedom Spaces:

Test or staging environments
Your own projects, side projects or proof-of-concepts
New projects that haven’t established processes yet

Practical progression:

One project, one feature — Start with logs for one service. Prove it works.
Wait for requests — Don’t push. When someone asks “can we add this for our service?”, that’s your signal.
Scale incrementally — Add one more service, then another. Each success builds momentum.
Document as you go — By the time 5 teams use it, you’ll have real examples and patterns. That’s when you create templates or automation.

Don’t Ask Permission When Success Convinces

If you’ve proven value and people are asking for your solution, don’t wait for formal approval. Implement it where there’s demand. Success is your permission.

When three teams were using my Grafana stack and asking for more features, I didn’t wait for a “formal rollout.” I added what they needed. By the time management noticed, it was already serving 30+ developers. Success had already given permission.

When to Ask Permission:

Production systems with high risk
Changes affecting multiple teams
Budget or resource requirements

When Success Is Permission:

Teams requesting your solution
Low-risk improvements
Solutions already proven in test environments

Be Patient, Persistent, and Adaptable

Accept Different Speeds, Repeat Consistently

Not everyone adopts at the same pace. Early adopters jump in, the early majority waits to see success, and laggards resist until they have no choice. That’s fine—water doesn’t rush.

Stay visible

Keep your solutions top-of-mind without being pushy:

In standups: “I automated the deployment for project X. If anyone wants the same, let me know.”
In chat channels: When someone asks “how do I check logs?”, share your dashboard link. When they complain about manual deployments, mention your automation.
Share wins: “Project Y just went from 2-day onboarding to 2 hours using our templates.” Let the numbers speak.
Different formats: Same message, different ways. Demo in a team meeting. Write a short internal blog post. Mention it in a 1-on-1. People need to hear things multiple times.

Small drops, consistently. One automation here, a monitoring improvement there. Over time, they compound.

Listen, Learn, Adapt

Your first solution won’t be perfect. Listen when people tell you what’s not working — their pain points are your next improvements.

Feedback sources:

Direct complaints or requests
Questions revealing confusion
Workarounds people create show you what’s missing
Adoption patterns: What solutions get used, which ones don’t.

Sometimes the “best” technical solution isn’t the right one. A solution that fits the team is better than a perfect one that doesn’t. Empathy before efficiency.

Take-Away

Why this approach worked for me

Water doesn’t force — it flows. As a solo DevOps engineer, you can’t mandate change, but you can influence it. Find one ally. Solve one problem. Use one freedom space. Start small, prove value, let success flow outward.

Like water, you’ll find your way.

Your Turn

Have you tried influencing change without authority? What worked? What didn’t? Share your experiences in the comments or reach out on LinkedIn.

Want more detailed field stories? If there’s interest, I’ll write a follow-up with step-by-step examples:

How I automated deployments for 50+ projects
The Grafana journey: From test server to 30+ users
When water met concrete: projects that failed (and what I learned)

Let me know what you’d like to see.