How can startups possibly compete?
How is it possible for a small startup with no resources to compete with a well-funded mega-corporation? Why is it that startups seemingly out-innovate big companies at every turn? Why does everyone talk about big companies being slow and bureaucratic? Is there some fundamental reason why companies lose their efficiency and their ability to generate new ideas and products as they grow? Before I went to work at some larger companies these questions baffled me, but after some experience in industry I think they have some very reasonable and straightforward answers.
Why are big companies slow?
I won’t pretend to be an authority on these types of issues, but I can share my reasoning based on what I’ve seen in both large companies and my own startup. As far as I can tell, a lot of the issues stem from the pervasive notion that all companies must be monoliths that are “run” by a small group or even just one person. Indeed, when you look at how companies form it’s easy to see why this notion arises naturally.
The legal structure of a corporation encourages having an executive group and granting most of the power to the founders. This kind of structure is certainly reasonable at the very beginning, because the company is solely their work. However, as the company grows, the founders tend to want to maintain control over what they view as the company they’ve built.
I think that in most cases this desire to control the company is very well intentioned. However, it comes with a tradeoff. It requires that the company be organized into a hierarchy so that all employees are a small number of commands or “managers” away from the upper management. My hypothesis is that in creative domains (e.g. software services, game dev), it is this hierarchical structure that is at the root of substantial organizational inefficiencies. I’ve identified and named what I think are four of the main problems caused by hierarchical governance (at least in the realm of software development):
- The telephone problem
- The ownership problem
- The management = upward progress problem
- The single point of failure problem
I should note before I continue that these problems are not problems with managers themselves, but rather the hierarchical system of governance. I personally have worked with managers who have been truly excellent and I deeply admire their work and their skills.
The Telephone Problem
The telephone problem is an issue which, as far as I can tell arises in every hierarchical organization. The core of the issue is that, in any hierarchy, decisions are by definition made at “higher” levels. Any good decision requires two ingredients, a skilled decision maker and good information. The implicit assumption of every hierarchical organization is that the good decision makers are only at the top and therefore good information must be sent to them. The problem is that moving information up and down a hierarchy is the same as playing a game of telephone. Every person through which the info passes changes it slightly or misses out on important context. This is doubly true if technical information is being passed through a non-technical person and triply true if the person who is passing it along is incentivized to change or misrepresent it. Unfortunately, it’s all too often the case that delivering bad news is strongly disincentivized. No one wants to be the bearer of bad news if they’re going to be chewed out.
Consider this small concrete example. I was once given the directive to build a web dashboard at a previous job. I communicated to our manager that it was very important to know if there were going to be multiple dashboards in the future, so that I could design a slightly more general product for hosting the dashboards. He very clearly communicated that, no it would be the only one. However, it turns out that this engineering constraint was not communicated to his manager, because it didn’t seem relevant at this time. Sure enough just a couple weeks later the upper level manager, who was not aware of the trade-offs we made, decided we needed a platform for hosting dashboards. This miscommunication cost perhaps a week of dev time.
The miscommunication of the information is arguably not even the biggest problem with the telephone game, however. Moving complex information up and down has a time cost as well and it can be surprisingly expensive. For example, there have been projects that I’ve worked on where I’ve had to spend upwards of half my time in meetings with different levels of management explaining what I was doing and what the issues were that we were trying to solve.
I recall a coworker of mine explaining to management once that he could either spend his time explaining the details of a project or he could implement it, but not both. In another instance, I was asked to prepare a document every Tuesday and Thursday which explained what I was working on in the next two weeks and what I had done in the past two weeks, to keep management up to date. If you’re keeping track, that means I was reporting any given task eight times as it passed through the four week window.
If you throw away the implicit assumption that good decision makers are only at the top, then logically the people who are best equipped to make decisions are those who are closest to the information. In creative domains, this is often the people who actually have their hands dirty building products.
The Ownership Problem
I think the problem of ownership is the one that speaks to me the most. I’d like to break up the concept of ownership into two separate concepts:
- Responsibility
- Credit
Hierarchies, which are often organized by specialty (e.g. data scientist, artist) rather than by product, make it very difficult to know what “thing” a person is working on and what progress they have made. Similarly, they also make it difficult for an employee to be able to feel that they are making continuous progress on a well-defined product. This specialty-based structure seems to invite in all manner of inefficiency because it’s not clear who exactly is working on what. The sense of responsibility for creating a product that the creators “own” is lost. Frequently the solution is to create a separate “product manager” role whose purpose is ostensibly to manage a given product up and down the hierarchy. As far as I can tell, however, it just compounds the inefficiencies by adding yet another link in the game of telephone.
Everyone wants to get credit and compensation for their work. It’s what drives people to do the best work of their lives (I would argue the other driving factor is working with other talented/motivated people on something that’s bigger than what you could create yourself). Seeing someone else get credit for your work is no fun and yet it’s almost a built-in feature of hierarchies. This is because everyone towards the top of the hierarchy sees their organization primarily through their direct reports. The individual contributors (ICs) don’t have nearly as many opportunities to showcase their work to the top of the hierarchy. By contrast, a middle manager’s full-time job is to manage their relationships. In my experience, this leads to a situation where the managers are incentivized to downplay the contribution of the ICs and play up their own contribution. It’s a clear conflict of interest for managers when a particular talented ICs has the potential to replace them in their own job. As a result the best ICs have a choice of either working on the product or working to spend time with management to make sure they get the appropriate credit for their work. Since credit often determines compensation it’s incredibly important to assign it correctly, so that everyone can feel they are getting fair compensation for the work that they do.
Another interesting side aspect of hierarchies is that they give the power to determine team composition to a manager, not to the team as a group. From time to time, I’ve seen this lead to situations where teams are made up of one or two engineers who are pulling most of the weight of the team, but are unable to leave the team. This seems to happen in situations where the manager is not so technical and cannot easily determine who is contributing the most value to a project.
Unfortunately, I’ve seen absolutely excellent engineers, truly talented people, leave a company after being demoralized by this system for too long.
The Management = Upward Progress Problem
This, I think, is a well known issue of hierarchies. The problem here is that the only way to advance your career is to become a manager, not to improve the work that you do. Managers have an important role in hierarchies, but it’s good to remember that that’s all it is: just another role, not a superior one. The culture of credit, compensation, and prestige being a function of the number of people that work under you is exactly the type of thing that makes big companies inefficient.
Fundamentally a skilled engineer or a skilled designer is most useful when they’re writing software or designing products, not when they’re managing people. However, frequently the only way to get a higher salary is to “move up” to a managerial role within a company. Furthermore, the only way to get the authority to make decisions about what you’re working on is to manage people. Arguably someone with the skills to become a manager is also capable of making decisions from their IC role as well.
A salary can be a function of the employee’s performance and not their rank, and if they show initiative and good intuition for the products and the industry then simply they should be given access to the channels that would normally allow the managers to push for the implementation of something new. This of course would require high transparency in the company’s decision making process as well as the willingness to give the freedom to employees to take the initiative when it comes to developing new products.
The Single Point of Failure (SPOF) Problem
The problem with amplifying the impact of the decisions of just a few people through hierarchy is that their mistakes are also amplified proportionally. This can lead to enormous waste within a big company in a very short amount of time. Whereas a startup can fail fast and cheaply, every decision that upper management makes in a large company commits a vast amount of resources. I have seen upper management treat a large company like a giant startup where entire divisions are created to test out a new product or idea. This is the scale of waste that’s required for small startups to out maneuver well-funded enterprises.
Beyond just decisions and mistakes, attitudes, culture, and competence are projected also throughout the entire company via a hierarchy. Sometimes this can be desirable, but it also amplifies the flaws of the leaders. If the leader is non-technical the whole organization will struggle with technical problems. If the leader has bad taste, then the entire company will struggle with poor design. These are not things that can be easily delegated because knowing who to delegate these tasks to requires the same skills required to actually do the things. This is Paul Graham’s “design problem”.
Another interesting phenomenon is that a single incompetent manager (admittedly not very common) in a hierarchy can invalidate the work of everyone below them regardless of their merits or talent. This could happen by way of sending confused or conflicting directives down the hierarchy without a clear goal in mind. This type of thing is what causes talented employees, both managers and ICs a like to become disenchanted an leave. As they say, people leave managers, not companies.
Perhaps a flatter structure, in which teams manage their own well defined mini products, would provide an environment where teams can fail without hurting a larger portion of the company,
Why are startups fast?
If we just run back through the problems that result from big hierarchies we can see exactly why startups are faster and more efficient.
The telephone problem just does not exist in a small enough startup. A group of 9 people needs to maintain at most 36 total relationships and each person only needs to talk with at most 8 other people, no matter what they are working on. More importantly, the people who make the decisions are the people who are most intimately familiar with the product they are building and the users they have worked with.
When it comes to responsibility and attribution, it’s very very clear what the startup as a whole is working on because they can only afford to work on a single well defined product. Since everyone is working on the same product and the group is small enough, it makes sense for everyone to spend the time required to understand each other’s work. Furthermore, the members of a brand new startup are (presumably) all there by their own choice. They’re all people who know they can consistently work together and hopefully admire each other’s work. It makes sense then that credit and compensation is a consensus that they agree upon amongst themselves, rather than relying on a manager to choose for them. Beyond this agreement, they all sink or swim if the startup is able to sell a product (an achievement that can’t be faked, played down, or played up).
In a startup, career progress means getting the plane off of the ground. It has nothing to do with hierarchy. There are no managers so ICs can be comfortable knowing that the best career move for them is doing the best work of their lives.
It is true, however, that the SPOF problem still persists within a single startup. That’s unavoidable. A cofounder may decide to leave. Cofounders can have a falling out. The startup might just be dead wrong about the product or market. However, if we take a broader view of startups, we see that in reality the entire market of startups does not fail if one does. Y Combinator does not go bankrupt because of the poor decisions of a select few, rather they spread their risk out among many different enterprises.
Does big imply slow?
Certainly, the answer feels like of course; big always leads to more inefficiencies and clumsiness. Indeed, I speculate that this is in fact true for monolithic companies, but who said that companies must be monoliths? Given my observations above, I’ve come to wonder if there is a better way to organize large companies which reduces as much as possible the problems caused by hierarchies, while still maintaining an ability to act in a concerted way. The question that I pose is this: is there a middle ground between being a loosely affiliated collection of partially owned startups like Y Combinator and a monolithic organization like Facebook?
Unfortunately, I don’t know the answer to that question, but there are some encouraging signs. Supercell, in particular, has, in the games industry, pioneered a company culture and organization almost exactly in this same spirit. They have organized their company around the concept of independent “game teams”. These game teams are almost fully self sufficient startups, each with their own game designers, artists, and engineers.
Supercell’s CEO Ilkka Paananen has said that he would like to be the least powerful CEO. This sounds like an odd goal in a world where startup CEOs seemingly become deified by the media. However, in the context of game development, where quick iteration and testing of many ideas means you can find that next hit game, it’s brilliant. I think perhaps the next step on this adventure might be to formally incorporate this philosophy of “power to the employee” into the legal governance of the corporation itself. Maybe it could even be worked into the compensation model as well. We shall see.
