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.
