Look How Big Is My Team | Hacker News Reader

Look How Big Is My Team

nicolasbustamante.substack.com

140 pointsnbstme102 comments

My worst job ever was at a big company whose CEO believed that small teams and low headcount were the answer to everything. I was attracted to the company because I had enjoyed working in small teams at startups before.

It was awful in a big company, though. We were always short-staffed on everything we did. The CEO chronically underestimated how much work went into maintaining existing products or even just extending them. He wanted to treat every new initiative like a mini-startup that could move fast with small headcount, which led to tens of isolated teams building products that were incompatible with each other and not communicating about it. Coordinating with other teams would slow you down, so it was basically forbidden. But then our customers expected things to work together, so we had to scramble to re-integrate everything before it shipped.

Taking vacation was difficult because it could mean 20% of the team was gone, which would have measurable effects on delivery. Every time someone left it was a scramble to re-hire and re-train because it left such a huge hole in the team.

Hiring too many people is a problem, but trying to keep teams artificially small is also a problem. The hard part is knowing how close you are to "too big" or "too small", which is rarely obvious at the time.

Thanks for your insightful comments. You're right; the hardest part is to find the balance between too big and too small headcount. It's challenging and it differs a lot per department, company size etc

> treat every new initiative like a mini-startup

> Coordinating with other teams would slow you down, so it was basically forbidden.

Are you sure team size was actually a factor? I've seen rules/cultures like these before and they always end in disaster, regardless of team size.

Small teams that actually coordinate, on the other hand, seem to do just fine in my experience. In fact, one of the biggest problems with oversized teams is the combinatorial explosion of communication channels https://project-management.info/number-of-communication-chan...

Well, to be clear, it was great for the CEO

Team Topologies provides some good info around team size, and how to split teams when they get too large: https://teamtopologies.com/

Heh, I used to have so many opinions on how to run software companies. Ideal team sizes, methodologies, remote vs office.

Now I'm seasoned with enough experience to know that no matter what the "best practice", some companies out there will screw it up.

Whatever past successes I experienced in teams I was a part of, I was wrongly attributing to these various rules of thumb (such as team size).

There's a great quote in the XP book that boils down to, "Never follow any rule or practice thoughtlessly. The important thing is understanding WHY you pair program, or TDD, or use CI/CD." If you have a Jenkins pipeline but are getting none of the benefits of CI, then there's really no point in having it. Same goes for any practice or tool.

I recall someone talking, possibly here, about how they limited this a bit.

One of the expected outcomes of Agile is that the business has to acknowledge some of the realities (logistics) instead of just living in a fantasy word where how they think things works is real and if things aren't happening then it must be someone else's fault.

Anyway what they said is they had about 8 projects and 3 teams, some of which worked on the same projects, some which only worked on a subset. Rather than trying to juggle all 8 products, each sprint was about one product, and the product owners had to thumbwrestle over whether the next cycle was one (or possibly two) of theirs. Pretty much you could only count on 1-2 sprints a month, unless you were involved in some high visibility mandate.

But at the same time, old projects still existed as an ongoing concern, just with intermittent attention.

I agree with the premise of this blog post. But there are downsides to having a small team. We're a bootstrapped startup with 15 employees. When we lose an employee (sickness, termination, voluntary) it really hurts us. We have a 3 person sales team. One sales person down means a 33% loss in our pipeline. When our accountant is out, that's the entire department.

50-100 seems like the sweet spot for having enough coverage in responsibilities and spreading risk. But maybe we'll get there and it will still feel like we don't have enough people.

Thanks for sharing! I also suffered from this when we were less than 20 people. From my experience, once you reach roughly 50 people, you have enough redundancies among functions to not be hurt by a departure.

How do you manage a 50-100 person team?

Honestly that sounds as bad as a skeleton crew of 1-3 people.

The reality is that oft-hated word bureaucracy is what's needed. A hierarchy.

Using a military analogy: "teams" of 2-3 ppl, 2 teams in a squad, 3-4 squads in a platoon, 3-4 platoons in a company, etc, etc.

Each of those entities in the organization should have a lead. Someone who's responsible for their group's performance.

Now you can stretch this, and minimize paperwork to expand say, a squad to 10-12 people (instead of the 7) but that either requires a talented squad lead, or some stuff gets ignored (ok for short term, not good long term).

If you have large loose teams without a hierarchy it's madness

I think the suggestion was 50-100 people in the _company_, not that each team should be that large. Right now they only have 15 people total.

> Small teams leverage speed as a competitive advantage which is key to winning over competitors. Other benefits include better communication, more engagement, more profits to reinvest, and, overall, better productivity. Small groups avoid the Ringelmann effect, which is the tendency for individuals to become increasingly less productive as the size of their group increases. More importantly, the headcount constraint drives creativity and innovative solutions.

> Controlling headcount expansion when experiencing fast growth is challenging. Targeting an efficient number of teammates is tricky because it's difficult to know and test when fewer people can achieve more.

This is really challenging, but one thing to keep in mind when planning headcount is that product usage and business revenue can scale very, very quickly once you find product-market fit, but there’s a slow maximum rate you can find, hire, and onboard more (good) people; especially good managers.

At Notion we were too cautious about adding engineers because we over-valued the efficiency of the small team, and under-estimated the difficulty/low rate of growing the team. This caught us by surprise - we thought we had a good trajectory figured out compared with our business growth, but at a certain point the growth ate through the headroom in our systems, and we spent most of a year on reliability instead of features. We fixed the problems, and have been hiring aggressively since that whiplash, but it still feels like we lost a lot of time chasing efficiency instead of starting hyper growth hiring.

That said, hindsight is 20/20. If you start aggressive hiring as soon as you see some market fit, and then growth tapers off, you can burn both your efficiency and runway on a “false start”. But even if you’re right to start, you’re going to hit the “good problems” of hyper growth next. Maybe it’s part of the hyper growth territory to feel a year behind hiring until suddenly you double the team in a year from 300 to 600 engineers like we did at Airbnb and then all the culture falls apart and suddenly you’re in the Warring States period.

Just be sure they're not contracting out development to artificially reduce the FTE count and increase this ratio.

Another strange ration was a CEO at a tier 1 automotive supplier telling us he was looking at engineering as a percent of sales (or revenue or similar). We were above the industry average which seemed to indicate spending "too much" on engineering. My first thought was that a lot of engineering (vehicle specific calibration and software tweaking and integration) was on a per-vehicle basis, so that metric could be improved by not taking the smaller production programs. DUH. But as a leader it makes sense to grab all that business, including the less profitable projects. Maybe those are even a basket of programs with one OEM negotiated all at once. Who knows.

Especially if you're not capitalizing any of that spend and expensing it all to be conservative in your financial reporting.

The eng spend could benefit you later down the road so it's perhaps naive to say it's bad to be above industry average

This one size fits all approach is wrong. It is not about the size, but of quality. If you are able to hire all A-star employees then small size makes sense. But the reality is very different. You cannot get all A-star employees from the start, and you are also racing against time. So you try to balance between time, size and quality. If you are lucky, you will get second A-star senior engineer. Otherwise you have to hire two junior A-star engineers instead of one senior engineer both being mentored by a senior engineer.

Depending on what your team configuration is, the way of communication changes. With senior engineers the communication is minimal but with junior team member configuration the communication increases. Similarly, the cost structure(implicit and explicit) also differs between these two configuration.

So suggesting a single prescription is not viable. The reality is very different and needs to be looked at on a case by case basis.

Craigslist went from 50 employees in 2017 to 407 today, and I wonder if that's partly responsible for its decline. Facebook Marketplace was probably the last straw, but a smaller Craigslist might have been able to pivot and innovate ahead of them.

Back in the 90s, I always wanted to be in a small startup that was mostly open source or maybe part of a software developer guild that pooled resources with other startups. Then every time a startup won the internet lottery, it would invest the proceeds into the local community or pay into UBI.

But even today, there's no way to come up with the roughly $24,000 per year it costs to live in the rural US, so we all still work for the mega corps in one way or another, saving for a day we might free ourselves which never comes.

Interesting for Craiglist! Maybe they started hiring more in 2017 when their traffic decreased to fund new initiatives, and it finally didn't work out. Or perhaps it worked out, and they stabilized the traffic around 300m visitors per month. Who knows!

Don't you think there are more and more developers - for now the most elite ones - who manage to live out of contributions from grants or github sponsoring?

Ya there are, but it's such a vanishingly small percentage that it's not material.

There's good stuff like Y Combinator, and I was excited when it started because it seemed to grok that the fundamental problem in startups is that first $10,000. But (and this may be a controversial opinion) I feel like they fell into the same trap that every other incubator falls for, which is catering to elites. Now it seems to be a bit gamified, filtered through the lens of a certain youth demographic pitching to wealthy investors for large sums of money ($125,000), like the show Shark Tank.

I would very much like to see something that looks more like the grant system you mentioned, where small amounts of money could be obtained with relatively few hoops or strings attached. I've had countless times in my life where $5,000 or $10,000 would have given me the runway that I needed to finish a project and make money. But the money never came, so those all ended in failure, and a person can only fail so many times into midlife before playing the game itself feels like failing. If I knew in the 90s what I know now, I maybe wouldn't have chosen tech as a career.

The flip side is that I've survived on almost nothing for so many years, that I feel a calling to work towards providing income to everyone, everywhere. I think that's something we can manifest if we go back to first principles. I'd propose studying the history of such attempts and discovering which steps of the process were sabotaged by external pressures, then routing around that interference. Basically a startup working to solve the problem of income. The fact that this sounds at least a little preposterous seems more like of a failure of capitalism to me, than something fundamental.

A practical attempt at this might look like building solar farms to power cryptocurrency mining, to route around the problem of energy markets not buying alternative energy from homeowners at the going rate. Every market has that kind of defect that can be exploited. But they're difficult to see when we're at the losing end of the bargain as consumers, or dependent on the cashflow they generate as employees.

I might be slightly bitter after watching no movement on this in over 25 years, so please take what I'm saying with a grain of salt. I'm also super-optimistic about stuff like solarpunk :-)

"but a smaller Craigslist might have been able to pivot and innovate ahead of them."

I feel like they had a small team that didn't innovate for 20 years. Whether they were 10 employees or 10,000 they were due to have someone figure out a better way.

One of those 9,950/10,000 employees would have figured out that better way. Size matters when there are multiple orders of magnitude of difference.

Sure, one of them would have figured it out. But then they would spend the next year trying to get managers to listen and would eventually quit out of frustration.

Counterfactuals are fun!

Craiglist's biggest advantage in the past was their userbase. They didn't make the website that user friendly. I might be an outlier on HN but I'd rather give my number and email once to a large corporation instead of having to use that email/number to directly call strangers, asking about what they're selling. They also have a problem with duplicate or irrelevant listings when you search for low volume items.

Once Facebook Marketplace came in and essentially wiped away all those roadblocks. Facebook has its own share of problems but those are mostly with the people who are still using it and the ads. The marketplace product works pretty well.

You don’t use your own email on Craigslist, it’s obfuscated.

Or, maybe a bigger Craigslist would have better predicted Facebook marketplace's reach and have additional lines of business so Facebook Marketplace wouldn't be such an existential threat. Without additional, inside information it's impossible to say.

Remember, Craigslist predates the cloud by a decade or so, so standing up their service would be a lot easier today than when they started. How much time of those 50 people was spent on procurement, to the opportunity cost of having a modern interface/other upgrades.

One thing completely left out of the discussion is the aspect of time. It takes lots of work and time to hire somebody and make them perform at their best at contributing to the business (especially in technical roles). I’ve seen this underestimated more times that I can count. Throwing new (either to the company or to the problem) people at a problem will almost never speed up a project. Hiring done right is an investment - not only of time, but also of short term productivity - that will start paying off after months at best. People react taken aback when they offer you 3 engineers to get that project done in 4 months instead of 5 and you tell them that this will not make this project run better but will help with the next.

I remember the need to make company sites look big / corporate like - using We even when it's I. It's less of a concern now, BUT headcount is still important because of bus count/factor [0] - which is a legitimate concern if a business unit is going to depend on your solution for business continuity.

[0] https://en.wikipedia.org/wiki/Bus_factor

I remember being turned down by customers because your team of 5 people was too small. Now that we are 80+ I understand their concerns and how hard it is to rely on a small team's software.

VCs buy growth, headcount signals growth

Not sure that signaling & social status lead however to success

If your goal is to maximize the rate of return you pump a lot of cash into a startup, force them to spend it on heads and marketing then ask your friend to 10x the valuation in 12 months.

Haha true! Although it's the "not realized rate of return." That might be good enough to raise another fund and live out of generous management fees, but it is not sufficient to realize financial performance - making money when the business sells out or IPO.

Public markets have the same incentives, as long as there's growth stonks go up. Late stage firms have relationships with banks and the return of SPACs made dumping roided up donkeys easier than ever.

Warren Buffet claims that his mentor Benjamin Graham once wrote: "In the short run, the market is a voting machine, but in the long run, it is a weighing machine" In the long run, fundamentals matter, and only the best business thrives.

Yes but VC funds have a fixed window, their goal is to deploy their money in the first 3-5 years and show returns in under 10.

If the goal is to create a successful product, then no.

If the goal is to get another round of funding from, or bought by someone with tons of cash but lazy in the diligence department -- then it can definitely "work".

About a decade ago I worked at a place where we frantically moved from our private offices to a big shared open office situation with whiteboards on the walls before the investors came because "that's how facebook does it."

It worked and the place got bought out lol. Business was shit though.

Ours had a fancy "library", well-stocked with thought-provoking books, supposedly for stimulating discussion and study, realistically only for showing investors around.

The "library" backed out onto the Big Boss' office and he didn't like the noise. Oh, I forget, of course he sat with us lowly minions at the coal face of open space, and it definitely wasn't his office. Except it was. And he didn't like the noise.

Not just VCs a lot of governmental funding initiatives or tax initiatives are based on headcount growth. So sometimes you hear startup founders proudly say how they will double the headcount in the next year.

It's not just VCs. In a big corporation, the number of reports in your org is proxy to your clout. The more people you manage the more prestige you have. My wife likes to say "Head count is currency". It can absolutely lead to bloat because leaders are now incentivized to have more employees instead of producing more value.

> For instance, the crypto exchange FTX with 150 employees rivals Coinbase and its 4115 employees.

I bet Coinbase has better customer support. Customer support for a financial institution can be 1000+ people, which inflates numbers but has a huge impact on the customer.

Imagine you deposit 10k and your balance isn't showing up. A company with 150 employees is going to try to use the same (potentially broken) automated systems to help you. It can be really comforting to know there is a human on the other end looking at your account and saying, "yeah that doesn't look right, let me fix this for you."

> I bet Coinbase has better customer support. Customer support for a financial institution can be 1000+ people, which inflates numbers but has a huge impact on the customer.

I have no experience, but whenever I read about coinbase support, people are crying how horrible it is. Reading only now, people are calling it The Worst they ever encountered. Anyone with experience here?

If you look at volume Coinbase does something like 2x as much volume as FTX. Volume isn't the end all be all of an exchange, but we would expect larger exchanges with more trading users to have more complaints.

2x sounds like not a lot?

I mean, which support? That's the question I always wonder about when I see "good teams are small, bad teams are large", because if you're a Coinbase, you have these groups needing support:

- Consumer-level users

- Business users

- Cloud developers

- Ecosystem platform partners

- Outsourcing partners

- Lawyers, for formal complaints and civil violations

- Law enforcement, for criminal violations

- Government support, with special clearance and security training requirements

Then if you do 24/7 global support, you need to replicate that support expertise across multiple geos trained to triage and hand issues off across TZs and languages.

So who _generally_ gets the bad support experience? It's often the small-potatoes consumers, because those complaints have the smallest business value. But who generates the most noise? Small-potatoes consumers, because there are thousands upon thousands of them, and some will start social media accounts, blogs, and groups JUST to complain about the support.

But in the end, they're still small potatoes to the people at the top of the success/service or sales orgs, who look at churn numbers and say, "oh, we lost $xM in business in the consumer segment because our service locked them out of their accounts, but we have a single $xxxM customer who thinks our UI needs more polish, and also they heard about NFTs and want to trade them. so we want eng to prioritize those things over fixing the consumer app, and we'll hire x support reps to get the consumer first-response time down, then lay them off in a reorg after a couple of quarters. and now who wants whisky????"

So you wind up with a large support team, "good" metrics, a customer base of small users who are mad all the time, enough Tier 2/3s to handle the small enterprise customers' needs, and enough managers to run interference with large enterprise customers to buy time for engineers to show up to calls so the big fish feel heard.

It's a cultural legacy of the old businesses that were human intensive. Now there is a lot of use of technology that is harder to see from the outside. Clearly those who judge a technology startup by the number of people indicate a low understanding of the scaling capabilities provided by technology.

Interesting, thanks for sharing. I'm still amazed that Microsoft, with 144,000 employees, still has a revenue per employee of $932,000! What a monster business!

What you really want to look at is net income per employee, which for MSFT is around $415k. Compare to Amazon with is iirc around $50k (just goes to show why software-first businesses are so attractive to investors)

depends how much net income is being reduced by capital investment costs... for example amazon has been bootstrapping its own version of fedex. They could probably raise net income in the short term by just using existing carriers, but they clearly think long-term profits will be improved by burning money on rolling out an entire internal logistics org.

Microsoft has a lot of vendors and contractors that aren’t technically employees but are, in an abstract sense, part of their workforce and payroll.

Amazon also has a lot of contractors, but IIRC most of their warehouse employees (the vast majority by number) are FTE. Also I think Amazon has many multiples of Microsoft’s “employees” as a result.

For sure software has big margins but I think there is a lot of nuance lost when looking at these gameable FTE counts

That's why you look at net income and not revenue

You can find something similar in consulting businesses:

- Mckinsey Revenue: $10.B, Employees: 30.000 -> Revenue per employee: $333K

- Accenture Revenue: $50B, Employees: 674,000 -> Revenue per employee: $74K

I think this just shows how underpaid so many people at Accenture must be. You figure out of nearly 3/4 of a million employees, they must have several hundred, maybe a thousand or more executives making $200-500k/yr in salary. There must be a ton of consultants doing the grunt work for $30-50k to make that feasible.

Given that Accenture does a ton of outsourcing, I'd imagine it is a magnitude less than $30-50k.

Microsoft has a lot of vendors and contractors. I’d be curious to see how the number changes when you include, say, everybody with an active @microsoft.com email.

Pedantry, but vendors at Microsoft have an @microsoft.com email, the username is just prefixed with v-.

That is what I meant. Include everybody at Microsoft with an internal email as a “worker” to capture people like vendors and contractors along with employees

Oh yes, gotcha, I misread it as the opposite. Indeed if you include vendors and contractors the average per “employee” would certainly go way down.

Vanity metrics don’t have to be high numbers, they can be low numbers too. The author is just swapping high head count with low head count as a vanity metric, using low headcount as an efficiency indicator. Without knowing what the people are working on/achieving, headcount is useless either way.

> The author is just swapping high head count with low head count

That's actually not the conclusion. They suggest looking at ARR/FTE.

To show my point with an example, according to him, 10 devs keeping the lights on has a better AAR than 15 devs that are keeping the lights on and adding new value. But the former is not more efficient than the latter.

What is AAR?

Pretty sure they mean annual recurring revenue (ARR)

Then this clause makes no sense:

> 10 devs keeping the lights on has a better AAR

Sorry, I meant ARR/FTE ratio, the metric that the article and the person I replied to are using.

Ok.

If the 15-member team is adding value alongside the maintenance, that will surely be showing up as increased ARR. If the increase in ARR is > 50%, the 15-member team will be doing better in ARR/FTE.

I don't still get your objection to the point made in the article.

> If the 15-member team is adding value alongside the maintenance, that will surely be showing up as increased ARR.

No, and this I think is the root of my point. Anything not producing AAR yet (e.g. developing a new product) has no impact on your AAR, but adds headcount, thus skewing any insight AAR/FTE would give.

This point, I believe, is implied in the article. The trend of ARR/FTE is what the author recommends measuring as a metric.

> So, one of the few reasons to ask for the startup headcount is to compare to its revenue and quickly evaluate its soundness.

This line lead me to believe otherwise. I agree the trend is more valuable, but still has issues (e.g. months- or years-long projects will have no value until they are released)

All else being equal, low head count is simply better than high head count from a business standpoint.

Sure, I guess my point is that all else is never equal.

Haha, fair enough.

I've certainly seen first-hand how resource constraints can lead to incredible focus, creativity and a cohesive end product. I've also seen how hypergrowth at scale can lead tons of waste and net-negative activity. The ideal is efficient growth, which requires different tricks at different stages, and becomes harder and harder as you grow.

I dislike the VC model because there is huge pressure to keep growing even when it doesn't make sense or sells out potentially bigger but non-monetary ambitions. For example Twitter received incredible pressure to be as big as Facebook which turned it into a generic walled-garden ad-selling media app, away from the potential to be message-plumbing for the Internet.

Targeting an efficient number of teammates is tricky because it's difficult to know and test when fewer people can achieve more. Too many constraints kill growth, and not too much also kill growth...

A fact often ignored is that big startup success didn't raise a lot of money. Before their IPO, Shopify raised only $122.3M, Google raised $36.1M, Linkedin $103M, King $43M, Datadog $147M, Tableau $30M, and ServiceNow $83M. They all built massive businesses without a lot of cash infusion.

I'm a little taken aback at 100M+ qualifying as "not a lot of cash" in comparison to, say, YC's usual funding level for brand new companies?

I think it might be restating the obvious to say that a company pulling in 100M+ is no longer a startup, it's an established (even if relatively new) company in aggressive growth mode.

look at companies like dataminr or plenty - they have taken over a billion dollars in funding afaik. That level of cash is pretty rare for successful companies from what I see. 100M is a lot too though - i don't disagree.

Are you saying that raising $100M makes a company ipso facto no longer a startup, or that some transformation that makes it a startup has almost always happened by then?

I joined my last company about a year before they raised a Series C that brought total funding to $95M, and I think that by almost any other definition it was a startup before and afterwards.

(And it was enough of a startup to do a "hard pivot" to something largely unrelated when the pandemic destroyed its core business model, instead of shutting down.)

Competitive Senior Eng packages in this market are ~$350-500k (incl equity), and the fully loaded cost to hire is probably something closer to $1m per engineer.

Yes $100M is a lot in absolute terms, but depending on what you're trying to achieve, how many people you need to achieve it, and what your timeline is, $100M might not be so crazy in context.

I am an industry analyst and pay a lot of attention to head count. I use similar metrics to the author to estimate revenue for each of 2,000 companies I track. I usually have a friendly CEO in a sub-segment that will share their revenue numbers so I use their revenue per employee to estimate all the other's revenue.

But even more valuable is tracking change in headcount Q/Q. And yes, growth and success is reflected in head count. Of course there is always a bump up after they get the big A round or B round, but now they have investors looking over their shoulder to make sure they keep an eye on cash flow.

I have received conflicting advice from various respected sources on ideal team size. During my time at Amazon, frugality and the inability to acquire and retain talent kept my team small with open reqs the entire time I was there. On the opposite end, I was in charge of product of a Hollywood studio backed venture that went seeking additional capital from Sand Hill Road VCs. A combination of clout and curiosity got us meetings with a lot of top names. At a meeting with Khosla Ventures, Vinod Khosla asked if our whole team was the meeting. Around the table was myself, our COO, our CTO, the very famous head of the studio, our CFO, our head of cloud and a couple of engineers. Our COO proudly said "Why no, there are 35 more employees back in Los Angeles. Vinod told him that our head count was about 35 too many and went on to explain his reasoning. I received some very good wisdom, but sadly the advice wasn't taken and the discussion on the private jet back to LA was about why our actual head count was too small and why Khosla was wrong. The company was eventually acquired by Yahoo, which perhaps was a fitting fate for not taking some good advice.

> At a meeting with Khosla Ventures, Vinod Khosla asked if our whole team was the meeting. Around the table was myself, our COO, our CTO, the very famous head of the studio, our CFO, our head of cloud and a couple of engineers. Our COO proudly said "Why no, there are 35 more employees back in Los Angeles. Vinod told him that our head count was about 35 too many and went on to explain his reasoning.

Do you remember what was the reasoning?

Might signal efficiency.

Might signal unsustainable overwork, inability to scale / manage a "real" business / no real barrier to entry.

Don't you think the inability to scale is exemplified by revenue growth problems, not headcount?

Of course it reeeallly depends on the case, but every business will need the "wetworks": customer service, client relationships, etc.

So if you have a core tech product and that is scaling, then fantastic.

The classic success case was WhatsApp: 19 billion dollars (jeesus wow) for a basement full of people.

"There are plenty of examples in which small teams outcompete large teams on the same market. For instance, the crypto exchange FTX with 150 employees rivals Coinbase and its 4115 employees. I admire how small groups of people have built incredible businesses."

Me reading that as I'm casually walking by FTX Arena, Miami right now.

haha FTX = small team but big adversiting budget!

> It often leads to what I call the "hiring death cycle." A startup faced with a problem tends to hire more people, making it harder to solve the problem and thus requiring even more hires. The death cycle is reinforced by the "next hire fallacy," in which, supposedly, the next recruit will suddenly solve the problem. It's common to fall into this vicious cycle and hard to break out of it.

Also here: https://en.wikipedia.org/wiki/The_Mythical_Man-Month

This phenomenon is more interesting to watch in a big IT department. Where various leaders try to get allocated more people, or slide in new management layers. I suppose the tendency to empire build is baked into us.

I'm also surprised at how little uniformity there is across companies. You would imagine sizes of teams would follow some ratio related to revenue, or percentage of all IT, etc. They don't. So the size of the IT Security Team, or Change Management, etc, vary wildly. Even for similar companies in the same industry.

I wonder how much infrastructure affects these calculations. In theory a company built on serverless resources should have much better revenue/employee, since a key premise of serverless is to replace headcount with a higher cloud bill. A saas company using expensive cloud services might look artificially more successful than one built with on-prem or more traditional cloud servers, if investors focus too much on employee specific costs.

The advantage to smaller teams is nimbleness; the advantage to larger teams is robustness to perturbations. These are not mutually exclusive, but in practice a small (nimble) and robust team is challenging to build since the balance of personalities and skills requires intent and access to amazing hiring opportunities.

HM: "We're definitely in startup mode, we've got a team of 400 employees, 150 of those in engineering..."

Me: (Cloud Strife voice) Not interested.

Based on a true story.

Shouldn't the calculation of the 'value' of the average employee be the annual profit divided by the number of employees, not revenue?

Also good to see if revenue can increase while adding few or no employees. Then the potential for flywheel is there, vs. an agency that scales costs linearly with revenue.

True! Some startups, unfortunately, have a scalability problem and need to scale headcount to increase the revenue proportionally.

Yes, it's another interesting metric. Although ideally, a fast-growing focuses on cash flows and reinvest all the cash so that there are no profits at the end of the year.

"average revenue per employee" is a fairly widely used metric even in non-startup companies. "Profit", GAAP or non-GAAP, is these days kind of a virtual number; Amazon have been hugely successful despite not "making a profit" in the traditional accounting sense.

However the article hints at what's really going on: in many startups the objective is to cash out before the question of profit has to be addressed. Many of these buyouts are "acquishutdowns" - the product has zero value and is shut down after a short transition, while the customers and staff are really what's being bought. In this sense the startup functions like an expensive recruitment agency or an inefficient version of the footballer transfer scheme.

In those cases it's advantageous to hire even if there is nothing profitable for the employees to do - because it increases the buyout value.

You're right; all these metrics can be easily manipulated, whereas revenue is more reliable.

I guess you're talking about "acqui-hire," meaning the acquisition of teams of 10-40 people for ~$25m. My broader point is that many startups scale to hundreds of employees, buying growth, but remain poor businesses. Headcount is a vanity metric similar to likes on social media or fundraising.

Growing a sales and marketing team can translate to a lot of revenue growth.

Yes, and as long that the revenue growth is higher than the cost, most startups should do it!

When looking at revenue / employee, in businesses where wages are the biggest cost (eg: software), that ratio also gives you a upper bound to how much you can pay employees and still be profitable.

In my book, revenue / employee is much more meaningful than profit / employee, because profit is arbitrary to a large extent.

+1 and I should have mentioned that there are significant disparities, say per country, of how much an employee costs.

Who asks their acquaintances for revenue numbers? Most employees at a small startup won't know anyway.

Reply on news.ycombinator.com