Articles

At Fleet, the head of design ships to production. Here is the rule that makes it work.

Fleet lets named people outside engineering merge their own changes to the website, docs and handbook with no engineer review. We read six months of its public pull requests to see how it works and how often it broke.

Case study5 min read

This is an analysis of public data. Fleet is not a Hybrid customer and did not use Hybrid. Everything below comes from Fleet’s own open-source repository.

Fleet is an open-source device management company, and almost everything it does happens in public, including the automation that decides who needs a reviewer. That makes it a rare chance to see how a real team lets people outside engineering ship to production, and what happened when they did.

The rule

Fleet’s website runs a small GitHub automation, get-is-pr-preapproved, backed by a map of folders to the people allowed to merge their own changes there. When a pull request comes in, it lists every file the pull request changes and checks the author against that map.

  • All or nothing. The pull request is pre-approved only if the author is listed for every changed file, or for a folder above it. One file outside their area and it goes to normal review.
  • Named people, not teams. The map lists individual GitHub accounts.
  • A size cap. A pull request that changes 100 files or more never qualifies.

In practice, the people merging this way included the head of design, the CEO, a go-to-market lead and a product marketing manager. The areas they could change on their own were the website, the docs, the handbook, articles, app icons and the app catalog.

Approval isn’t a job title. It’s a rule about who can change what.

How much it covered

We counted merged, human-written pull requests in fleetdm/fleet from April to October 2026, leaving out bots.

  • 778 of 5,023 merged without an engineer’s review under these rules: 15.5% of everything people wrote.
  • 482 of those 778 came from people who aren’t engineers.

That is roughly one change in six that didn’t wait for an engineer at all.

How often it broke

We looked for later pull requests that undid each change.

  • Self-merged under the rule: 4 of 778 reverted, 0.51%.
  • Reviewed by an engineer: 0.64% reverted.

We wouldn’t call that safer; four reverts is too few to tell. But it is clearly no worse. And the detail that matters most: all four reverted changes were operational config files (GitOps YAML). Not one was copy, design or docs.

What to copy

  1. Scope by folder, not seniority. The question is “what can this person change?”, not “how senior are they?”
  2. Name people. A list of accounts is easy to read, easy to audit and easy to change.
  3. Make it all or nothing. One file outside someone’s area sends the whole change to review.
  4. Cap the size. Big changes go to a person, whoever wrote them.
  5. Keep config off the list. Fleet’s only reverts were configuration, so leave those files with engineers.
  6. Measure it. Count self-merged changes and their reverts against reviewed ones. It is the evidence that lets you widen the list later.

Where a folder rule stops

This works beautifully for content and assets, because they live in their own folders. The changes business teams wait on most, such as pricing, sign-up flows and settings, don’t. They sit inside the same code as payments and login, so “who wrote it and where” is no longer enough; the change itself has to be checked against what your engineers decided is sensitive. That is the gap Hybrid is built for.