“A group of 10 people within a large organization is a kind of fake tribe. The number of people you interact with is about right. But something is missing: individual initiative.”
- Paul Graham

Paul Graham on the anthropology of big companies versus small companies:

What’s so unnatural about working for a big company? The root of the problem is that humans weren’t meant to work in such large groups.

Another thing you notice when you see animals in the wild is that each species thrives in groups of a certain size. A herd of impalas might have 100 adults; baboons maybe 20; lions rarely 10. Humans also seem designed to work in groups, and what I’ve read about hunter-gatherers accords with research on organizations and my own experience to suggest roughly what the ideal size is: groups of 8 work well; by 20 they’re getting hard to manage; and a group of 50 is really unwieldy.

Whatever the upper limit is, we are clearly not meant to work in groups of several hundred. And yet — for reasons having more to do with technology than human nature — a great many people work for companies with hundreds or thousands of employees.

Companies know groups that large wouldn’t work, so they divide themselves into units small enough to work together.

… Each group tries its best to work as if it were the small group of individuals that humans were designed to work in. That was the point of creating it. And when you propagate that constraint, the result is that each person gets freedom of action in inverse proportion to the size of the entire tree.

… A group of 10 people within a large organization is a kind of fake tribe. The number of people you interact with is about right. But something is missing: individual initiative. Tribes of hunter-gatherers have more freedom. The leaders have a little more power than other members of the tribe, but they don’t generally tell them what to do and when the way a boss can.

… The restrictiveness of big company jobs is particularly hard on programmers, because the essence of programming is to build new things. Sales people make much the same pitches every day; support people answer much the same questions; but once you’ve written a piece of code you don’t need to write it again. So a programmer working as programmers are meant to is always making new things. And when you’re part of an organization whose structure gives each person freedom in inverse proportion to the size of the tree, you’re going to face resistance when you do something new.

… Working for oneself, or at least for a small group, is the natural way for programmers to live. Founders arriving at Y Combinator often have the downtrodden air of refugees. Three months later they’re transformed: they have so much more confidence that they seem as if they’ve grown several inches taller. Strange as this sounds, they seem both more worried and happier at the same time. Which is exactly how I’d describe the way lions seem in the wild.

- Paul Graham, March 2008: Link.

Via NewsVine: Link.

The evolution of trickster stories among the dogs of North Park after the Change

Short fiction by Kij Johnson. Excerpt:

6. One Dog Invents Death.

This is the same dog. She lives in a nice house with people. They do not let her run outside a fence and they did things to her so that she can’t have puppies, but they feed her well and are kind, and they rub places on her back that she can’t reach.

At this time, there is no death for dogs, they live forever. After a while, One Dog becomes bored with her fence and her food and even the people’s pats. But she can’t convince the people to allow her outside the fence.

“There should be death,” she decides. “Then there will be no need for boredom.”

- Kij Johnson: Link.

Via Futurismic.

Interesting idea, nicely realized. The story is a finalist for the 2007 Nebula Award — best wishes Kij!

Reminiscent of The Author of the Acacia Seeds
And Other Extracts from the Journal of the Association of Therolinguistics by Ursula LeGuin, as well as Our Neural Chernobyl by Bruce Sterling.

Here’s a story I like to tell:

I started programming when I was fifteen. (Actually, I wrote my very first BASIC program when I was ten years old, but that’s another story.) I’m now forty-six, so you can see I have some experience. Anyway, when I was fifteen, my dad taught me the rudiments of structured programming. He was a programmer himself, for the Star-Tribune.

Something he said has always stuck with me. He said, what usually happens is this: Management issues some directives; the programmers fulfill the directives; the end users try to use the programs — and things go wrong because the end users were never consulted about what kind of tools they need to do their jobs.

The successful programmer, dad said, is the one who first goes and sits down with the end users, talks to them about their jobs, finds out what they really need — then integrates this knowledge with Management directives. He called this “going native” (before he was a programmer, he took his degree in anthropology).

I’ve always taken this to heart, and in this sense, I’ve got something like thirty years experience in good interface design. Of course, I don’t actually say this on my resume, it’s kind of silly. But it’s a great story, and I think it illustrates the approach I take to my work.

- Karl Jones