Paul Graham was once asked the following RAQ (rarely asked question):
How can I avoid turning into a pointy-haired boss?
His answer:
The pointy-haired boss is a manager who doesn't program. So the surest way to avoid becoming him is to stay a programmer. What tempts programmers to become managers are companies where the only way to advance is to go into management. So avoid such companies and work for (or start) startups.
Why be a manager when you could be a founder or early employee at a startup?
Why?! Oh wow. I could fill a book explaining why. But many of my reasons are my own, and aren't relevant to you unless you're much like me. So I'll focus on the general answer to the question implied by Paul Graham:ย Why do large firms exist?
The question was addressed by the economist Ronald Coase in his article "The Nature of the Firm". This article, together with his work on externalities (the Coase Theorem), earned him a Nobel Prize in economics. This is one evidence that the question is interesting and far from trivial.
Suppose there are no good answers to Paul Graham's rhetorical question. That is, it's alwaysย objectively better to start or join a small firm than to be a manager in a large one. You'll always get more work done, or will be more satisfied, or both. Well, if so, competition should eventually drive large firms out of business. So why are they still around?
For starters, clearly there are problems best solved by small groups of people armed with off-the-shelf tools. For instance, two iconic YC startups funded by Paul Graham, Reddit and Dropbox, each solve a problem with the help of a few programmers and a bunch of commodity servers running a commodity software stack. A larger company could hardly improve on what they do.
Note that off-the-shelf products are key to being small (or at least starting small). Reddit or Dropbox could never build those servers from scratch. A small group of people can not erect a $5G chip fabrication facility. Building and operating a fab โ or a search engine โ requires lots of custom development, so you need a lot of people.
Or do you?
Of course the total number of people involved has to be very large. But it doesn't follow that they should be organized as big companies. Instead, the work could be done by many small organizations, each contracting out most of the work to others.
You're big because you hire. Why hire if you canย buy, contract out โ and stay small?
Indeed, this seems to make perfect sense. To quote Wikipedia's summary of The Nature of the Firm (1937):
The traditional economic theory of the time suggested that, because the market is "efficient" (that is, those who are best at providing each good or service most cheaply are already doing so), it should always be cheaper to contract out than to hire.
Then why do most people prefer employment to self-employment, as evidenced by their actions (and an economist never trusts anything but actions as a tool to reveal someone's preferences)? Why do I hate the idea of running a small firm?
Either the "traditional economic theory" is right โ one should run a small firm, and I'm a freak of nature destined to extinction due to economic evolutionary pressure, together with much of the population โ or the theory is lacking, and there should be a concept formalizing my aversion to self-employment.
And in fact, at this point, Coase introduces the term โ transaction costs:
Coase noted, however, that there are a number of transaction costs to using the market; the cost of obtaining a good or service via the market is actually more than just the price of the good.
Oh, yeah โ MUCH more if you ask me.
Other costs, including search and information costs, bargaining costs, keeping trade secrets, and policing and enforcement costs, can all potentially add to the cost of procuring something via the market.
YES! Here's a Nobel Prize-winning economist from the notoriously "pro-free market" Chicago school that UNDERSTANDS ME. He knows why I hate markets. ("Pro-market" doesn't mean you love markets, just that you think governments are even worse.)
This suggests that firms will arise when they can arrange to produce what they need internally and somehow avoid these costs.
Avoiding these costs can enable work that just can't happen outside the context of a big company.
For instance,ย I work on chips for embedded computer vision, at a company that's now fairly large. This is an example where a lot of people need to cooperate in a custom development effort (as opposed to fewer people using off-the-shelf products).
In theory, I could start a computer vision hardware startup instead of it being an internal project. In practice, it wouldn't work, because:
- I wouldn't know what to build. Hardware accelerates algorithms โ what algorithms? I only know because I'm in the same company with developers of very effective unpublished algorithms. Without that knowledge, what could I build โ an OpenCV accelerator? Good luck selling that.
- I couldn't build it nearly as efficiently. A great source of efficiency is fitting hardware to the specific workload. But if we were not a part of the company but a vendor, the company would make sure there are competing vendors to keep prices low. This means that we, no longer having a guaranteed customer, wouldย have to support as many different workloads as possible, to increase the pool of potential customers. As a rule, more generic hardware is less efficient.
- I couldn't explain how to program it. Once you gave away your programming model to the customer โ as you have to if you want them to, well, program you processors โ only very strong patents can prevent them from cloning your hardware (possibly with the help of your competitor). A big company that, among other things, designs its own hardware doesn't have to explain it to the outside world. And even if its hardware ends up cloned โ it's just one part of the secret knowledge behind the product. But if you're a small company only making hardware and it's cloned, you're busted. You shouldn't even start before making sure your ideas are "sufficiently patentable" โ which you don't know before you developed those ideas.
Of course, the number one real reason I couldn't run a hardware startup is that I'm no businessman. But the problems above are also very real, and frequently insurmountable for people who can do business. Not all custom development is impossible to successfully outsource, but much is. The problems result from economic fundamentals.
In econ-speak, such problems are collectively known as "search and information costs, bargaining costs, keeping trade secrets, and policing and enforcement costs". Indeed, all these problems were featured in my example. In plain English, a simple way to sum up all those problems is trust โ or more precisely, the lack thereof:
- A company can't trust a vendor, so a vendor can't know its algorithms.
- A company can't trust a vendor to keep qaulity high and prices low if it guarantees to remain its customer...
- ...So a vendor can't trust a company to remain its customer, so it can't invest too much in a solution just to that company's specific needs.
- A vendor can't trust a company to keep buying from it if enough knowledge is given away so that the product can be cloned instead โ so some products are not worth building.
When you work for a big company, you deal with coworkers, and you're all playing for the same team. The smaller the company, the more you deal with customers and vendors, which means playing against them. There's no such word as "co-customer" or "co-vendor" for a good reason.
At least that's how things are framed by the rules. The rules say that all employees are agents acting towards a common goal, "to promote the company's interests" โ whereas different companies have different bottom lines and different interests.
Of course, reality is never like the rules โ in reality, everyone in the company plays by their own rules, attempting to promote the interest of any of the following โ or a combination:
- Shareholders
- Customers
- Employees
- His team
- His manager
- His friends
- Himself
So in reality, of course there's a lot of chaos in a big company. And it doesn't help that the bigger it is, the harder it is to make sense of what's going on:
...There is a natural limit to what can be produced internally, however. Coase notices "decreasing returns to the entrepreneur function", including increasing overhead costs and increasing propensity for an overwhelmed manager to make mistakes in resource allocation. This is a countervailing cost to the use of the firm.
...Which explains why we aren't all employed by a single all-encompassing huge company.
But at least the rules of a large company frame things right โ as cooperation more than competition. (Competition generally isn't an end โ it's a means to ultimately force people to cooperate, and, as Coase points out, it only gets you this far.)
Of course, corporate rules also create competition โ employees compete for raises, etc. But in practice, overall most would agree that it's much safer to trust co-workers than customers or vendors.
Why be a manager when you could be a founder or early employee at a startup? Here's the part of my answer that is based on economic fundamentals.
I specialize in areas requiring custom development by many people. Many people can only tightly cooperate under rules implying trust. Therefore they must not be customers and vendors, but coworkers, which leads to large firms.ย Such is The Nature of the Firm.
Of course there are problems that can be solved by a small group of people with mutual trust, without tightly-coupled, joint development with others โ for example, the problems solved by Reddit and Dropbox. One reason I personally never looked that way is my aversion to business. Such is my own nature.
It just so happens that the nature of the firm suits my nature nicely โ because there are situations where big companies are a good idea. When you can't buy and have to build, trust is fundamental to getting the job done.
UPDATE (December 9, 2011): just found an interesting analogy between company size and program size. Doing many things in one big program can be easier than using many small programs because of "transaction costs" โ the cost of exchanging data between the programs.