Merge, Don't Mandate: How Smart Engineering Teams Are Running Their Orgs Like a Git Repo

Somewhere around the third all-hands meeting where a decision got reversed with no explanation, Priya—an engineering lead at a mid-size SaaS company in Austin—started thinking about pull requests.

Not for code. For decisions.

"In our codebase, nothing gets merged without context," she told me. "There's a description, there's a rationale, there are reviewers, and there's a history you can always go back to. But in our org, a VP could just... decide something, and two weeks later nobody remembered why, or who had objected, or what the alternative was."

She's not alone in this frustration. Across the US tech industry—particularly in distributed and remote-first teams—there's a quiet but growing movement to apply version control principles to organizational decision-making itself. Call it GitOps for your org chart.

The Problem With Top-Down Decisions in Distributed Teams

Traditional management hierarchies were designed for a world where the people making decisions and the people executing them were in the same building. Information flowed slowly, so you needed a chain of command to make things move at all. That logic doesn't hold in a distributed engineering team where a developer in Denver and a designer in Miami are collaborating in real time on a shared codebase.

When you apply a 1970s org model to a 2024 distributed team, a few things reliably go wrong:

• Decisions get made without the context that the people closest to the work actually have
• There's no audit trail—bad calls get quietly abandoned rather than formally reversed
• "Politics" fills the vacuum where transparent process should be
• Disagreement goes underground instead of being surfaced and resolved

The result is slower shipping, higher turnover among your best engineers (who have the most options), and a culture where people stop raising concerns because they've learned it doesn't matter.

What Git-Like Governance Actually Looks Like

Let's get concrete, because "applying version control principles to decision-making" can sound like consultant-speak if you don't ground it.

The core idea is this: treat significant team decisions the way you treat significant code changes. That means:

Branching — Propose Before You Decide

Instead of a manager announcing a decision, someone opens a proposal. This could be a structured doc (Notion, Confluence, a literal markdown file in a repo—teams use all of these), and it follows a template: what problem are we solving, what options did we consider, what's the recommendation, and what are the known tradeoffs. The proposal is the branch. It exists separately from "main" until it's been reviewed.

Review — Real Consensus, Not Rubber Stamps

Designated reviewers (not just whoever is senior) have a defined window to comment, ask questions, or formally object. This isn't a veto system—it's a signal system. Objections get logged. If a proposal moves forward over a documented objection, that's fine, but the objection is part of the record. Transparency is the point.

Merging — Explicit Commitment

A decision isn't made until it's "merged"—meaning a designated person (could be a team lead, could be a rotating role) formally closes the review period and marks the proposal as accepted. At that point, it's part of the team's decision history. Searchable. Attributable. Real.

Rollback — Admitting a Bad Call Without Drama

This is the part that surprises people most. When a decision turns out to be wrong, teams using this model open a new proposal to reverse or modify it—and they link back to the original. The rollback isn't an embarrassment. It's just another commit. This makes it psychologically safer to change course, because the process doesn't require anyone to publicly admit failure. The system absorbs it.

What Teams Are Actually Using

A few tools have emerged as favorites for this workflow. Some teams run their entire decision log in a GitHub or GitLab repo—literally markdown files, PRs, and comments. It's nerdy, but it works beautifully for engineering-heavy orgs because everyone already lives in that environment.

Others use Notion with a structured template database, tagging decisions by status (Proposed / In Review / Accepted / Rolled Back). This is friendlier for cross-functional teams that include non-engineers.

For teams that want something purpose-built, tools like Loomio or Pol.is offer structured async deliberation with voting and comment threading. Loomio in particular has been adopted by a number of US worker cooperatives and open-source foundations for exactly this kind of governance.

The Objection Everyone Raises

At this point, someone always says: "This sounds slow. We can't open a PR every time we need to decide something."

Fair. And good implementations account for this. The model isn't meant for every decision—it's meant for significant decisions. What counts as significant? Teams typically define this by impact threshold: decisions affecting more than X people, decisions that are hard to reverse, decisions that involve resource allocation above a certain level. Everything below that threshold moves fast, informally, the way it always has.

The irony is that having a clear process for big decisions actually speeds up smaller ones. When people trust that the important stuff gets handled transparently, they stop relitigating every minor call in Slack threads at 11pm.

What Changes When You Ship This

Teams that have moved toward this model consistently report a few things. Politics drops. Not because people become less political—they don't—but because there's less to gain from backroom maneuvering when the record is public. Engineers who previously stayed quiet start engaging with proposals because they know their input is actually part of the process. And leadership, paradoxically, often feels more confident making hard calls because the rationale is documented and the team was genuinely consulted.

The org chart doesn't disappear. Someone still has to make the final call when consensus breaks down. But the shape of leadership changes—from issuing mandates to curating proposals, facilitating review, and maintaining the integrity of the process itself.

That's a model of leadership that a lot of engineers actually respect. And in a market where retaining good technical talent is brutally hard, that's not a small thing.

The hive runs on collective intelligence. Might as well build the governance to match.