Why successful startups stumble at 40 employees
thinkgrowth.org
thinkgrowth.org
Reddit plans to expand to 300 employees by the end of the year from its current 230. That's already up from the 140 the company had at the beginning of 2017.
Huffman declined to share revenue numbers, and the company is not profitable.
https://www.bizjournals.com/bizwomen/news/latest-news/2017/0...
Don't know how accurate this is, but Twitter is at 3500 employees now, down from 3900.
https://www.statista.com/statistics/272140/employees-of-twit...
There's something fundamentally wrong with the way the industry builds products.
The question is how many people are actually needed to keep the lights on. One person can read the latest CERT notices every day and decide "we need to upgrade our servers before we are hacked", but from there the upgrade can get hard: how many people are needed to to stage and test the upgrade. How many people are needed to keep the servers running? How many people are needed to ensure that twitter doesn't become a has been unable to keep up with their competition (who presumably is adding new features all the time)?
The above is a complex question. I don't know the answers, so while I lean to agree with those thinking twitter should cut people until they are profitable I can never be entirely sure. Even if twitter took my advice and it worked out I can't be entirely sure their current path (too many people) wouldn't be better in the long term. Or alternatively if they continue on the current path I cannot be sure if cutting people would have been better.
Google has 72k employees, Facebook has 17k. What exactly do _they_ all do?
Google made money almost from the start I think.
Reddit has been losing money since its inception.
Google and Facebook both have massive, globally spread datacenters. Staffing them and ensuring they're built out, maintained and operated alone requires loads of personnel.
Then you got the massive user count: Facebook with Instagram and Whatsapp has likely over 2B users, and Google most likely the same order of magnitude.
All these users must be supported - both Google and FB do their best to provide as low-quality support as they can get along with, but by law they're bound to quickly react to copyright violation and child porn; in addition Google has (via Google Apps for Enterprise, GCE, AdSense etc) a number of projects with companies - and companies who pay your company generally expect competent support.
Add in all the "low paying" jobs, if they're not already outsourced... like cantinas, cleaning, facility management - and for FB, Google, Amazon and Apple at least a strong architecture and legal team.
Digg and reddit are fairly niche, at least for advertisers - which means these sites need far less ad salespeople and support staff; reddit also can get by with having next to zero visible support staff by relying on community moderators which cost them nothing.
The same kind of thing is true with companies. In order to hire X more employees who "do actual stuff" you need to hire X * Y% more other employees to support and manage those do-ers, which, themselves need X * Y% * Z% more other other employees to support and manage them. Suddenly you have Digg with 300 employees. That's kind of how it happens. I don't think there is such a thing as a medium-to-large company with just "do-ers" sitting there doing things without support staff like project managers and HR personnel
(not to say these people don't do things, just not in the sense of directly making products, which is the root of the "what do all these employees do?" question)
You may point to Google.
But they are what in UK financial regulation speak, is called a Systematic Internaliser. They operate a two way market without substantial open interest not provided except internally from client order flows executed according to their own instruction interpretations.
Some companies just can't grow even while hiring a ton of people.
And to answer your question, the 900 people at twitter are doing sales, community work, support, etc, etc. That stuff balloons fast.
"You need to hire more/better people" is just the standard response to almost any problem.
[Time and Motion Study..]
.. is a major part of scientific management"
https://en.m.wikipedia.org/wiki/Matrix_management
It's obvious that the task has to be able to be subdivided suitably, but not enough is said about Matrix Management, especially when the cost of parallel business development is considered, in seeking increasing speed of execution.
Population size responds to circumstances almost immediately because birth is so well parallelized. You can have any number of women produce one baby each all in the same 40-week period. If you put any significant number of women on the problem, you'll get noticeably more than one baby each. And you can increase the litter size pretty dramatically beyond that -- how many months did it take Octomom to produce one baby?
For example, if I'm in build mold, I may scale my non-engineering organization as: - Each salesperson I hire a million dollar quota - Every 2 need a Sales Development Rep - Every 2 need a Sales Engineer - To generate pipeline for them, I need X dollars of marketing spend per salesperson (scales linear) and this will require a marketing department of Y people. - Every $2 million in revenue requires a support person - Management is 1 employee out of 5 - Every $2 million in revenue requires engineering support overhead of another body. - Every X employees requires an additional head in Finance and HR.
These #s are all made up, but it's a way of thinking why people use headcount as a proxy for revenue, especially when revenue #s are private.
This is much less true in consumer focused companies, or resellers.
This is where it bothers me. Startups start out by taking a share of the enterprise companies lunch by doing things that enterprise companies can't because of the structures they built.
At some point when startups get successful they flip a switch a switch and try to become more enterprisy. They might get a "real" CEO, one of the big performance metrics becomes by how many hundred people you can grow the company per year and at some point if they make this transition successfully the company will start to stagnate. Back in the days when I went to some Erlang user group I was complaining about how I could solve a problem and rather than solving the problem the guy wanted to grow the engineering team to 20 people(from 5) some government contractor said that I don't get how the system works. You think that solving the problem is the key performance metric, but the actual metric is how many people the manager manages.
One of the comments I saw below is true though. They grow the numbers and then they don't have proper management to fill the gaps. But what's proper management to begin with?
If they "invest" in their people they will promote their earliest employees to director of xyz. Congrats, now some random crappy junior javascript developer is now your Director of Engineering and it will be legitimized by the $10000 Leadership 1 weekend course he got at Stanford. He will do 1 on 1s with you and try to talk about your future.
But here's the problem though. Where do you get good management? Anecdotal evidence, I once sat at a dinner table and next to me was some old school business guy with his friend, a senior management guy at another company who recently got fired, saying that the worst thing you can do is hire middle management that is weaker than you. He will always try to keep the lower tier below himself. I'm supposedly in a leadership position in my company, yet the thing that no one ever wants to hear in upper and mid management is fixing issues.
Ironically I recently did a PMP certification to see what the fuss is all about(granted, it's not really a management certificate). Nothing I saw in that formal guidebook aligns with what I've seen in real life. So if you can't get good management from other "enterprise" companies, and you can't get good management from your early employees and you can't get it from training, then why strive for that model to begin with?
It seems like the only rational explanation for all of that is to pump up to numbers so you can aim for a nice exit on the ipo.
A rule of thumb I've heard for SaaS startups is after they reach $50MM in ARR, Revenue + Margins should equal 40%. So if you're growing 20%, you should have profits of 20%. If you're growing 50%, it's ok to lose 10%. Just a rough rule of thumb.
It's a tradeoff. I don't think it's realistic to, outside of consulting or similar model stuff, build a company that can continue to run at peak efficiency even as the world changes. Internal small exploratory teams and a willingness to cannibalize yourself can help a lot here, but may hit a wall at some point (e.g.: what can Apple build next for future massive growth?).
It's something like: Startup starts small enough to exploit how the world has changed since the big companies built their processes, and start undercutting those companies. Then they have to grow their delivery capacity to build out the rest of the features to capture the rest of the market, but this means more devs, more management, more sales, etc. That makes those of us in the "but it's less efficient" camp uncomfortable, but it's also explicitly what we're being paid for: figure out a way to grow this opportunity to be something really big. At some point it's unlikely that it can be your baby anymore.
Then the world changes enough, and somebody else does the same thing to that startup. Satellite/cable TV is an example: from very innovative at the time, to the dinosaurs lumbering around today.
The biggest thing I've seen correlated to good management is caring (if not about the people under them, at least sufficiently about the product so that they will do what's necessary to empower the people under them to get things done right). Hard to identify in a day of interviewing, though.
Both metrics are wrong. "Solving the problem" might as well be translated as "how well the engineer engineers", and it's just as bad a metric as you might expect. You want to measure impact on the company bottom line, in the long and short term. It's just not easy to measure this metric, so we come up with a bunch of proxy metrics which we optimize for, each of which can easily lead to its special type of dysfunction.
The problem you describe is what some people call "excel managers" - managers who only juggle numbers and have no idea how processes work. I have seen some management course material and quite a lot of those focus entirely on production line management. There is nothing wrong with that. Problems arise when managers adept at controlling production line processes are given control over projects.
Earlier I my career, I've seen projects understaffed with tight deadlines. When management finally released that the said deadlines could not be met, they hired really fast, and not carefully, a bunch of people to try to reach that deadline. Those new people needed to be on-boarded, trained, and sometimes put aside because they didn't have the required competences. In the end it put us even more behind schedule than before.
I've also worked at former startup bought by a big company, with more than ample resources. Yet there were tons of issues. Many teams having huge difficulties to communicate with one another, tons of features in the roadmap but very few made it into production and those in production were barely working and were a pain to keep up, the core functionalities of the product were slowly rotting away, long, annoying and not understood processes just cluttered everything and pieces of knowledge/information spread more like rumors with all that entailed of inaccuracies and wrong ideas... I could not shake the feeling that with fewer people, we could actually have had a better and faster output. It may be an extreme case of scale-up (in term of headcount) gone bad, but I'm pretty sure I'm not the only one with a story like that...
I'm a fervent believer that flat organizations are way better, you can discuss directly with people, the pain points and challenges are clearly identified and solved together. In the end everything goes way faster and it's far more rewarding as an employee to work in that kind of environment. The issue is that past a certain headcount, flat organizations don't work anymore, however, when designing our products, maintaining the headcount as low as possible should really be a big item in the requirements.
Growing the headcount for growing the headcount seems ludicrous from a purely technical point of view. But I can understand that a larger headcount might make a company more credible and valuable from an external eye. I understand it but I'm far from a big fan of it.
>Earlier I my career, I've seen projects understaffed with tight deadlines. When management finally released that the said deadlines could not be met, they hired really fast, and not carefully, a bunch of people to try to reach that deadline. Those new people needed to be on-boarded, trained, and sometimes put aside because they didn't have the required competences. In the end it put us even more behind schedule than before.
The parent is talking about enterprise software, where costs per customer are very high. These companies live on contracts. They may have a core product, but each new customer requires a lot of development. These kind of organizations can scale linearly because each customer basically gets its own team. Consulting is the extreme version of this.
Nothing new under the sun. This is from the Tao of Programming (1987):
A manager went to the Master Programmer and showed him the requirements document for a new application. The manager asked the Master: "How long will it take to design this system if I assign five programmers to it?"
"It will take one year," said the Master promptly.
"But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?"
The Master Programmer frowned. "In that case, it will take two years."
"And what if I assign a hundred programmers to it?"
The Master Programmer shrugged. "Then the design will never be completed," he said.
> adding manpower to a late software project makes it later
More then 4 decades later it seems like we still have learned.
You don't want it entirely flat, and you don't want it rigorously hiarical. You have touched on too hiarical, but too flat is a thing as well. Someone with the skill and time needs to make descisions, and someone needs to keep track of things and coordinate. Both of those things are important even for small teams for 5-6 people, otherwise you end up with "The Bridge"(https://www.stilldrinking.org/programming-sucks).
One thing I've seen in tech companies is they invest heavily in engineering at the beginning, justifying it as a fixed cost. As the company grows, they stop growing the so called "fixed" cost, and hire more in sales, services and support. (So called "variable" costs) The reality is these salespeople sell custom deals to hit their revenue #s (especially in tough quarters) so the engineering work goes up. If staffing doesn't go up, you wind up with tremendous technical debt.
Instagram was also not profitable yet. They would have easily ballooned to 100 people if they'd tried to become profitable.
Craigslist has 50 now, and had 28 as of 2009.
Reddit IIRC was 6 employees until they were spun out of Conde Nast in 2011. (Some of those early employees are on HN; maybe they can correct me.)
PlentyOfFish was one guy until 2008, 5 years after its founding. It was doing a couple million in revenue then.
The big labor-intensive function seems to be enterprise sales. If you're just building a product for people to use or charging self-serve for use, you can do that with a small engineering team. As soon as you start charging $100K for the product or ad sales on the product, then you need to start hiring people to convince customers why they should spend $100K for your product. Of course, each salesperson makes more than they cost, so it's still rational to hire them.
In the case of at least the last 2 they also used community moderators which can be seen as a tremendous HR hack in some ways
A lot of times enterprise sales folks are not particularly technical, so they'll often request support from a sales engineering organization.
Consider if you wanted to build a Spotify competitor. Disregarding the partner management/sales/distribution side of thing, but sticking solely to the tech:
You have to be able to ingest content from all your partners. If a new song is supposed to go live exactly at midnight on a given day, you gotta be able to deliver that. Not just media, but also systems for ingesting, reviewing, and publishing the metadata, album art, etc.
You have to run on a lot of devices. You need a desktop or web app, an iOS app, an Android app, a bunch of living room apps, Chromecast support...
You have to be able to bill people. I'd suggest offloading as much of this as possible so you're not touching credit cards yourself, but then it's still integration work. And now you have paying customers so you're going to be expected to have good reliability and responsiveness to issues, and to build tooling for your customer support team.
Paying customers and inventory - even digital inventory - make things turn into a lot more work quickly.
There is almost no software priced between $1,000 and $50,000. Only big companies can afford to pay $50k+ for software and as a result they want a lot of hand-holding, support, and customization. Because they're spending so much they also want a lot of CYA assurances. Let's also be honest: they also want sales people to buy them lunches and send them bottles of scotch.
Selling to enterprises for $15,000 is a great way to go out of business: you won't be able to pay for enough staff to keep the sales pipeline flowing and you're too expensive for individuals and small businesses no matter how much value you deliver.
I wasn't that early, but I was probably in the first 30 employees, depending exactly how you count things.
There are start dates for most of the early employees in this file that used to power the (now removed) "team" page on the site: https://raw.githubusercontent.com/reddit/reddit-plugin-about...
The "new" field in that file is YYYYMM data for when each employee started (though, looking through it right now, some of these definitely aren't correct, but they're reasonably close at least). Figuring out when people left is a little trickier, but estimates around a few significant dates:
* Acquired by Conde Nast (Oct 31, 2006) - 4 employees
* Independence from Conde (Sept 6, 2011) - 12 employees (including 2 redditgifts from that acquisition the month before)
* $50M funding round announced (Sept 30, 2014) - 58 employees (many working on redditgifts/redditmade)
* Steve Huffman returns as CEO (July 10, 2015) - 69 employees
* $200M funding round announced (July 31, 2017) - 230 employees
And they've said that they're aiming to get to 300 by the end of 2017.
If you're going to figure out how to monetize all those users in a profitable way, you're going to have to do more than just let them send text messages.
I'd be curious to know how many people work on WhatsApp at Facebook now, and whether they've become profitable on their own.
It's very easy to look at a going concern from the outside and say "what are all those people doing?!" The definition of bloat is not "things I didn't think a company would have to deal with because I don't work there".
Measuring a company's success by count of employees is like measuring the skill of an aerospace engineer by the weight of the airplane he designs.
It is true that all successful airplanes have a nonzero weight, but more ain't always better.
This article doesn't really address the causes or offer any true solutions though. Focus on culture? You need to do that from the start. Get new board members? So your advice is to get new advisors? Okay, but what steps can you actually implement to solve the problem?
In my view the real problem is that good management is difficult and not well understood. Once your company grows to the point where a flat structure starts to have problems, the usual shift is to a hierarchical structure; not only a difficult transition, but also ends up trading your old problems for new ones. I wish the startup world did a better job of tackling these issues.
I'll at least attempt to give you something that may be a little more enlightening. I suspect a bunch of it will come off as stupid babble to people who have smaller teams, and less so to people who have managed or transitioned larger organizations. I claim credit for none of it.
There is no single cause of course. The unsatisfying answer is that "for the complex system that makes up a lot of these organizations, 30-40 is the number at which a lot of these systems become noticeably more unstable". There are a lot of possible reasons for this (not everyone has the same mind anymore, same incentives, etc, and over time, are gravitating towards certain things)
The main reason for failure though, i believe, is that startups are very used to dealing with complicated problems (difficult but amenable to having an end state and answers, even though they involve tradeoffs) and not complex systems (things that don't stay still, there is no right answer, and there is no end state) , and so try to solve "the system" as if it was a complicated problem. People want to put in place "an answer" and have it work for a while. This rarely, if ever, works
You give an example of this: The flat organizational system tend to not work as well at that size. People see this as a set of problems. So they try to solve them. Often, as you mention, by moving to hierarchical management. As you've aptly described, that just ends up trading one set of problems for another. That's because there is no actual solution to the problem.
It's not a problem to be solved, in the same way "culture" is not a problem that can just be solved. It is an ever changing thing. You need a very different approach. Instead of trying to solve "the problem" (which is usually, in this case, something like "people running in too many directions", etc), one needs to try to step back, and try to understand all the attractors, variables, and factors that are currently causing your system to behave in a certain way. People often think they know the answer why ahead of time, but they are often wrong :P. Figure out where you can have influence in this system by nudging variables, and try to nudge things towards a certain direction and see what happens (IE choose something you want to see more of or less of, experiment, learn from what happens, try again). Incentivize the right things to happen, instead of directing the right things to happen.
This is all a pretty general description (and there are actually very good books and courses and such on the above, even if not specifically written about startups).
There are also certainly times where the system is failing bad enough you need to completely replace it, but that is due to a failure of leadership.
There are also times where "hierarchical management" may be a valid experiment to try (it's just an example above). But i believe most startups just go directly into problem solving mode when they hit these kinds of issues, and that, again, rarely accomplishes much except frustration and failure. It really requires a mindset shift of not just trying to solve complicated problems and seeing everything as fitting into this mold.
Even you mention "Okay, but what steps can you actually implement to solve the problem?". The steps you can take are to realize it's not a single problem, or even a collection of problems. These are just emergent properties of your system. Your goal is to nudge it into different emergent properties that are closer to what you want, not just try to solve the set of problems those properties produce. It's important to also realize you will never stop having to push the system in various directions. You are never going to reach this end state where everything is always going awesome with no work on anyone's part ever again. Systems may become meta-stable, and the timeframes on which it stays meta-stable may be long, but usually the only systems that are stable are dead ones ;)
Oversimplifying the cause is that you go from having to manage people and problems relatively directly to managing through layers of indirection. You deal with it by knowing what effective layers of indirection are available to you, and learning how to make best use of them. There is no concrete recipe because each company is different, and nobody has really abstracted out commonalities to make the subject easier to learn.
The article does give a list of important indirection tools, and a list of books that give insights on the key principles. And also stresses how, in the absence of general theory, you need to get personal assistance from someone who has concrete experience with the transition.
So this seems to me to be very useful advice, even if none of it is directly actionable.
So, that's the self-similar model where you're a manager of managers...
But isn't there another model—the partnership model—where at the top is just multiple partners, each of whom manage their own part of the business and report directly to the board?
Like, at a law firm there's not a CEO right? Or the CEO role isn't about delegating tasks to the partners, it's more literally an operations role, and partners have reports that are largely outside of the CEO's delegation?
I'm kind of obsessed with partnerships lately, or as I like to call them: "Worker Owned Co-ops for Republicans".
https://en.wikipedia.org/wiki/Dunbar%27s_number
40 is about the point where the CEO can't possibly manage everyone one-on-one, and has to start delegating real management tasks.
Plus the number of edges in a fully connected graph of relationships would exceed 1000 at this point, so the graph starts to partition itself: employees stop working directly with most of their colleagues and start dividing into more isolated “tribes”. And this goes on to affect the structure of their projects, e.g., software architecture[1].
Growing a business isn't about distinct phases. It's about a continuous, iterative programme of holistic improvement, where you are always working on the business, usually while working in the business. For instance, we followed a leapfrog model whereby we'd prioritise technical uplift (both product and internal tooling) and then structural uplift (hires, methods, practices, culture). When we were actively working on one we'd be planning another - and we worked like this from day zero, when we were just two dudes.
It does differ between businesses and models. In the case of one business I consulted with, we (me, two founders) put together SOPs, defined the hell out of everything, hired like crazy (30+ in 3 months), and they got acquired for a large sum six months on. Muggins got doodley-squat, as until acquisition they were cash strapped, and afterwards the new owners wound it all up.
What didn't survive the transition in either case was me. I hate working in process-driven tick-box-now orgs, which is why I started my own business in the first place, so hit the ejector button on my own org last year - my discomfort within the beast I grew manifested as a total deterioration of physical and mental health. Turns out I'm great at building them, which is a shame.
So. It's easy enough to avoid humps if you're always planning ahead, always iterating, but the greater barrier is psychological - I guess few are willing to do the hard things you have to do to keep it on plan - like firing friends, "intensively monetising" customers, and generally playing a nerve-wracking seat of your pants game for years on end - because the cost is ultimately steep. Self hatred is like acid, and I honestly think most orgs fail because founders find it hard to completely compromise their values for the good of their business and employees.
I think you were fortunate to have this sort of mindset from the beginning and I can tell you that it is not common. One of the 7 habits is to work on things that are important but not urgent. This is what you do when you're working on the next phase while executing on the current phase. I tell people it is like watching yourself drive.
If you have the experience of teaching your kids to drive you might notice that they are much more likely to hit things when they are looking where they are driving, than they are when they are looking where they need to be. Another example I've heard is sailors walking with a cup off coffee on a ship that is moving with the waves. If the sailor watches the coffee to keep it from spilling, the coffee goes out of control and spills, but if the sailor looks to where they are going, the hand doesn't let the coffee spill.
The same is true in business where if you focus so hard on how you are solving the current problem the next one hits you before you are ready for it. Whereas if you're thinking about the next problem while executing against the current one, then when the next one arrives you are already starting to execute against it.
I'm serious about the book too. Its a very useful way of approaching running a business and many others would benefit from your experience if you could put it into book form.
There are people who start companies and either fund raise or drive revenue to the point that they have the ability to hire that many people.
Unfortunately, when they don't have the skills to hire the right people then the business tends to implode.
I always found this approach to be tremendously effective. If decentralized command were applied diligently from a company's earliest days, I believe it would sole a lot of the scaling issues organizations face. But it's difficult for most startup founders to give up control.
[0] See, e.g., https://www.inc.com/magazine/19980401/906.html
My guess is that businesses have the same issue - it's great in theory, but the cost of failing to achieve it in practice is low at first so it creeps up over time. It takes a catastrophic event to force leadership to rearrange reporting relationships and clear up lines of communication again.
Seems very reasonable to me.
Startups often have a fun "screw the corporate rules, we're doing it our way!" mentality that's perfect for the Search phase described by Steve Blank here.
During my time in a Fortune 500 company, I came to see the reasons for some of the corporate rules and corporate culture... I saw the problems and potential problems that the rules and processes are in place to deal with.
If you've never been in a large organization, it's a very different beast than a small one... I imagine that it's tough psychologically to institute rules and processes that you rebelled against in an earlier stage.
I worked for a company that came within inches of imploding at around this point. I noticed that even before hitting that size, they were already going downhill and losing people. So maybe an issue is that a company doesn't do anything different at 40 employees, but the employees get less willing to put up with it, especially if they feel that they're not sharing in the rewards of the company's growth. And the new employees who are coming in, don't share the same "startup fever" and personal loyalty to the founders, that propelled the early employees.
A mentor might be able to see this happening and steer the founders in the right direction.
It was interesting for a while but a bit of a shitshow. All the leadership felt they could run things they same way they always had instead of adjusting to the new paradigm - which is rather 'corporate' in my book.
This is a great observation, and one that is frequently overlooked or downplayed, that the true definition of "corporate" is not the existence of process or procedure or anything specific, it is being static and not adjusting to change. Thinking "we don't want rules and process because we want to remain flexible" results in the shitshow, but it's those very processes that enable predictablity in the operation of the organization which leads, paradoxically to some, to freedom. The kind of freedom you really want is freedom from having to think about and frequently deal with all the ("little") things. To wit, if your plan is to hire 30 people for a new department, you want solid HR, finance, and IT onboarding processes so you're not dealing with those things in a bespoke way for each hire, so you can continue to work on hiring the next person. If you don't have good customer service and post-sales support in place, you're going to be constantly fielding issues from current customers when all you want is the freedom to work on getting new customers.
I always thought of it as giving a platform or framework so, as you said, people didn't have to think about it. It's ready to go when a project is about to launch, etc. I also wholeheartedly agree about that w/ the more human processes (HR, onboarding, etc).
It was an interesting experience to learn from though my pushes for change and resulting frustrations are probably what ultimately lead to being laid off.
I'm just blowing hot air, but it seems to me people - engineers especially - are not discussing dependency graphs in relation to this problem as much as they could.
Also, root cause analysis suddenly looks like a much more powerfull tool to discover the connections in the graph (if those hidden dependencies cause major pathologies).
When you have a small team, you can more easily arrange for that team to all pull in the same direction. When you pass a certain threshold of employees (I'm not going to suggest 40, the number is clearly going to vary in the real world) a lot more effort is required to coordinate the work of employees. This means more middle managers, more meetings, more email traffic, more office politics as teams start to fragment, etc... All of these things can hamper productivity if not handled correctly.
I'll leave the direct link to the pdf here even though it's gated content, so pls downvote.
This also makes me think if you're lucky and have a low drama team, you can do more than 10, but at the end of the day you're going to get a superlinear increase in interpersonal drama the more people you manage so this number is likely to remain small.
At 40-50 people you're hitting the point where you have 6-7 managers reporting to the CEO and each responsible for 6-7 direct reports.
If you hire more people after that, you basically either have to severely overload someone's management capacity or start hiring a third layer of management.
The company still feels too small for that much hierarchy so instead of adding management it increases the number of reports either of middle management or the CEO until the situation is untenable.
50 is the level at which systems and processes start to become critical - you can't just succeed accidentally through heroism, you have to deliberately set out to learn from and solve problems or you're sunk.
100 is the level at which people can no longer self-organize and need explicit constructs to manage organization. I.e. not just 'a pool of engineers who work on the product', but a X team and a Y team and a Z team.
150 is the level at which every person can no longer know everyone on a personal level at the company. You'll need some way to handle cooperation and communication that's not "Talk to Bob", and all hands meetings can only happen at best yearly.
500+ is the point at which things will generally become stabilized / ossified enough that the ongoing structure of the company either works or it doesn't and the difficulty of changing those things becomes exponentially higher. Reorganization is a significant misnomer.
At 150, no one can stay aware of everyone else. Your "observable universe" becomes a strict subset of the company, no matter who you are. There's no longer one company, but rather 150 different companies as seen by every employee. Direction must be constantly supplied from the top to apply corrective measures to all those different visions of the company.
Some commentators touched this subject as well and rightly so, when you reach around 20-40 employees you start having problems that are organizational. If not addressed properly these will cripple growing startups and in some cases even prevent them from reaching the next stage.
I went through a couple of these failures myself and I can't stress it enough when discussing problems related to growth; there is a point when you can no longer communicate or work in the same way and you can't expect things to self organize. It takes quite some reorg including some hard decisions to get to a stable stage or in the best of case, transit smoothly but that takes someone very well aware of all the pitfalls.
What I saw was a whole lot of empire building. Things seem to snowball very quickly once managers start getting hired and they're all aspiring for greater head count.