# Don't grow your org fast

*This is an essay in the spirit of Habryka's* [*Lightcone Principles*](https://www.lesswrong.com/s/cegJvyiP2dBkhDh2K)*. I'm not Habryka, but I have worked at Lightcone/LessWrong for a long time. The modeling of the pressures to grow fast in the second section comes from me. The models of the bad effects and reasons to stay smaller for longer are very much in the Lightcone philosophy soup.*

People like to grow their orgs, companies, startups, and teams. If there are funds and not outward pressures[^bomp3662gu], then there are job postings and recruiters, and when you turn away, look back, they've doubled in size.

The intuitive reason for growth is *that you can get more done.* There's so much to do! More people, more projects, more getting through the the to-do list! Further, if your org is new and small, you might [lack the skills to accomplish the mission,](https://www.lesswrong.com/posts/rSCxviHtiWrG5pudv/do-not-hand-off-what-you-cannot-pick-up) or even if you have one person with the skillset, others are bottlenecked on them.

Ok, but why is growth so bad?
=============================

Done right, it's not, but it always has costs. 

Let's start with some properties of a good organization: 

1.  The activities and resources of the organization cause the goals of the organization to be furthered, ideally efficiently and with limited wasted motion.
2.  People are on the same page about the values, methods, culture, goals, and strategies of the organization.
3.  Information flows freely between people, and people know what they ought to know (no left foot doesn't know what the right foot is doing)
4.  In particular, leadership/management knows what is going on and has visibility into the organization.
5.  Most employees can focus on delivering object-level value and aren't chewed up in management, coordination, office politics, etc.
6.  The organization is well-coordinated and nimble: if the situation changes, it's possible to redirect the organization's efforts to the new challenge.
7.  Members of the organization are in contact with reality, such as the object-level production or the macro state of the org's profitability, commitments, etc.
8.  Whenever you do grow, the new hire [raises the bar](https://www.aboutamazon.eu/news/working-at-amazon/what-is-a-bar-raiser-at-amazon#:~:text=A%20Bar%20Raiser%20is%20an%20interviewer%20at,process%20to%20be%20an%20objective%20third%20party.).

In case it's not immediately clear, I shall elaborate on how growth, particularly rapid growth, makes all of these harder. 

**Being in sync is valuable, or rather, not being in sync causes problems and waste.**

I'll decompose the value of being in sync into vertical and horizontal components. Vertically, leadership can make much better decisions about org strategy when they're in touch with everything that's going on beneath them. Too many people beneath and problems get missed, including problems that no one else is positioned to fix[^a2yuxcwf3qp]. Too much focus on managing, and the leader loses touch with their domain.

Even barring problems, as someone directing an org, you want people to understand your vision and models so they can independently execute against them. That's much easier if it's you and three others working in a room than if there's a suite of team leads when you and they are all too busy managing others to speak very often.

Horizontally, you also want in-syncness. It is not realistic that every message that ought to be passed between peers can be routed via management. Inkhaven is a multifaceted event (product?) where there are a lot of dependencies between the parts. I'm not one of the people running but I want to say it's taken less than six key people and that's been important for its success[^tw10ru0ykup]. 

+++ Case study of running Inkhaven

*I have not been part of running Inkhaven, though I have been observing from the sidelines. This is me speculating.*

Let's imagine that the work had been split up among many more than the "six". That instead, you had 0.5-1 people for each of: designing the program, marketing it, vetting applications, seeking sponsorships, recruiting and managing coaches, arranging guest speakers and contributing writers, setting up Lighthaven, ensuring that participants' needs and wants are met, and so on.

There's really a huge amount of work and those involved have been pretty overworked, but I think if you tried to split up the work more, separate from cost, is it would get very hard to coordinate. It definitely would have made the product development clunkier and harder to refine.

For example, most of the functions I listed depend on the design and vision of the program. Theoretically, that could be figured out up front and locked in at the start. Then the applications person knows who to accept, the marketer knows what to market, the sponsorship person knows what perks sponsors could receive, and so on. Yet that locks in the vision with the friction that updating everyone would entail.

Because it was Ben and a few others running it, the design could evolve, and decisions could change without being extremely onerous to update everyone. I would guess that if you doubled the people in the project, there'd be a lot more cross-purposes, failed to receive the memo, clash of personalities, wasted motion, and so on.




+++

My impression is that four people who spend a lot of time together, e.g., initial founders, can actually get on the same page, share models, and debate. At five to seven/eight, you can still kind of have a meeting with everyone but it sucks a bit. By ten or twelve, you need to split, and you are beyond the point where you can have a single meeting that lets everyone participate. Your entity can no longer talk fully with itself. Proceed further, and middle management becomes necessary with all its many costs.

The losses at each stage may eventually be worth it, but know that something valuable is being lost. The ability to share models. The ability to build justified trust. To establish culture and values. When you are small is when it's possible to do that, and each marginal hire, even if they're very good, will make it harder.

**You want to retain the ability to pivot as long as possible.**

At least if you're doing anything with high uncertainty, e.g., a startup or an organization trying to build infrastructure to help humanity survive an especially critical century.

LessWrong 2.0 was launched in 2017-2018. Several years in, after pretty good success, Habryka concluded that the online was no longer the bottleneck for community infrastructure. He determined it was necessary to get into in-person stuff. His team of 5 or 6 (I forget) was on board with this, and all but one volunteer (me) pivoted to the in-person quest. Lighthaven is the spoils of that transition. Nimble. Responsive to the needs. I would guess that if you had an organization of 40 engineers, perhaps only 20, and then you decided that the priority strategy involved designing rooms and managing contractors, you would not be able to get them to pivot. You'd maybe need to fire them and hire others, which is probably so impractical that you just stick to what you know.

But in general, the larger your org is, the more you are stuck doing whatever you started doing. Since you are operating in an uncertain domain, there's a good chance you picked your original direction wrong, and by growing, you have made it hard to fix that.

Also, the larger an org you have, the less time you, the CEO, will have for reflecting on whether your org is even taking the right tack at all.

**Management is costly, if not risky.**

Value created by an org has to flow to the object-level work completed. Management is a cost, and in a magical ideal org, all effort could be allocated to productive object-level work. Alas, in the real world, coordination and direction have to happen.

At Lightcone, we have approximately flat leadership where Habryka is the manager of almost everyone on the core team, and we're always trying to prevent anyone else from acquiring management burden. This is true of the core team. This hasn't always been true, and we've experimented with greater middle management. The advantage is multifold: others are spared the distraction of management and Habryka stays in touch with everything going. (The major cost, however, is Habryka's ability to do other things and the chances that he becomes a bottleneck on work.)

Management mixed with object-level work is very costly to productivity on the object-level work. Management without object-level work is not good for the soul. [Do not hand off what you cannot pick up](https://www.lesswrong.com/posts/rSCxviHtiWrG5pudv/do-not-hand-off-what-you-cannot-pick-up), and even if you once could do the work, you can get out of touch with it.

Worse than all that is [Recursive Middle Manager Hell,](https://www.lesswrong.com/posts/pHfPvb4JMhGDr4B7n/recursive-middle-manager-hell) where middle management can get disconnected from concrete reality. See the linked article or the collapsed quote below for more details.

+++ Key quote from Recursive Middle Manager Hell

> Say you have a two-layer company, a CEO and a widgetmaker. The CEO is directly in contact with reality – his company either is profitable or not. He can make choices about high-level-widgetmaking strategy, and see those choices play out in customers that buy his product. 
> 
> The widgetmaker is also in direct contact with reality – he's got widgets to make. He can see them getting built. He can run into problems with widget-production, see that widgets are no longer getting made, or getting made worse. And then he can fix those problems.
> 
> Add one middle manager into the mix.
> 
> The middle manager is neither directly involved with widget-production, or the direct consequences of high-level widget strategy. Their feedback loop with reality is weaker. But, they do directly interact with the CEO, and the widgetmakers. So they get exposed to the object level problems of widget-making and company-profit-maximizing.
> 
> Hire a lot of widgetmakers, such that you need two middle managers. Now, the middle managers start talking to each other, and forming their own culture. 
> 
> Scale the company enough that you need two *layers* of middle-managers. Now there's an upper layer who reports to the CEO, but the things they reports about are "what did the lower-middle-managers tell me?". The lower layer talks directly to the widgetmakers, and reports down what they hear about high level strategy from upper management.
> 
> Lower middle management wants promotions and raises. Upper management isn't directly involved with the process of widgetmaking, so they only have rough proxies to go on. Management begins constructing a culture about *legible signals of progress,* which begin to get [goodharted in various ways](https://www.lesswrong.com/posts/EbFABnst8LsidYs5Y/goodhart-taxonomy). 




+++

**Hiring too quickly risks hiring the wrong people and/or failing to integrate them well.**

The downside risk of a bad employee is asymmetrically higher than the upside of a good hire. Bad hires can do any of the following: low-quality work, degradation of your culture, demoralization of others, normalization of bad behaviors/vices, erosion of trust, creation of drama, and a lot of distraction from your org's actual priorities. 

Blatantly bad employees, at least, can you force your hand to deal with, though probably still with great stress and attention, as firing is rarely easy (there are so many reports of people regretting that they took so long to do it). But employees who are not *that* bad but still bad stick around, eroding things, have made more friends who want to protect them, and dangerously can end up involved in subsequent hiring. If you're leading a large enough org, you might not even have enough attention to notice.

Even with a good employee, if you're a good org, you'll have built up a good culture that's not universal and takes time to inculcate. [Lightcone has its principles](https://www.lesswrong.com/s/cegJvyiP2dBkhDh2K). In recent memory, we had something like a site outage traced to a decision made by a trial candidate signed off by a relatively newer team member who was missing one of our core philosophies.

If you grow fast, you make it harder to maintain a detailed common culture and shared values. Especially if you start to have not-yet-sufficiently onboarded employees, start hiring and training the next round.

This really matters if you believe, like I do, that the default organizational culture is pretty bad and is making a lot of mistakes that undermine effectiveness, especially at hard and uncertain goals. It's pushing against gravity, and if you keep adding people.

**Hiring is expensive (time and money), and there's other stuff worth focusing on**

I opened this post with the standard justification for hiring: that there's so much to do and we need more people. Namely, the productivity justification.

But there are multiple non-hiring ways to get more done, and more of the right stuff done. Things like [improving communication](https://www.lesswrong.com/s/cegJvyiP2dBkhDh2K/p/FM7tWezTknbcTinu9) in the org, [questioning requirements](https://www.lesswrong.com/s/cegJvyiP2dBkhDh2K/p/BECDxh5jKjcmxs7hw),  [improving decisions](https://www.lesswrong.com/s/cegJvyiP2dBkhDh2K/p/sdvBcPSR7p5mKhB7b), [removing bottlenecks](https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592) in the org, [closing loops](https://www.lesswrong.com/s/cegJvyiP2dBkhDh2K/p/Shfziga3BdCi2L5D6), increasing the [skill and capability range](https://www.lesswrong.com/s/cegJvyiP2dBkhDh2K/p/rSCxviHtiWrG5pudv) of existing employees (someone learns design rather than hiring a designer)

For what it's worth, I think people often focus too much on "how to get more of what you're currently doing done" and not enough on "how to get better at figuring out what you should be doing" ([rowing vs steering](https://www.cold-takes.com/rowing-steering-anchoring-equity-mutiny/) in Karnofsky language). It's harder to accomplish the latter with hiring, and what's worse, is that hiring makes it harder to change your strategy, both because you have less time to think about strategy and because you've all these additional people to point in a different direction.

So why then do people do it?
============================

*This section is more speculative compared to the previous one.*

Yet, looking at the orgs and teams around me, the pace of hiring feels like it exceeds the motivation of trying to get more done or hire for skills not yet possessed within the team. My guess is that people are further driven to hire/expand/grow/scale for some further reasons.

First, the number of people is a natural indicator of success. Intuitively, a company with 1000 people is a bigger deal than a company with 100. And I'd guess that "units of people" is a more natural, intuitive, and universal metric for comparison than any other units of production. 1000 people has a concreteness to it that $10m annual recurring revenue or a million widgets shipped does not.

At the individual level, someone who leads a team of 10 people feels more important than someone who manages only 2 or even less impressively is just an individual contributor[^q4s9rjgkdco]. Status is very social; it makes sense if it gets tied to *how many people take orders from you*. Being a larger organization also opens up the door for more impressive titles like VP of Engineering, Engineering Lead, etc. Larger teams justify larger budgets, which is also an easily stateable metric of progress[^nqvp78til8p].

Speaking of budgets, seniority, as indicated by position within a hierarchy, is perhaps the most allowable justification that someone should get paid more than others. Our society would prefer to be perfectly egalitarian, and that means everyone is equally valuable and should get paid the same (that's fair). That someone has more formal qualifications is a little a bit a justification for greater pay. It's a much better reason if they're more in charge. It's almost an expectation that the manager gets paid more.

So if you'd like to eventually have more prestige and power, or if you have it yourself but want to offer it to others as an incentive, then it's important that you continue to grow.

The dynamics I describe here match what Scott Alexander hypothesized regarding subcultures:

> Status within a subculture is zero-sum. You can’t make everyone high-status at the same time. But you can have everyone at time T reasonably expect to be high status at time T+1, after a bunch of new people have joined and the older generation has become Wise Elders and Founding Heroes. - [Scott Alexander, A Cyclic Theory of Subcultures](https://www.astralcodexten.com/p/a-cyclic-theory-of-subcultures)

Replace "subculture" with "organization" and it is much what I am describing above.

What do?
========

The message is not that you should never grow, but that if you're aiming to do anything at all hard and uncertain[^xt7c19he14f], you should probably aim to grow your team more slowly than many people do. 

Focus on getting existing team members to be as productive as possible. Focus on building solid culture, processes, and especially communication within the org. Try to reduce key uncertainties about your strategies before hiring in ways that will reduce your flexibility.

When you go to hire, be cognizant of the costs and everything that gets harder when you do. Think about whether there are ways to get more done with the current team. When you do hire, work to get new employees properly integrated, especially before they get involved in hiring themselves.

[^bomp3662gu]: With a large company like Meta or something, I can imagine groups and teams would still like to grow but upper management decides on a down-sizing strategy. 

[^a2yuxcwf3qp]: To tell a story, suppose you're the CTO and you have a new engineering manager underneath you who is a mix of incompetent and vindictive.  This manager won't inform you of the personnel issue here, and the reports unlikely to reach out if the CTO feels inaccessible and the manager is vindictive. It could perhaps be surfaced with skip-level 1-1s. This can happen if the CTO manages two middle managers. What if there are six? 

[^tw10ru0ykup]: Instead Ben has been reaping the increasing returns to effort. Let me guess at it though: Ben ultimately directing it, lots of input from Habryka, Ronny interfacing a lot as its an event on campus. Did Ray get pulled in to make the website? Lucie? Oli?  Lucie is definitely a key person. Justis might be operating as head coach, maybe? Hannah is now fulltime ops on stuff. 

[^lnn400gf14]: This is the current size of the Lightcone core team. 

[^q4s9rjgkdco]: The only way for this to not be true is if some individuals are much more productive and valuable than others, but this conflicts with egalitarian ideals, cf. the next paragraph. 

[^nqvp78til8p]: Really how much you spend should be held against you (a cost), but in fact people are impressed by how much many you raised, etc. 

[^xt7c19he14f]: Things that not hard and uncertain: taking over running a restaurant or bakery that's been operating successfully for 5 years, running a soup kitchen. Things that are hard and uncertain: any kind of tech startup, any kind of non-profit with a large distant goal (e.g. prevent AI going badly).