5 ms·

Are there really more than a few hundred people working on Threads? I believe Twitter had ~7,500 at its peak. Even if Threads succeeds, its not going to be bec

Are there really more than a few hundred people working on Threads? I believe Twitter had ~7,500 at its peak. Even if Threads succeeds, its not going to be because they have meaningfully more employees. Cloning twitter is a fairly easy technical problem nowadays... in contrast to early 2010s era of no-cloud, poor infra management and so on

martin8412 3y ago
A few hundreds working on a project within Meta. They won't have to take care of a lot of important things they'd have to if they were standalone.
whateverman23 3y ago
It's not really possible to say how many people are "working on" Threads, I bet. Threads is using Meta infrastructure. Should all those employees count towards Threads employees? How about HR? Legal? Internal tools? Building staff? Security? etc etc.
- adam_arthur 3y ago
  I'm not particularly interested in Twitter itself, I just disagree that many of the products we use today require a large number of developers. Its easy to find many examples of apps that were challenging to build even just 10 years ago, that are somewhat trivial now. That trend will only continue. OpenAI only had ~100 employees at one point. You don't need 100s of operations people if you move from on-prem to serverless, for example. Today, social media requires the most people in content moderation/support, rather than development. Tomorrow those people are likely to be supplanted by LLMs or similar more tailored AI moderation models. Many products that required 1000s of people 10 years ago, may only require 100s today. To me this is just a fact
  - whateverman23 3y ago
    I see it as four categories, from least employees to most: 1. Desperately trying to make short term cash, and are trying to do their best with fewer employees than needed to maintain the current product. (Twitter is here). 2. Enough staff to maintain the current product, but not significantly innovate. 3. Significantly more than needed to maintain the current product, leaving room for people to work on non-core products that may end up being the next billion dollar project, even if the vast majority flop (Most big tech companies are here). 4. Way too bloated, with not enough projects to work on or not enough revenue to justify the R&D. The problem is that outsiders have a really really hard time understanding the product complexity of half a billion+ user services. Comparing OpenAI to the social media sites that this HN post is talking about is a great example. It's a completely different product with completely different challenges than FB, twitter, threads, youtube, whatever. Another great example is people citing "day in the life" videos that are actually recruiting videos showing the brighter sides of the job. Or people citing employees who claim that the company hired them to do nothing, when in reality it's a recruiter that was hired shortly before hiring slowed.
    - adam_arthur 3y ago
      Do you agree or disagree that techproducts today are easier to build than 15 years ago? Everything else is irrelevant. Technology drives abstractions which drive deflation by allowing fewer people to produce more goods. This has been proven and observed for thousands of years Companies can thrive while overemploying people, but eventually they get undercut by one that doesn't
      - whateverman23 3y ago
        You're conflating two different topics: 1. "Its easy to find many examples of apps that were challenging to build even just 10 years ago, that are somewhat trivial now." Correct. It's easier now to build apps that we used 10-15 years ago. 2. "Do you agree or disagree that techproducts today are easier to build than 15 years ago?" Incorrect. Tech product complexity has increased in many ways in the last 15 years (and the increase in complexity is larger than the decrease in complexity we talked about above). -- Regulation. COPPA regulations strengthened significantly around 10 years ago. Europe's GDPR went into effect in like 2016. Those are just a couple popular ones. Remember when Amazon just didn't collect sales tax? Sure makes things easier! And remember, those laws are constantly changing. If NJ raises their sales tax, you better have someone paying attention. If Europe comes up with a new privacy law, you better have enough people to drop everything and implement everything that's needed. -- Scale + globalization. Myspace topped out at like 100 million active users around 15 years ago. Facebook is 30 times that size now! That scale comes with complexities most don't think about. How do you report user video ad income to the IRS-equivalent in Andorra? I don't know, but you now need to know at Facebook's scale!
        orwin 3y ago
        I'm automating network engineering. We still hire network engineers, and while scale/regulations are big reasons why, do not forget security. This can trigger entirety new projects. Some industries still transfer their driver updates in sealed, marked usb sticks to their clients. A lot of companies invested in IOT in the past 5 years, and just recently decided they wanted all their connected stuff to go through specific Cisco routers. Security is my SWE job security.
  - sroussey 3y ago
    > You don't need 100s of operations people if you move from on-prem to serverless, for example This statement really leaks a lack of experience with large systems. The efficiency loss for going to some serverless regime and the costs associated would be astronomical. My god…
  - rhaway84773 3y ago
    > I just disagree that many of the products we use today require a large number of developers. In a non competitive world this might be true (although I have my doubts). In a competitive free market world it isn’t because a competitor can then beat you by hiring more developers and delivering more features faster than you could. > Its easy to find many examples of apps that were challenging to build even just 10 years ago, that are somewhat trivial now. The consequence of this isn’t that people continue using those tiny apps. The consequence is that people’s expectations increase dramatically. There was a time Evernote was a Unicorn. Today, even though building a product like Evernote would still be fairly challenging, it’s considered a feature. > You don't need 100s of operations people if you move from on-prem to serverless, I have not yet, in practice, seen overall spend go down by moving to serverless. You may have fewer ops people, but you now need more devs to achieve the same work because a lot of ops has been shifted to devs. That being said, I’ve often seen serverless not even lead to a reduction in ops. > Many products that required 1000s of people 10 years ago, may only require 100s today. To me this is just a fact This does not come close to matching reality. In the late 90s early 2000s you and a handful of other devs could build a multimillion dollar product using Visual Basic which only ran on Windows and was distributed as a binary to be run by your clients and it would be a best in class product. Today, you would need a designer, web developers, and someone with experience in pushing it to production and securing it to simply build an MVP version that ran on browsers. In addition you would need another set of iOS developers and another set of Android developers. Heck, you may even need an Apple Watch and iPad app to be competitive. All of this would probably be required to simply make your app competitive, never mind best in class. What your comment appears to be missing is that with software development becoming easier, what changes most is an increase in customer expectations.
  - simmschi 3y ago
    At a certain scale you start to break many things that you're used to abstract away into a neat little box. This can be anything, from kernel, libraries, network stacks to anything running in the cloud. "Serverless" is not really an option at a certain scale. It's likely too expensive, but especially a giant risk if you abstract away something that can fail in an interesting way. I remember we once managed to break the AWS ELB in one AZ and had a nice little call with a dev from Seattle. Another time we managed to saturate EC2 in a zone at a certain time. You will need people who can dig into this. If you're at Twitter scale you'll probably want whole teams digging into aspects that you take for granted.
stubybubs 3y ago
Most of those 7500 were not engineers. They were moderators, sales, support, HR, etc The moderation, whatever people personally think of it now, has certainly suffered from an advertiser perspective, which is why they left. It was a mistake to fire many of them. The sales people with relationships to advertisers left, and so again did many advertisers. It's apparently impossible to get your account reinstated if you were banned, because there is no more support. People had pay issues due to lack of HR and also lost benefits, so they left. On top of that, almost all the features they shipped were in the works before the company was bought, so they didn't really ship anything. Stability was worse and users left. They are flocking to Threads because it's stable. Remaining devs continued to trickle away as the work environment became intolerable. Basically every aspect of his experiment was a failure. I'm sure Twitter could have cut 10-15% and been okay but what Musk did absolutely did not work. All those things managers talk about, those reasons to treat your people well: cratering morale after layoffs, increasing attrition, dead sea effect, loss of institutional knowledge, it's all true, and just what everyone expected. The only thing to learn from Twitter's fall is that they were right. Great experiment I guess? Really validated some things we had all seen small scale or intuited.
- adam_arthur 3y ago
  Twitter layoffs will have only "failed" due to creating a cultural divide and driving people to other services. Not due to the mechanical aspect of them Twitter laid off 80-90% of their people and the app functions the same. No material downtime in the year or so since the acquisition and feature velocity has only increased. Even if the features were in the pipeline already, none of them appeared over the 5-6 years preceding the acquisition. Highly coincidental, to the point of being suspect. Advertisers left due to taking sides on will of the moment cultural reasons, not because of moderation. The individuals behind advertising at many large corporations simply didn't want to help Elon. Would you want to give money to somebody you hated, and who loudly vocalized things that went strongly against your principles? This part is obvious to any objective observer. It's clear at this point that net added value per Twitter employee was low or even negative for many. If a company can layoff 90% of the developers and have no material change in availability or development velocity, then it's really inarguable otherwise
quitit 3y ago
In addition to the other points made by others about sharing staff... At their respective peaks Meta had around 12x the staff of peak Twitter despite not having 10x the user base (that said Meta towers heavily over Twitter in users and monthly accesses.) Even today Meta still has more than 10x the staff of peak Twitter. If anything you're highlighting that at ~7,500 staff Twitter was probably too thinly run.

martin8412 3y ago

A few hundreds working on a project within Meta. They won't have to take care of a lot of important things they'd have to if they were standalone.

whateverman23 3y ago

It's not really possible to say how many people are "working on" Threads, I bet. Threads is using Meta infrastructure. Should all those employees count towards Threads employees? How about HR? Legal? Internal tools? Building staff? Security? etc etc.

adam_arthur 3y ago
I'm not particularly interested in Twitter itself, I just disagree that many of the products we use today require a large number of developers. Its easy to find many examples of apps that were challenging to build even just 10 years ago, that are somewhat trivial now. That trend will only continue. OpenAI only had ~100 employees at one point. You don't need 100s of operations people if you move from on-prem to serverless, for example. Today, social media requires the most people in content moderation/support, rather than development. Tomorrow those people are likely to be supplanted by LLMs or similar more tailored AI moderation models. Many products that required 1000s of people 10 years ago, may only require 100s today. To me this is just a fact
- whateverman23 3y ago
  I see it as four categories, from least employees to most: 1. Desperately trying to make short term cash, and are trying to do their best with fewer employees than needed to maintain the current product. (Twitter is here). 2. Enough staff to maintain the current product, but not significantly innovate. 3. Significantly more than needed to maintain the current product, leaving room for people to work on non-core products that may end up being the next billion dollar project, even if the vast majority flop (Most big tech companies are here). 4. Way too bloated, with not enough projects to work on or not enough revenue to justify the R&D. The problem is that outsiders have a really really hard time understanding the product complexity of half a billion+ user services. Comparing OpenAI to the social media sites that this HN post is talking about is a great example. It's a completely different product with completely different challenges than FB, twitter, threads, youtube, whatever. Another great example is people citing "day in the life" videos that are actually recruiting videos showing the brighter sides of the job. Or people citing employees who claim that the company hired them to do nothing, when in reality it's a recruiter that was hired shortly before hiring slowed.
  - adam_arthur 3y ago
    Do you agree or disagree that techproducts today are easier to build than 15 years ago? Everything else is irrelevant. Technology drives abstractions which drive deflation by allowing fewer people to produce more goods. This has been proven and observed for thousands of years Companies can thrive while overemploying people, but eventually they get undercut by one that doesn't
    - whateverman23 3y ago
      You're conflating two different topics: 1. "Its easy to find many examples of apps that were challenging to build even just 10 years ago, that are somewhat trivial now." Correct. It's easier now to build apps that we used 10-15 years ago. 2. "Do you agree or disagree that techproducts today are easier to build than 15 years ago?" Incorrect. Tech product complexity has increased in many ways in the last 15 years (and the increase in complexity is larger than the decrease in complexity we talked about above). -- Regulation. COPPA regulations strengthened significantly around 10 years ago. Europe's GDPR went into effect in like 2016. Those are just a couple popular ones. Remember when Amazon just didn't collect sales tax? Sure makes things easier! And remember, those laws are constantly changing. If NJ raises their sales tax, you better have someone paying attention. If Europe comes up with a new privacy law, you better have enough people to drop everything and implement everything that's needed. -- Scale + globalization. Myspace topped out at like 100 million active users around 15 years ago. Facebook is 30 times that size now! That scale comes with complexities most don't think about. How do you report user video ad income to the IRS-equivalent in Andorra? I don't know, but you now need to know at Facebook's scale!
      - orwin 3y ago
        I'm automating network engineering. We still hire network engineers, and while scale/regulations are big reasons why, do not forget security. This can trigger entirety new projects. Some industries still transfer their driver updates in sealed, marked usb sticks to their clients. A lot of companies invested in IOT in the past 5 years, and just recently decided they wanted all their connected stuff to go through specific Cisco routers. Security is my SWE job security.
- sroussey 3y ago
  > You don't need 100s of operations people if you move from on-prem to serverless, for example This statement really leaks a lack of experience with large systems. The efficiency loss for going to some serverless regime and the costs associated would be astronomical. My god…
- rhaway84773 3y ago
  > I just disagree that many of the products we use today require a large number of developers. In a non competitive world this might be true (although I have my doubts). In a competitive free market world it isn’t because a competitor can then beat you by hiring more developers and delivering more features faster than you could. > Its easy to find many examples of apps that were challenging to build even just 10 years ago, that are somewhat trivial now. The consequence of this isn’t that people continue using those tiny apps. The consequence is that people’s expectations increase dramatically. There was a time Evernote was a Unicorn. Today, even though building a product like Evernote would still be fairly challenging, it’s considered a feature. > You don't need 100s of operations people if you move from on-prem to serverless, I have not yet, in practice, seen overall spend go down by moving to serverless. You may have fewer ops people, but you now need more devs to achieve the same work because a lot of ops has been shifted to devs. That being said, I’ve often seen serverless not even lead to a reduction in ops. > Many products that required 1000s of people 10 years ago, may only require 100s today. To me this is just a fact This does not come close to matching reality. In the late 90s early 2000s you and a handful of other devs could build a multimillion dollar product using Visual Basic which only ran on Windows and was distributed as a binary to be run by your clients and it would be a best in class product. Today, you would need a designer, web developers, and someone with experience in pushing it to production and securing it to simply build an MVP version that ran on browsers. In addition you would need another set of iOS developers and another set of Android developers. Heck, you may even need an Apple Watch and iPad app to be competitive. All of this would probably be required to simply make your app competitive, never mind best in class. What your comment appears to be missing is that with software development becoming easier, what changes most is an increase in customer expectations.
- simmschi 3y ago
  At a certain scale you start to break many things that you're used to abstract away into a neat little box. This can be anything, from kernel, libraries, network stacks to anything running in the cloud. "Serverless" is not really an option at a certain scale. It's likely too expensive, but especially a giant risk if you abstract away something that can fail in an interesting way. I remember we once managed to break the AWS ELB in one AZ and had a nice little call with a dev from Seattle. Another time we managed to saturate EC2 in a zone at a certain time. You will need people who can dig into this. If you're at Twitter scale you'll probably want whole teams digging into aspects that you take for granted.

stubybubs 3y ago

Most of those 7500 were not engineers. They were moderators, sales, support, HR, etc The moderation, whatever people personally think of it now, has certainly suffered from an advertiser perspective, which is why they left. It was a mistake to fire many of them. The sales people with relationships to advertisers left, and so again did many advertisers. It's apparently impossible to get your account reinstated if you were banned, because there is no more support. People had pay issues due to lack of HR and also lost benefits, so they left. On top of that, almost all the features they shipped were in the works before the company was bought, so they didn't really ship anything. Stability was worse and users left. They are flocking to Threads because it's stable. Remaining devs continued to trickle away as the work environment became intolerable. Basically every aspect of his experiment was a failure. I'm sure Twitter could have cut 10-15% and been okay but what Musk did absolutely did not work. All those things managers talk about, those reasons to treat your people well: cratering morale after layoffs, increasing attrition, dead sea effect, loss of institutional knowledge, it's all true, and just what everyone expected. The only thing to learn from Twitter's fall is that they were right. Great experiment I guess? Really validated some things we had all seen small scale or intuited.

adam_arthur 3y ago
Twitter layoffs will have only "failed" due to creating a cultural divide and driving people to other services. Not due to the mechanical aspect of them Twitter laid off 80-90% of their people and the app functions the same. No material downtime in the year or so since the acquisition and feature velocity has only increased. Even if the features were in the pipeline already, none of them appeared over the 5-6 years preceding the acquisition. Highly coincidental, to the point of being suspect. Advertisers left due to taking sides on will of the moment cultural reasons, not because of moderation. The individuals behind advertising at many large corporations simply didn't want to help Elon. Would you want to give money to somebody you hated, and who loudly vocalized things that went strongly against your principles? This part is obvious to any objective observer. It's clear at this point that net added value per Twitter employee was low or even negative for many. If a company can layoff 90% of the developers and have no material change in availability or development velocity, then it's really inarguable otherwise

quitit 3y ago

In addition to the other points made by others about sharing staff... At their respective peaks Meta had around 12x the staff of peak Twitter despite not having 10x the user base (that said Meta towers heavily over Twitter in users and monthly accesses.) Even today Meta still has more than 10x the staff of peak Twitter. If anything you're highlighting that at ~7,500 staff Twitter was probably too thinly run.