Process vs Bureaucracy

Process as the thing that prevents bureaucracy

Ryan Petersen describes spending his first eleven years as an entrepreneur treating process as "corporate" and wanting nothing to do with it, then reversing at scale. His conclusion is that "hatred of bureaucracy is not enough to keep bureaucracy away," and that a company gets more bureaucracy from having no process, policies, or standards than from having too much.¹ He frames the goal as staying on the line "at the edge between order and chaos," a balance that is never finished because a growing company is always changing. A company can tip into too many approvals and services just as easily as into having none, so the calibration is permanent work rather than a one-time setup. Garry Tan, interviewing him, adds a stage map to the same claim: founders moving from Series A to B often die from too little process, dismissing it as "corporate," while founders moving from B to C or C to D can die from too much, building a culture of rule-followers who cannot add anything new.¹

The counterpoint: design the environment, do not write the rule

Tobias Lütke offers a sharp alternative. Rather than calibrating how much process to write, he questions whether to write any at all, calling the reflexive impulse to document rules "corporate babyproofing."² His argument is that a policy is downside protection: it puts a floor under how badly things can go while also putting a ceiling on how well the best people can perform, because a rule that stops a mediocre employee from erring also constrains an excellent one from doing something better than the rule imagined.

His alternatives to policy, as he describes them, are to design the environment so the right behavior is intuitive, to hire people whose instincts do not need constraining, and to treat bad affordances as a design error to fix rather than a rule to post: a door with a pull handle that you are supposed to push, in his example, should be redesigned, not signposted.² His further example is Shopify's office pods, sized so that five people sit comfortably and a seventh is uncomfortable, which he says produces a team size of five without any written rule. He adds a related caution he calls the cheat-sheet trap: when you write down exactly what you are looking for, the people who find and study the list are precisely the optimizers you do not want, so "actively avoiding to write something down is sometimes the most important thing you can possibly do."²

Petersen and Lütke are not framed as contradictory. Petersen's claim is that some process is necessary for coordination at scale, absent which informal bureaucracy fills the void. Lütke's claim is that the process should be environmental and systemic rather than written and rule-based. The stated goal is the same, and the difference is the mechanism.

A third voice on the same axis

Eric Glyman frames the same order-versus-chaos choice as Amazon versus Google, a debate he says Ramp had at around forty to fifty people.³ He characterizes the Amazon model as a rainforest of redundant, competing tools and teams that move fast, and the Google model as a cathedral of centralized decisions and enforced norms. For a startup he describes as "wrong a lot all the time," he picks the Amazon posture because high-velocity learning beats multi-year bets, but he pairs it with what he calls "antibodies," internal quality mechanisms that "sweep the streets" without stopping production.³ The structural implementation he names is Single-Threaded Teams, small vertical teams supported by horizontal service orgs. This lands on the same resolution as the other two, tolerating some redundancy at the edges and then pruning it, and it sits alongside Standards Over Rules as Glyman's account of how a fast company stays high-quality.

Open questions

The order-and-chaos line is described as impossible to locate in advance, knowable only after drift has already happened, which leaves the detection problem unresolved. Lütke's environment-design approach also depends on the environment being designable through office layout, org structure, and compensation, and it is not settled at what scale complexity exceeds what designed environments can hold, forcing a return to written policy.