It always astounds me that growing the number of employees is one of the key metrics of "growth" startups looks for. As if an unprofitable company with 500 employees is somehow more prestigious than a profitable one with 50. Perhaps it's pressure from VCs to chase market share over profits, founder ego, or something else entirely, but it's always struck me as a troubling trend in the startup world. I recall (several years ago) looking up how many employees worked at Twitter and seeing it was over 900 and thinking, "What in god's name are those 900 people doing all day?"
For enterprise software companies, the numbers matter, as they're roughly proportional to revenue.
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.
Well, at least for the purely engineering part (aside from sales), I've seen the contrary more often than not.
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.
> When management finally released that the said deadlines could not be met, they hired really fast, and not carefully, a bunch of people [...] In the end it put us even more behind schedule than before.
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.
>Well, at least for the purely engineering part (aside from sales), I've seen the contrary more often than not.
>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.
Having these rule of thumbs as guidelines doesn't mean that they're actually followed. :-)
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.
> 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.
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).
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.
> You think that solving the problem is the key performance metric, but the actual metric is how many people the manager manages.
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.
In lectures on management focusing on people (not necessarily strictly HR, like what traits you want in certain roles) you often hear that one of the worst thing you can do is to promote the best salesman to head of sales, best programmer to head of engineering, etc.. Their qualities make them good at production, not management. There is a lot of truth to it.
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.
> 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.
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.
Revenue definitely doesn't equal profit. Headcount is easier to measure than revenue, which is easier to measure than profit. :-)
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.
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.
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.
Yes they were also not charging their customer and thereby had no reason to offer customer support. These companies are more of the exception than the rule.
All this, as well as integrations: if a company is paying 100k for your software, they are going to expect it to integrate with their existing stuff in various ways and you've gotta support that, and a lot of times that involves hiring "integration engineers" to support that stuff while you (hopefully) build those things into a general purpose solution (which is more difficult than it sounds).
A lot of times enterprise sales folks are not particularly technical, so they'll often request support from a sales engineering organization.
Integrations aren't just enterprise things, as well.
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.
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:
That's only one way of measuring scale. They also burned something like $130MM the year before they were bought by Facebook.
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 was the same way with Digg. Hundreds of employees to do what exactly? In hindsight, maybe not shocking it died. Reddit is doing the same, ~300 employees to run something that a team of 30 could (of course, not all are engineers). It's crazy.
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.
Whenever you start asking "Why does company X need all these people, what do they do?" Think about your time playing Kerbal Space Program and learning how the rocket equation works. In order to get a heavier rocket into space, you need more fuel, which itself weighs more, so you need even more fuel to launch all that extra fuel, which itself weighs more, etc.
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)
It's the valuation trap. If twitter was satisfied with a valuation 2-3 orders of magnitude lower than what it is, it would be highly profitable right now.
The question is CAN twitter be satisfied. I'm not talking if the investors, ego, or all those others will be satisfied, can it survive at all?
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.
The answer is probably: a lot less. Let's be honest, with the exception of Google, there are very few technology companies (not consulting companies) in the world that actually need 10.000+ employees.
I have to just say that I can't think of anything else except that advertising sales just does not scale.
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.
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.
They're also publicly traded companies, so they need to look like they're doing stuff. Facebook could probably very easily cut back on 5.000 employees without a problem. But that wouldn't look good now to the shareholders, would it?
Digg and Reddit, for starters, don't have hundreds of their own datacenters - and about one or more orders of magnitude less users than the "giants". Twitter seems to have operated a mixture of leased and owned DC space (http://www.datacenterknowledge.com/archives/2011/09/19/twitt...), but far, far less than FB/Google/AWS do.
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.
Smaller companies will. Multinationals generally have in-house tax specialists to deal with all of that. Case and point: General Electric. Assuming by multinational you're talking about Fortune 500 and not companies operating in more than one country.
Facebook burnt through $700M if I recall correctly. Back then this was unheard of. Though, most of it was to support their explosive organic growth while ad revenue was catching up.
I guess it'd be more helpful to see a breakdown by employee type/duty. Stuff like Reddit/Twitter would be considered to be something that needs to be up 24/7 (by their users/investors/etc). That means either shift work, or a lot more people so you can rotate the on-call duties. When you're a fresh, new company, you can get away with having one or two people do that in perpetuity, but after you get VC funding or have been around for a while, those people are going to expect you to hire on more help for them so they don't have to be on call all the time.
I think a classic reason for ever expanding head count, and in ZIRP era economy, valuations, is because management tries to end run failures of immediate objectives and keep trying more elaborate end runs. Yes, UberCab will be a fine multi city service if they have poured such subsidy into their operations, that every last competitor is bankrupt.
Number of employees isn't a key metric of growth for any startup. It _is_ a way to try and drive growth, though. So when VCs want companies to hire, what they're really asking for is companies to put the money to work to make it grow faster.
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.
Hiring as an attempt to drive "real" growth (revenue/market share) I can understand but my argument is that the marginal gain of every new employee seems to drop off quickly. I can understand hiring more sales reps if that's the bottleneck in getting new customers or more support staff if that'll improve customer retainment. I just don't support hiring 20 more project managers because that's what someone feels like the company should have at this stage.
Yes, I think what you're witnessing is badly managed companies, or companies that don't have much of a future. I'm fairly sure no VC on earth would recommend hiring 20 more project managers.
I agree, but I also think that if your product isn't where the VC thinks it needs to be, and you've got plenty of money in the bank, that VC isn't going to tell you to take all the time you need: they are going to tell you to focus on hiring great people so you can build faster.
"You need to hire more/better people" is just the standard response to almost any problem.
I've seen it pointed out that it's an odd choice to use the most well-known example of parallel work in the world as an icon of non-parallelizable work.
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?
The way to do it is "3 people making a baby, 3 people building a nursery, 3 people promoting the baby shower". Not all companies can do this, or are managed well enough to pull it off, but it's not an insane thing to try once you've already decided to get on the VC gravy train.
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.
Being understaffed really limits your ability to do stuff, and it also sucks for the people you do have. (Source: I live this every day of my working life.) Also, by the time you're in this spot you should have hired already, and digging your way out will be so costly in terms of forfeited opportunity and the strain on existing employees when spinning up new ones. While on the other hand, if you don't grow your customer base you're gonna go out of business anyway.
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".
I think there is some truth behind it. Yes, profitability doesn't directly increase with number of employees, but having many has other advantages. For instance you can drive bigger bargains, you can take on bigger customers, you can get bigger loans, and you have a bigger influence on politics, law, etc. I don't believe that 500 to 900 employees makes a big difference, but you can feel a huge difference between 5, 50, 500, 5000 and 50000 employees.
Can't say I found this article all that enlightening. Having been an employee at several startups that have transitioned past the 30-40 headcount mark, there does seem to be a breakdown at that stage. What is the cause, and how do you deal with it?
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.
>Having been an employee at several startups that have transitioned past the 30-40 headcount mark, there does seem to be a breakdown at that stage. What is the cause, and how do you deal with it?
Yup, in my experience, 40–50 is also about when a classroom changes from “small class” to “lecture hall” or needs a TA, for similar reasons.
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].
Having been an employee at several startups that have transitioned past the 30-40 headcount mark, there does seem to be a breakdown at that stage. What is the cause, and how do you deal with it?
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.
> Oversimplifying the cause is that you go from having to manage people and problems relatively directly to managing through layers of indirection.
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".
The problem is the "plan" would be for the company to grow 10x in the next 3-4 years. So, for every person on the team add 9 more people. now, keep your culture. Also, most of the people you hired were experts in the jobs not management.
"Can't say I found this article all that enlightening. Having been an employee at several startups that have transitioned past the 30-40 headcount mark, there does seem to be a breakdown at that stage. What is the cause, and how do you deal with it?
"
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 ;)
I disagree with much of this, having taken my own business (ecommerce platform) through this point and having mentored a few others through it.
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.
Then you're takeaway should be that if you wrote a book about your experience it would have solid sales :-).
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.
As someone who has been through this. The 40-50 employee threshold for a business requires competent people appointed to the management of departments.
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 think that is the difference. Under 50, you are hiring people to execute and the leader can still control everything. Above that you must hire managers to control pieces of what you used to control. You must trust them to do the right thing for the company. Most people who are successful at the 0-50 can't let go of that control.
The Marine Corps teaches the "rule of three:" each leader should have at most three direct reports.[0] In practice, leaders at the platoon level or higher (~40 people total on the infantry side) also get a senior enlisted advisor who serves as a trusted second-in-command but who isn't a direct report in the same way as your subordinate unit leaders. Additional folks beyond those three should report to one of the boss's subordinate leaders, not to the boss. The structure repeats up and down the line, sometimes with small tweaks: three rifle platoons to a company, three squads to a platoon, three fire teams to a squad.
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.
I have always loved the USMC's leadership principals, but they have a hard time adhering to them in practice. Talk to pretty much any infantry officer who saw combat in the last 15 years and they have endless stories of chaotic command arrangements.
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.
I agree that there's a missing playbook for that phase of companies... it would be great to see some collected wisdom on "these are the ways that companies run into problems in this phase" and "this is how to prevent / deal with those issues".
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.
Excellent point. The company I worked (not a startup) had existed below 30 people for most of its multi-decade history. They started expanding rapidly the past few years and I came onboard when they were at 60 people. That double in the two years I was there. The higher-ups, who had started and run the company for decades, were strictly against not wanting to "seem corporate" or have too much organization / structure because it was "corporate". Yet, they kept running into ways that the structure would self-organize or that things would stagnant because they weren't being responsive to the large amount of employees below them. They wanted everyone to participate in a vision but the vision was basically "get bigger and don't be corporate" and rather muddied. Everyone I spoke with that had been there more than 5+ years, and that would be honest, had said the major changes in the company 'felt' like they came at 50 people, 70-80 people, and definitely after 100.
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.
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.
Maybe the founder should hire or involve a senior manager as a mentor, long before they reach X employees. The mentor can say: "I see what you're doing here, but here's how a larger company does it, and here's why."
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.
One way is to look at the organization as a random graph. Relations between people - edges - describe business dependencies. If the growth has been completely organic to that point, there are chunks of undocumented and unnoticed connections. Unnoticed, until they break, I presume. The complexity grows as a square of the number of people. With 40 people there are 40 x 39 random edges (1560). With 20 (20×19) the number is 380. With 10 (10 x 9) 90. So, as back of the envelope estimate a company with 40 people is 17 times more complex than a company with 10.
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).
I'd suggest it has something to do with coordination.
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've actually had to write an ebook (for content marketing purposes) on growing a company and going from 3 to 9 to 30, and so on. The most interesting thing is the Greiner's Growth Curve as well as Adizes Corporate Lifecycle.
I'll leave the direct link to the pdf here even though it's gated content, so pls downvote.
One principle of good management is that no one can properly manage more than roughly a half dozen direct reports (10 is the absolute limit, and at that point you're stretched way too thin).
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.
This was definitely the wisdom I've heard historically. I suspect the number may be slightly higher than it was 40 years ago due to digital communication, but a lot of what I hear is that it's just really hard to deal with all the personal, and interpersonal problems that crop up.
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.
Here's my rough understanding, from experience anyway:
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.
I think the difference between 100 and 150 is that at 100 people, as long as the organizational structure is right, you can still play fast and loose with corporate culture. While it'll be a stretch, each person may be able to know every other person if not by name then at least by face and role. In other words, each person's "observable universe" inside the company is the whole company.
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.
I like the high level CEO view of this problem since it's a good reminder that the overall phase needs re-think. That said, what this article hints to in the title and misses is that there are inherent problems for startups that are in fact related to the number of employees.
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.
I was an early hire at a data protection startup which inexplicably began behaving like a much larger and profitable company when product was still very flawed and barely usable. ~$100M of funding and many years later, that company has yet to become profitable and rather than shudder the doors, merged with a competitor. All common stock rendered completely worthless in the process, not that there was any hope left after all the dilution anyways.
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.
I imagine it's because, at that point, you're running a real company, with needs for marketing, sales, health insurance, company policies regarding leave and all the other adult stuff that most people expect at a real company these days. And generally, the person who started the company doesn't have the skills/knowhow to handle all that (many were just line engineers or what have you the year or two before). These things can obviously be learned and dealt with, as evidenced by the fact that there are companies that continue after the stumble.
also consider that while there is funding, everything is great by definition. at least two places I worked at had to start showing results around then...it wasn't anything about scaling, they just didn't have anything to show
As the VP engineering of a company in the Build process our CEO do most sales thing and won’t hire capable people and fire incapable people. What should I do?
This article is a decent attempt at explaining this phenomenon. Most early stage startups are co-founded by highly driven people, who work well even with the absence of processes and structure. This ethic will never translate to all your employees after a certain point. This is where process and structure come in and often, it is too late before it can be successfully implemented.
I can accept that there are different levels of growth and at each of them there can be trouble. But it's not just one level. You can just as well stumble at 5 employees (I experienced that), at 17 employees (experienced that) or at 80000 employees (experienced that; admittedly not a startup though).
I think below 40, employees have multiple roles where you are expected to think on your feet. It attracts a certain type of person. Above 40, you are a cog in the machine. You really need to keep to your role and the company succeeds because of the role you do.
embedded questions in a headline should get the same sentencing as those ending in a question mark. It is not hard to point out the answer in the title. I won't try at it, thohgh, since I won't read the article (either way or because of) Betteridge's law of headlines.
"Why successful startups stumble at 40 employees" is a statement and an answer, not a question. If it was a question, it would be "Why do successful startups stumble at 40 employees?"
