I’ve argued before that a lot of top-down thinking is driven by a tendency to anthropomorphize complex systems or processes. If a system is hard to understand in its full complexity, people deal with it by thinking about it as if it’s a big person. In any essay he wrote last year, Paul Graham essentially argues that the management of large companies amounts to turning the style of thought I’ve been criticizing into an organizing principle:
[Small groups in large organizations] are always arranged in a tree structure. Your boss is the point where your group attaches to the tree. But when you use this trick for dividing a large group into smaller ones, something strange happens that I’ve never heard anyone mention explicitly. In the group one level up from yours, your boss represents your entire group. A group of 10 managers is not merely a group of 10 people working together in the usual way. It’s really a group of groups. Which means for a group of 10 managers to work together as if they were simply a group of 10 individuals, the group working for each manager would have to work as if they were a single person—the workers and manager would each share only one person’s worth of freedom between them.
In practice a group of people are never able to act as if they were one person. But in a large organization divided into groups in this way, the pressure is always in that direction. 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.
Anyone who’s worked for a large organization has felt this. You can feel the difference between working for a company with 100 employees and one with 10,000, even if your group has only 10 people.
How bad these problems are depends a lot on what your large organization is trying to do. If the organization is trying to do something routine, then limiting individual freedom might not matter too much. If you’re running an automobile assembly line, for example, you don’t necessarily want individual workers doing a ton of improvising, so a structure that constrains employee freedom might not be such a big deal. (Although even there you want your employees proactively looking for problems that might stop the assembly line) On the other hand, this kind of thing is absolutely deadly in a creative industry like software. The job of a computer programmer is to write software that’s never been written before (software that already exists can be copied, after all) so the process of software development can never be made routine like the steps of an assembly line. So limiting a programmer’s freedom is going to have a big, negative impact on his productivity.
Google’s management seems to understand this problem, and they’ve apparently adopted some interesting strategies for dealing with it. One is 20 percent time, the practice of allowing each programmer to spend one day a week working on a project that isn’t decided by the Google hierarchy—this leaves some room for bottom-up creativity within the company. Another approach Google has pursued is to make the hierarchy as flat as possible. Reportedly, Google gives each manager an absurd number of direct employees—on the order of 50—with the specific goal of making it impossible for bosses to micro-manage their employees.
Nevertheless, Google isn’t immune from the forces Graham is describing. I have friends who interned at Google at various points between 2004 and the present. From what they tell me, the character of the place has changed dramatically. As the firm grew by an order of magnitude, it was simply inevitable that the freedom experienced by individual employees would suffer. And it’s probably inevitable for Google to complete its transition into just another big company—following in the footsteps of Yahoo!, Netscape, and Microsoft before them. (Interestingly, Apple might be an exception; Steve Jobs has always run Apple like a dictatorship, so Apple employees may not have had any freedom to lose as the company grew.)
The practical consequence of growing companies is that increasing bureaucracy has a stifling and homogenizing effect. In a small company, an individual’s outstanding effort can make a big difference on the overall performance of the company, and senior management is likely to notice the contribution and reward it. In a large company, employees not only don’t have the freedom to do things that make a big difference for the company’s bottom line, but even if they did it’s unlikely they’d get the credit. As a consequence, the most talented programmers almost inevitably get a raw deal at large companies, because they’re neither as productive as they could be, nor are they fully rewarded for the level productivity they do achieve.
I spent about a year and a half as a bottom-of-the-rung engineer at GE, after being laid off from a fuel cell startup company. All of my relatives and friends saw it as a step up — GE obviously has resources that no other company has, upward mobility is a real possibility, and the job security was certainly better than my old job. I told them all that I would go back in a second to the financially insecure startup if given the chance.
The bureaucracy was suffocating. My job wasn’t to actually be an engineer, it was to set up meetings and keep track of what other engineers were doing. Original thought was not part of my job description, and it sucked. For me, the poor morale engendered by that sort of environment was at least as much a problem as simple organizational inefficiency.
“My job wasn’t to actually be an engineer,”
I think that why this is especially an issue for engineers and programmers — they see doing administrative and managerial things as a step down from their art. And I certainly agree with them! But I think in large % of other job positions, not having to do the daily drudgery of your job, but instead telling other people what to do is considered a promotion.
But definitely — absent any economies of scale, smaller is just flat out better than bigger.
“But I think in large % of other job positions, not having to do the daily drudgery of your job, but instead telling other people what to do is considered a promotion.”
That’s the thing, is that for us a promotion often means an end to our creativity. They say you get promoted to your level of incompetence meaning that if you were a good programmer who enjoyed coming up with effective and/or clever solutions that when you are promoted to management you stop getting to do that. Then you need a whole new skill-set and need to learn to enjoy the more abstract stuff (project planning, laying the framework for other programmers to actually solve the problem) and as much of an ego boost as that can be, it’s not always better to be in charge of people instead of in charge of the solution.
I’d much rather be a coordinator: I work along-side everyone else. I just happen to decide who does what, and if any design issues come up, deal with it by coordinating with those involved.
but instead telling other people what to do is considered a promotion
Hah, I suppose I should clarify and say that I certainly wasn’t telling anybody what to do. My job was to track the money-saving ideas that came from design engineers, which basically involved hounding a bunch of people who couldn’t care less about me or my job, and trying to get them to help me. A boss I wasn’t.
But I think I would feel very similarly to Akusu. I’ve never found the task of arranging tasks to be all that creatively fulfilling, although I know others enjoy it very much.
Made a small blog entry about this. Looks like we’re struggling with some of the same things!