# Flat companies run on rules, not managers *Speed is easy to admire and easy to overspend. The teams that keep it encode their rules before they scale.* **TLDR:** If you've kept your company flat so you stay in direct contact with everyone, then watched small inconsistencies multiply every time you added a person, this article has the answer. You'll learn why the cost of unwritten rules grows faster than your headcount, why a flat structure depends on protocols being as reliable as good software, and how we encode our own operations as versioned rules so the system runs without a management layer. **Authors:** [Vadim Zolotokrylin](/people/vadim-zolotokrylin) --- Every team wants to run fast. Speed is the thing founders can feel, so it is the thing they protect. What they cut to protect it is almost always the same thing: the time to sharpen the saw. Writing down how the team actually works feels like overhead when the product is on fire and the next milestone is close. For a while, skipping it costs nothing. With three or four people in constant contact, the rules live in everyone's head and stay in sync by conversation. The saw is dull, but the tree is small. Then you add people, and the bill arrives all at once. ## The distortion amplifies with scale Unwritten rules do not scale linearly. Each new person is not just one more mind to keep in sync. They are one more set of connections to every other person, and every one of those connections is a place where an unstated rule can be interpreted a little differently. So the drift compounds. Two people can hold a shared understanding by talking once a week. Ten people cannot. The gap between what you think the rule is and what is actually happening widens with every hire, and by the time it is visible in the output, it has already been running for months. Founders usually reach for the obvious fix: add a layer. Hire a manager to hold the context, then another to manage the managers. The hierarchy grows to absorb the drift. It works, in the sense that a bandage works, but it buys coordination by putting distance between you and the people doing the work. You stop being in touch with everyone. You start hearing about the company secondhand. ## Flat is the more efficient shape We think the more efficient companies of the future stay flat. Founders remain in direct contact with everyone, on the same channel, reading the same source of truth, instead of routing everything through layers whose main job is to compress and relay information. Flat is faster because there is less translation loss, and it is cheaper because you are not paying for a hierarchy whose purpose is to manage the fact that nobody wrote anything down. But flat has a hard precondition, and it is the part most people skip. ## Flat only works if the rules are not optional A hierarchy can survive vague rules because a manager sits in the gap and improvises. A flat company has no one in that gap. The rules are the structure. If they are ambiguous or optional, there is nothing else holding the shape. So the protocols have to be real. They have to be written down, specific, and enforced the same way every time, for everyone. In other words they have to be treated like software. Good software is not bug-free because the team hoped for the best. It is bug-free because behavior is defined precisely, checked automatically, and corrected the moment it drifts. Behavior protocols for a company deserve the same standard. A rule that applies on Tuesday but not Friday, or to one person but not another, is a bug, and like any bug it is a small thing that produces large and unpredictable failures downstream. This is also where the discomfort lives, so it is worth being plain. A flat company has no managerial layer to quietly absorb someone who ignores the rules. Breaking a protocol is not a personnel matter to be smoothed over in a one-on-one. It is a structural fault in a system that has no other structure, and the system cannot carry it. This is not a democracy where every rule is up for a vote. It is a survival structure. The rules are the thing keeping a flat company alive, so respecting them is not a preference, it is the condition of belonging. Someone who will not operate by them is not a difficult teammate to be managed around. They are load the structure was never built to hold, and they do not last, because a flat company has nothing to hide them behind. This is closer to what Frederic Laloux calls a Teal organization in _Reinventing Organizations_: a company that behaves less like a chain of command and more like a living system, with a clear purpose and members who self-manage against shared, explicit rules rather than against a boss. ## What this looks like in practice We run Holdex this way, so the claim is not theoretical. [Our whole company runs on GitHub and AI agents](/insights/running-on-github-and-ai): contracts, onboarding, and HR records are markdown in version-controlled repositories, and agents execute the routine steps on top of them. The operating rules get the same treatment as the code. Instead of a long HR handbook that nobody rereads, each operational guideline is its own small, versioned file with a stable identifier, a stated problem, and a solution. Changing a rule means opening a pull request, so every rule has a history and a reason attached to it. Nothing changes by hallway consensus. We also organize those rules around the shape of the work rather than a filing cabinet. Every person, whether a partner or a team member, is an item moving through a lifecycle: joining, signing terms, getting set up, doing the work, being reviewed, and eventually moving on. Each rule is tagged to the stage where it applies, so the question "what governs this moment" has one answer instead of a search. None of this is bureaucracy. Bureaucracy is rules that exist to protect a hierarchy. This is the opposite move: rules precise enough that you do not need the hierarchy at all. You write the saw-sharpening down once, keep it as clean as you keep your codebase, and it does the work a layer of managers would otherwise have to do. The founders who will still be close to their teams at fifty people are the ones sharpening the saw at five.