Here's something we see all the time: a team installs Argo CD (or Flux), points it at a Git repo, and expects magic to happen. Suddenly, deployments will be "safer," "auditable," and "self-service." Git becomes the source of truth, automation handles the grunt work, and humans finally step out of the critical path.
Sounds great, right? Except it often doesn’t work out that way.
The problem isn't the tools. Argo CD and Flux are solid. The issue is that GitOps forces you to answer questions your organization probably hasn't yet figured out. Who actually owns production? Who's allowed to change it? Who gets blamed when things break?
GitOps isn't a tooling decision. It's an organizational one. And most of us aren't ready for that conversation.
The GitOps adoption myth
You've heard this pitch: "We'll use Git as the source of truth, and teams can deploy without direct cluster access."
On paper, it checks all the boxes:
- Strong audit trails
- Reproducible deployments
- Fewer manual changes
- Reduced blast radius
But here's what nobody mentions: GitOps doesn't just change how changes reach production. It completely rewrites who gets to make them.
When a git merge triggers a production rollout, your pipeline stops being just infrastructure. It becomes a mirror of how your company actually thinks about responsibility and risk - ever heard of Conway's Law? Your deployment pipeline is Conway's Law applied to operations.
That's when the friction starts.
GitOps redefines ownership - like it or not
Before GitOps, production access was obvious. You had SSH keys, Kubernetes credentials, or a CI pipeline owned by some specific team. It wasn't perfect, but at least you knew where you stood.
GitOps makes access indirect but just as powerful. A commit to main is a production action. Full stop. So now you have to answer some uncomfortable questions:
- Who can actually merge to trunk?
- Who approves production changes?
- Who's responsible when a merge breaks everything?
- Who gets paged when Argo CD says "success," but your users see errors?
Most teams adopted GitOps without hashing this stuff out. The result? Ambiguity. Everyone assumes someone else owns the problem until something breaks and—surprise - nobody does.
GitOps doesn't remove responsibility. It just moves it into version control.
Your repository is your trust boundary
Here's something people underestimate: repository access equals operational power.
If your repo controls Kubernetes manifests, infrastructure definitions, and platform configs, then write access is effectively root access to production. This creates a real tension:
- Open it up too much, and you risk unreviewed changes with massive impact.
- Lock it down completely, and "self-service" becomes "file a ticket and wait for the platform team."
GitOps forces you to make trust explicit. Instead of hiding in credentials and hallway conversations, trust gets encoded in repository boundaries, branch protection, and review requirements. But explicit trust requires actual design. Without that, your GitOps repos become accidental bottlenecks.
The platform team trap
We’ve seen this pattern play out dozens of times:
The platform team owns the GitOps repos. They review every PR. They merge everything. They get blamed when stuff breaks.
At first, this feels responsible. You're protecting the system, right? But over time, you become a human bottleneck. Application teams lose autonomy. Changes slow to a crawl. And suddenly you're not just the platform team; you're the deployment team.
Sounds great, right? Except it often doesn’t work out that way.
A healthy platform team doesn't own every change. They own the mechanisms that enable safe changes.
What actually works
Teams that succeed with GitOps tend to land on a few common patterns.
Clear separation of concerns. Platform teams own cluster configs, policies, and shared services. App teams own repos that express what they want, not how to build it. Boundaries live in code, not in someone's head.
Intent over implementation. Instead of making app teams manage Deployments, Services, and Ingresses, give them higher-level concepts. A "Service" abstraction. A "Database" that hides cloud-specific details. Let GitOps reconcile intent, not raw YAML: less cognitive load, fewer foot-guns.
Guardrails, not approvals. Stop relying on humans to catch every mistake. Enforce constraints automatically. Set secure defaults that can't be overridden. Let humans intervene only when automation genuinely can't decide.
In this model, GitOps isn't a review workflow; it's a safety net.
The incident response problem
This is where pure GitOps thinking falls apart. "All changes go through Git" works great until your site's down at 2 AM and you need to move now. Reality is messier. During incidents, teams need speed, clear authority, and the ability to act without committee approval.
Mature organizations plan for this. They build break-glass mechanisms: time-bound elevated access, audited manual changes, and clear processes to reconcile back to Git afterward.
Knowing when to bypass GitOps isn't a failure. It's operational maturity. The key is making exceptions explicit, temporary, and well-understood, not your default path.
Scale breaks everything
At a small scale, GitOps friction is invisible. One cluster, three teams, a single repo: it's fine.
As you grow, GitOps amplifies every organizational crack you have. Unclear ownership becomes deployment paralysis. Poor boundaries mean PRs with 50 files and no clear owner. Overloaded platform teams become full-time blockers.
GitOps doesn't create these problems. It just makes them impossible to ignore. That's why "it worked in the proof of concept" so often fails in production.
What leadership actually needs to decide
Before you roll GitOps out broadly, get alignment on a few things:
- How much autonomy do you actually trust teams with?
- What level of production risk are you willing to accept?
- Who owns uptime versus deployment velocity?
- How do you measure success; faster merges, or safer systems?
Without clarity here, every incident becomes a process debate instead of a learning opportunity. Tools can't fix organizational ambiguity.
GitOps doesn't remove humans
Despite the marketing, GitOps isn't about "removing humans from production." It's about making human decisions visible, auditable, and repeatable. It replaces shadow actions with clear intent.
When GitOps works, it's not because the automation is perfect. It's because the organization was finally honest about how it operates.
GitOps is a mirror. It reflects your org design back at you, flaws and all.
Final thoughts
GitOps didn't fail your organization. It just showed you how decisions were actually being made all along.
Treat it as an organizational design problem first, a tooling problem second, and it can become the foundation of something genuinely good. Treat it as just another deployment tool, and it'll quietly inherit every dysfunction you already have.
