Doing things that don't scale isn't a startup hack. It's a leadership principle.

An operational reading of Paul Graham's essay: the manager who only does what scales never understands what they command. And ends up managing a simplified version of reality.

Paul Graham wrote about why founders should do things that don't scale early on — recruit users manually, provide support personally, treat each customer as if they were the only one. The original argument is about startups. But the principle has a management version that rarely gets discussed: the manager who delegates everything that doesn't scale from day one never develops the understanding that makes delegation valid. You can't delegate well what you don't understand in detail. And you don't understand in detail what you've never done closely enough to feel where it breaks.

In larger companies, this dynamic shows up as distance between those who decide and those who execute. The manager who processes reality only through reports develops a filtered mental model — they see what reports can capture, which is always an impoverished version of what's actually happening. Direct contact with real work — with the dissatisfied customer, with the process that breaks at the wrong point, with the rule nobody can explain why it still exists — is what calibrates judgment. Without it, you're managing an abstraction. The abstraction looks stable. The reality underneath it often isn't.

This doesn't mean managers should do operational work indefinitely. It means the ability to do it is what legitimizes the authority not to. There's a difference between the manager who delegated because they understand enough to trust the judgment of the person executing, and the manager who delegated because they never wanted to understand. The first creates systems. The second creates dependency on specific people and distance between intention and result. Doing things that don't scale is the entry price for managing with credibility what will eventually scale.

Leo Bentier