Snap is laying off about 100 engineers(cnbc.com)
cnbc.com
Snap is laying off about 100 engineers
https://www.cnbc.com/2018/03/07/snap-layoffs-engineering-team-said-to-see-up-to-10-percent-cut.html
138 comments
> I'm honestly curious if the massive headcount of some of these companies is even necessary.
Patrick Collison (Stripe) talks about this in Blitzscaling and how this is often severely underestimated. He says it takes a lot less engineering to build the original product/service than to maintain it and operate it at scale. There is value in running a lean operation and there is probably some level of bloat in human resources across organizations; but dismissing the reality of necessity within these organizations should only be done carefully. I think the context PC was talking about was speed of feature creation/product shipping but conceptually the same thing holds for the size of the company.
[0] https://www.youtube.com/watch?v=qrDZhAxpKrQ
Patrick Collison (Stripe) talks about this in Blitzscaling and how this is often severely underestimated. He says it takes a lot less engineering to build the original product/service than to maintain it and operate it at scale. There is value in running a lean operation and there is probably some level of bloat in human resources across organizations; but dismissing the reality of necessity within these organizations should only be done carefully. I think the context PC was talking about was speed of feature creation/product shipping but conceptually the same thing holds for the size of the company.
[0] https://www.youtube.com/watch?v=qrDZhAxpKrQ
Yeah, I think it's important to stress that.
Building an application is easy. Maintaining it, adding features, scaling it, integrating with other services, building platforms… those activities all take a lot of other work.
I work at a small company whose core product was developed primarily by one or two developers. We now have substantially the same functionality with an engineering team of ~13, but constantly have a huge amount of work we want to do. Things like scaling, refactoring legacy code, paying down technical debt, handling complex and tricky edge cases that could previously be glossed over, and building administration tools – these take up _phenomenal_ amounts of time, especially if you want to work at a sustainable pace. I can totally believe that larger software houses need a surprising number of engineers.
Building an application is easy. Maintaining it, adding features, scaling it, integrating with other services, building platforms… those activities all take a lot of other work.
I work at a small company whose core product was developed primarily by one or two developers. We now have substantially the same functionality with an engineering team of ~13, but constantly have a huge amount of work we want to do. Things like scaling, refactoring legacy code, paying down technical debt, handling complex and tricky edge cases that could previously be glossed over, and building administration tools – these take up _phenomenal_ amounts of time, especially if you want to work at a sustainable pace. I can totally believe that larger software houses need a surprising number of engineers.
I worked in teams maintaining large projects and I also built (and maintained) a few ones myself after starting my own business, so I can sort of compare. I'd say it's a matter of risk management.
When 1 or 2 people are building a project, making decisions is easy. You consider the options, you pick a strategy and you're the one to blame if it fails. If that happens, you pick up the pieces and try to pivot, but you're still in charge.
When you introduce more people to the process of decision making (even on low engineering levels), it creates a massive political overhead. People compete for visibility, so they will propose ideas even if they don't make much sense strategically. People have feelings, so they will often support ideas of their friends and dismiss the ideas of their enemies regardless of the business impact. People don't want to be responsible for failure, so they will often create lots of unnecessary low risk/low impact work instead of taking risks. So there will be indeed a lot of extra work, but in many cases the customers won't notice the difference.
The upside of this is fault tolerance - if one of the 2 co-founders leaves a company, it is doomed. If the same work is done by a team of 13, you can fire and easily replace 1-4 of them without much impact and investors generally like that.
When 1 or 2 people are building a project, making decisions is easy. You consider the options, you pick a strategy and you're the one to blame if it fails. If that happens, you pick up the pieces and try to pivot, but you're still in charge.
When you introduce more people to the process of decision making (even on low engineering levels), it creates a massive political overhead. People compete for visibility, so they will propose ideas even if they don't make much sense strategically. People have feelings, so they will often support ideas of their friends and dismiss the ideas of their enemies regardless of the business impact. People don't want to be responsible for failure, so they will often create lots of unnecessary low risk/low impact work instead of taking risks. So there will be indeed a lot of extra work, but in many cases the customers won't notice the difference.
The upside of this is fault tolerance - if one of the 2 co-founders leaves a company, it is doomed. If the same work is done by a team of 13, you can fire and easily replace 1-4 of them without much impact and investors generally like that.
I'd say the risk management is bigger than that. If you have 10 customers and cock something up, that's 10 people affected. But with a million customers, the same cock-up causes 100,000 times as much damage and might cost 100,000 times as much money. So you can spend something closer to factor more to reduce the likelihood of it happening by up to 100,000 times.
I don't think the only side effect of this type of inefficiency is increased costs. I would love to see some scientific research on it, but my hunch from working in overstaffed companies suggests that if you don't let people self-actualize through taking responsibilities and putting their ego into the problems they solve, they start self-actualizing in office politics, creating a toxic environment and ultimately making the company incapable of smart decisions. Modern work culture does a pretty good job hiding it behind a thick layer of company values, virtue signalling and multiple-page integrity policies though.
Besides, you can actually mitigate the cock-up risks without going crazy on your head count: have focus groups, beta testers, roll out updates gradually, have a clear separation of layers and a mechanism to roll back a breaking change, etc.
Besides, you can actually mitigate the cock-up risks without going crazy on your head count: have focus groups, beta testers, roll out updates gradually, have a clear separation of layers and a mechanism to roll back a breaking change, etc.
Additionally, adding support for advertising at scale is a massively complex effort, and usually invisible to outsiders.
It's one thing to build a WhatsApp-type app, focusing 100% of your energy on the core messaging functionality itself, and little else.
It's a completely different thing to build a revenue-generating business that needs to connect with an entire ecosystem of advertisers, ad servers, video servers, programmatic ad exchanges, analytics, brand safety, reporting, billing systems, and a lot more.
And we're not even talking about services. There's another big layer of complexity to keep those services running 24x7 (well beyond just SREs), ensuring ads are running properly, campaigns are fully optimized, advertisers are happy with what they're getting, etc.
It's one thing to build a WhatsApp-type app, focusing 100% of your energy on the core messaging functionality itself, and little else.
It's a completely different thing to build a revenue-generating business that needs to connect with an entire ecosystem of advertisers, ad servers, video servers, programmatic ad exchanges, analytics, brand safety, reporting, billing systems, and a lot more.
And we're not even talking about services. There's another big layer of complexity to keep those services running 24x7 (well beyond just SREs), ensuring ads are running properly, campaigns are fully optimized, advertisers are happy with what they're getting, etc.
Why not outsource the complex ad work to a company that specializes in it? Why not use Google's DFP platform for instance?
When building an advertising platform that can potentially compete with Google, it's best to not put your entire revenue stream under the control of Google.
> Additionally, adding support for advertising at scale is a massively complex effort...
My interpretation of the GP's comment is that the advertising platform is not the core business but rather a secondary concern. Focus on your core business and outsource the rest.
My interpretation of the GP's comment is that the advertising platform is not the core business but rather a secondary concern. Focus on your core business and outsource the rest.
In that case, I agree with you that outsourcing is a good way to go. However, it should be stressed that the "core business" needs to be the core revenue generating portion of the business. I don't care if your company is dedicated towards making "the best photo sharing/social media/experience sharing platform for users". If at the end of the day your bills are being paid by advertisers, you're an advertising company and are in direct competition with Google.
Supply side platforms take a pretty big cut of the overall revenue, and are often very focused on existing formats like text and video. You’d be losing out on a huge chunk of advertising dollars both from the SSP cut as well as not getting optimal pricing because you’re bidding in the wrong market.
Of course ideally the question would be “why not just have users pay you directly instead of relentlessly monetizing every bit of personal information you can squeeze out of them” but as an industry unfortunately it doesn’t seem like we’re there yet.
Of course ideally the question would be “why not just have users pay you directly instead of relentlessly monetizing every bit of personal information you can squeeze out of them” but as an industry unfortunately it doesn’t seem like we’re there yet.
An army of full time employees ain't cheap either. I imagine your ad business would have to be very large to justify the investment, especially if building & supporting an ad platform is not your core business.
Not to mention that you just can't break things anymore once you have millions of users on your app. You have to move very carefully.
It also adds human redundancy and specialization, both of which reduce risk for a company. In the "product/market fit" words, before fit, a company is all risk. After fit, during growth and long term profit extraction, companies try to reduce risk as much as possible (and optimize for greater margins/efficiency).
Is there an example of a million-user/big B2B company built entirely on top of FAAS like AWS Lambda and some lind of database with auto scaling, sharding et al. (maybe Spanner or CockroachDB [0])? I suspect once somethink like that happens we could have companies that have almost Google scale while just employing a couple of engineers.
[0] As a side note, I'm sure a blueprint for handling the common DB scaling problem. I suppose we could train a ML model to read some logs/usage stats and handle the remainder of edge cases. But making such a model will probably require hundreds of engineers so I guess we're safe at the moment.
[0] As a side note, I'm sure a blueprint for handling the common DB scaling problem. I suppose we could train a ML model to read some logs/usage stats and handle the remainder of edge cases. But making such a model will probably require hundreds of engineers so I guess we're safe at the moment.
Snapchat and Nextdoor are great examples. The former runs most infra on Google App Engine, and the latter runs primarily on AWS.
Snapchat was built on Google App Engine, so they're probably one of the best large scale examples of this.
This is true, and really one of the more mysterious things about the headcount. This should be an example of how to keep an organization lean as it scales. I wonder why it isn't.
[deleted]
I think it’s important to remember that this is all happening in the context of easily raising huge amounts of VC money at incredibly high valuations. If a company was looking to raise money say 10 years ago when, all corporate metrics being equal, their valuation would have been half or even less than what it is today and it was much more difficult to secure funds, the mindset about headcount would likely be different.
Unfortunately, the mindset of ordinary people is reflected clearly in OP's confusion.
What exactly do all of these engineers do at single-focus companies like Snap? I guess I don't understand where you could find enough work for hundreds of engineers on a product like that?
I think there are two acceptable answers in addition from the obvious possibility of bad management.
1. Many engineers do not work on core products. Many of these companies operate like quasi accelerators at times: hire smart engineers since you can afford it, hire a few good PMs, see what happens, then market the most promising results. Twitter had Vine, Snap had Spectacles, and maybe one of the best examples of this is Amazon. They didn't need thousands of engineers to run an e-commerce site, but they did need them to build out a cloud, and Alexa, and a video streaming service, etc. Other companies want to replicate this model.
2. Scale is hard. As soon as you hit a limit of what off the shelf software or current open source offerings can do, you have a hard problem on your hands. There are certainly more 'web scale' products that exist now to make this process easier for startups, but it can still happen. It's also possible that even if there are products that can scale, it would end up being cheaper to spin up a large team of good engineers to replicate a commercial offering if you're optimistic about the companies growth.
1. Many engineers do not work on core products. Many of these companies operate like quasi accelerators at times: hire smart engineers since you can afford it, hire a few good PMs, see what happens, then market the most promising results. Twitter had Vine, Snap had Spectacles, and maybe one of the best examples of this is Amazon. They didn't need thousands of engineers to run an e-commerce site, but they did need them to build out a cloud, and Alexa, and a video streaming service, etc. Other companies want to replicate this model.
2. Scale is hard. As soon as you hit a limit of what off the shelf software or current open source offerings can do, you have a hard problem on your hands. There are certainly more 'web scale' products that exist now to make this process easier for startups, but it can still happen. It's also possible that even if there are products that can scale, it would end up being cheaper to spin up a large team of good engineers to replicate a commercial offering if you're optimistic about the companies growth.
I agree with your points! Just thought I'd lyk though that Vine was an acquisition, not a Twitter-born project.
There's tonnes of examples backing up your first point though, 100% accurate.
There's tonnes of examples backing up your first point though, 100% accurate.
Also as a codebase grows the complexity grows. Adding or changing code has a lot more impact and is much harder.
If I remember correctly Shopify is something like 400k lines of Ruby on Rails code and 400 developers (i.e. one developer per 1000 LOC). Whereas I guess a 5k LOC codebase could be handled by a single developer.
If I remember correctly Shopify is something like 400k lines of Ruby on Rails code and 400 developers (i.e. one developer per 1000 LOC). Whereas I guess a 5k LOC codebase could be handled by a single developer.
5k LOC is well in the realm of a toy project.
400k LOC can easily be handled by an handful of people and with some effort by a single very capable engineer.
Ooooo, not 1000 LOC.
That's a couple of weeks work.
EDIT: I'm being flippant, but to me a 400k code base is something 2 devs can put out in a few years. I'm pretty certain the present main code base I'm working on must be close to 400k and it's only ever had 2 devs working on it at any one time.
And we're always adding massive chunks of new functionality, and are regularly integrating with new third parties. And we total overhauled it last year to support i18n and it's now being regularly used in 3 languages and we can add more in literally a couple of days.
Ok it only handles hundreds of thousands of users, but I expect it to be millions within a couple of years and we're not even trying to load balance or anything yet.
That's a couple of weeks work.
EDIT: I'm being flippant, but to me a 400k code base is something 2 devs can put out in a few years. I'm pretty certain the present main code base I'm working on must be close to 400k and it's only ever had 2 devs working on it at any one time.
And we're always adding massive chunks of new functionality, and are regularly integrating with new third parties. And we total overhauled it last year to support i18n and it's now being regularly used in 3 languages and we can add more in literally a couple of days.
Ok it only handles hundreds of thousands of users, but I expect it to be millions within a couple of years and we're not even trying to load balance or anything yet.
There are so many features in the Snapchat app. If you really dig in, there are teams dedicated to each portion of the app. I'm not sure if that means a bunch of separate PMs as well, but it is a big complex app once you account for all the features... DMs, group messages, Discover, Memories, Stories, the map, filters/lenses, integrations like Bitmoji, ...
Still doesn't justify anywhere close to 1000 engineers.
I think a lot of the engineers are working on new filters.
Then a bunch are working on 'location based promoted filters", these are basically just graphic designers, or maybe web designers, but they are getting lumped in.
Then a bunch are working on 'location based promoted filters", these are basically just graphic designers, or maybe web designers, but they are getting lumped in.
I think about R&D. Rolling out experiments takes teams with different focuses.
Oh come on, 1800 employees!?
The majority of employees at advertising-based companies are employed in selling advertising and supporting the people who sell advertising. Outside of Google and Facebook scale it is still a very high touch process.
Sales people, biz dev, PR, recruiting, legal, content creation, headcount from acquisitions like Bitmoji, support team, data team to make sense of the massive amount of data coming in, marketing team, etc etc etc.
You need these things to run a global operation at scale.
If you're not interested in running a global operation at scale, then you can be happy running a little self-serve application - but to create the phenomenon that is SnapChat requires a lot of coordinated effort. To think otherwise is just simply naive.
Now I don't think we have enough information to judge if 1800 is the wrong number for SnapChat or not. They very well may be overstaffed.
You need these things to run a global operation at scale.
If you're not interested in running a global operation at scale, then you can be happy running a little self-serve application - but to create the phenomenon that is SnapChat requires a lot of coordinated effort. To think otherwise is just simply naive.
Now I don't think we have enough information to judge if 1800 is the wrong number for SnapChat or not. They very well may be overstaffed.
Valve has 1/6th of that, develops games, and provides the entire worlds distribution of PC games. 1800+ is ridiculous, and clearly the wrong number, since they are laying off people.
@overcast
> develops games
Not in a long time. They're practically in maintenance mode with their games, DOTA 2 being the exception. Most of the creative talent there (people who worked on Half-Life, Portal, etc) has retired.
> develops games
Not in a long time. They're practically in maintenance mode with their games, DOTA 2 being the exception. Most of the creative talent there (people who worked on Half-Life, Portal, etc) has retired.
[deleted]
Sure, but they must have 200-300 people actively developing hats.
It's actually very little work to maintain Steam once the core functionality is there.
Valve is actually a good example of a company that's now incapable of doing anything really ambitious that has real demand. You know, like Half Life 3...
Valve is actually a good example of a company that's now incapable of doing anything really ambitious that has real demand. You know, like Half Life 3...
It seems the only work left is to continually make the store page even busier and harder to use.
There's the business-facing products too; dashboards, analytics, insights, content curation, etc. tools for advertisers.
Not to mention internal engineering too, from dev-ops and platform to potentially even custom HR tools.
Again, not saying they're not overstaffed. But a lot of people seem to forget about the internal teams supporting other engineers/employees.
Not to mention internal engineering too, from dev-ops and platform to potentially even custom HR tools.
Again, not saying they're not overstaffed. But a lot of people seem to forget about the internal teams supporting other engineers/employees.
Let's not forget designers, illustrators, accounting, onsite-building security, benefits people, account managers, mid level managers, execs, advisors...
Instagram got pretty far with their initial 13 employees.
They got far but less than you think. They had 30mm users mostly in the US (versus nearly 1 billion today all over the world), no monetization operations in place, no biz dev deals, no data deals, not truly international, iPhone only, a far far more limited feature set, very little content moderation or community support in place, very little anti-spam measures, far less security, etc
[deleted]
I once worked at a very successful company that had hundreds of millions of dollars in worldwide business.
The employee count was like 260.
The employee count was like 260.
That's fine, but what's your actual point? That it's broadly possible to make money in the world with less headcount than 1800?
I'm sure there are hedge funds out there with only 100 employees and $30 billion under management.
That has nothing to do with anything.
I'm sure there are hedge funds out there with only 100 employees and $30 billion under management.
That has nothing to do with anything.
Hedge funds?
We were a software company, the only thing we shipped was software. We shipped a hell of a lot more code than Snapchat. We had many products, some fairly complex. We even developed a bunch of internal tools as well.
I obviously wouldn't be comparing the head count of a financial management company with a software company.
We were a software company, the only thing we shipped was software. We shipped a hell of a lot more code than Snapchat. We had many products, some fairly complex. We even developed a bunch of internal tools as well.
I obviously wouldn't be comparing the head count of a financial management company with a software company.
But still, compare this with ARM, who develop both CPUs, GPUs, and tons of other silicon IP that runs most of our digital world. They currently have around 4000 employees in total.
Is that a fair comparison? I'm actually asking, I don't know anything about CPU development. It just seems like it's a different kind of work entirely.
Once you introduce advertising, you have to hire an army of engineers, biz devs, ad ops, revenue folks, accounting, finance, sales folks to manage that business. The ad business seems so complex with so many players.
If I had to hazard a guess, it would be that most engineers aren't that productive. It's easy to fill your day with non-important ditch-digging to look busy, and it takes a certain level of critical thinking to cut through the bullshit and get stuff done.
So companies have to continue hiring until they find that magical person who manages to do the work of 10 people. Some companies get lucky and find 5 of these people right off the bat, others, not so much.
It could also be the engineering culture. All it takes is a couple of lazy developers and the laziness culture beings to propagate to the rest of the company. One or two people being wishy-washy about delivery dates and meeting times will send the message to the rest of the team that it's ok for you to also be wishy-washy with these things. Management doesn't always think there's a culture problem, so they just increase headcount thinking that productivity directly correlates to headcount.
It's not fair to fully blame engineering for this. If the company doesn't have a strong engineering voice, you will get handed ridiculous requirements and specifications and yes, you'll need 50 more developers so you can meet the needs of the picky lead designer who wants pixel perfect function on every device ever created for every language for any feature.
All that being said, when a company is doing well, the executives and shareholders shout "Hire baby, hire" and so the machine brings on capacity with no real goal, other than expansion for its own sake.
So companies have to continue hiring until they find that magical person who manages to do the work of 10 people. Some companies get lucky and find 5 of these people right off the bat, others, not so much.
It could also be the engineering culture. All it takes is a couple of lazy developers and the laziness culture beings to propagate to the rest of the company. One or two people being wishy-washy about delivery dates and meeting times will send the message to the rest of the team that it's ok for you to also be wishy-washy with these things. Management doesn't always think there's a culture problem, so they just increase headcount thinking that productivity directly correlates to headcount.
It's not fair to fully blame engineering for this. If the company doesn't have a strong engineering voice, you will get handed ridiculous requirements and specifications and yes, you'll need 50 more developers so you can meet the needs of the picky lead designer who wants pixel perfect function on every device ever created for every language for any feature.
All that being said, when a company is doing well, the executives and shareholders shout "Hire baby, hire" and so the machine brings on capacity with no real goal, other than expansion for its own sake.
To Snapchat's credit they did pull off some amazing features with that surge of investment money. The facial recognition/filters they built was truly innovative and very advanced. The engineers involved in that were undeniably exceptional.
I think a better contrast is Twitter. Thousands of employees and it feels almost nothing in terms of new features to show for it, minus changing a star over to a heart... (which btw, reportedly took two years to implement once the idea came about...)
I think a better contrast is Twitter. Thousands of employees and it feels almost nothing in terms of new features to show for it, minus changing a star over to a heart... (which btw, reportedly took two years to implement once the idea came about...)
Maybe on features that get aborted on each change of corporate strategy (my supposition)?
It's also really easy to knock out a MVP that replicates 80% of snapchat features, but the real problem is getting the scale right, as conventional social networks are worthless without a huge pool of eyeballs for precisely targeted ads.
While I'm at it, I'd like to plant the thought that Social might be a perfect place for disruption again, but now with a non-profit/public strategy. Maybe with a huge initial donation it's more than enough as incremental user costs are minimal if we don't spend money optimizing for engagement and ads and use some decentralized tech lime swarm/ipfs, but that's for another time.
Also the weird corner cases in different platforms and the huge technical debt in most startups seem to sap a lot of energy.
It's also really easy to knock out a MVP that replicates 80% of snapchat features, but the real problem is getting the scale right, as conventional social networks are worthless without a huge pool of eyeballs for precisely targeted ads.
While I'm at it, I'd like to plant the thought that Social might be a perfect place for disruption again, but now with a non-profit/public strategy. Maybe with a huge initial donation it's more than enough as incremental user costs are minimal if we don't spend money optimizing for engagement and ads and use some decentralized tech lime swarm/ipfs, but that's for another time.
Also the weird corner cases in different platforms and the huge technical debt in most startups seem to sap a lot of energy.
Probably the Glasses and everything related to that? I don't think those were profitable so maybe it could be their hardware division.
Definitely not core dev. Mostly IP harvesting/research and "ops"
My previous employer had way more than 10000 software developers. There was some justification for many engineers given the size of the business in that they did business in many different countries, owned many different brands, and had a major division that was completely divested.
Those qualities are completely valid business justifications for the swell, but the swell was largely unnecessary. If the technology were written well and scaled appropriately they could have easily gotten by with several hundred developers.
The most immediate problem in that industry is legacy technology. The technology is universally Java and it is often poorly written. Java is bloated enough on its own, required boilerplate, but bad software forces a multiplicative effect. Maintenance takes far more effort than originally authoring software in the first place, so a legacy Java application that is still being enhanced with new features can be scary massive.
Worse still is that this was a web-based business and historically very few people have understood web technologies well. If you go back far enough you will find that JavaScript was too slow to do anything and nobody took HTML seriously, so absolutely everything ends up in Java. Java isn't a web technology and would induce rabid insecurity into crappy developers who spent way too much on their education to qualify their insecurities. You quickly end up with really crappy code and needing 5-10x people to maintain it.
Eventually JavaScript got fast, so the business had the bright idea to offload everything in JavaScript. In the past nobody (well very few) wrote JavaScript well, because web technologies were slow and nobody took them seriously. Now there are still very few people who understand web technologies well and everybody else lives behind multiple frameworks and abstraction layers.
The horrid bloat before you had with Java... well now you have that in JavaScript too but you are continuing to develop and maintain on both sides of the fence so you need thousands of engineers just to keep the lights on. Oh, but wait it gets worse.
By now you should be asking yourself how the hell there are so many bad developers in the world and why hasn't the big corporation solved the bad developer problem. It is in their financial interest to solve this problem.... right? No, this is a cultural problem in the corporate world and so long as profit outpaces spend there isn't any financial incentive to fix anything particularly when fixes carry risks.
That cultural problem is that training and mentoring are rare in the corporate world. Furthermore, most developers aren't properly motivated to want to improve substantially enough to solve for valid business concerns. You have to understand that programming is a skill and like any skill the only valid discriminator of competence is deliberate practice (developers with initiative to takes risks to do innovating things). Most developers DO NOT want to take risks. They want to be employed.
Many developers want to go to work to perform only assigned tasks in their comfort zone, like in a factory, and then immediately turn their brains off as they go home according to a set time-frame. Personally, I would rather earn more money and have the freedom to easily move between employers if the need arises, which is only a common reality if you are more competent (more skilled) than other developers.
Ok, so, many developers suck because they aren't motivated to do wonderful things, and therefore you need A LOT of developers to compensate for the bad code (and as they continue to write bad code). The next logical question is why aren't the big corporations doing a better job of motivating their people.
Counter-intuitively, this problem is not solved by increasing compensation. If you increase compensation under the agreement that teams of developers will solve drastically more ambitious problems in more original (innovative) ways you are introducing risk to the developers' career. What happens in the case where a developer accepts higher compensation and yet fails to perform to the higher expectations? Remember that most developers want to keep their jobs. Employment is almost universally preferred to increased compensation others everybody would be entrepreneurs and nobody would be employees.
People capable of appreciating and accepting risks are self-motivated. This means such people tend to identify risks with their own initiative and are self-motivated to solve for the risk without awareness of an immediate reward. This is where increased practice becomes important and the resulting benefits aren't immediately clear, such as increased job security or a future promotion. This is also a behavioral quality much of the corporate world isn't willing to produce, so they leave it to the marketplace. Increased risk acceptance isn't the sort of quality that drives favorable annual reviews in much of the corporate world, as annual reviews reward quantitative performance metrics.
Talented people (people with the proper combination of practice, personality, and accomplishment) are rare and they take time to produce. It is so much cheaper to hire 5 times the crappy developers at 15 times the price than to wait for the golden unicorn to appear when you have work that needs to be performed RIGHT NOW. At least that is the common perception. There is also the common perception that many hands make light work.
I am of the mind that technology failures don't exist. There are only natural disasters and really bad decisions. One person's bad decision is another person's comfort blanket.
Those qualities are completely valid business justifications for the swell, but the swell was largely unnecessary. If the technology were written well and scaled appropriately they could have easily gotten by with several hundred developers.
The most immediate problem in that industry is legacy technology. The technology is universally Java and it is often poorly written. Java is bloated enough on its own, required boilerplate, but bad software forces a multiplicative effect. Maintenance takes far more effort than originally authoring software in the first place, so a legacy Java application that is still being enhanced with new features can be scary massive.
Worse still is that this was a web-based business and historically very few people have understood web technologies well. If you go back far enough you will find that JavaScript was too slow to do anything and nobody took HTML seriously, so absolutely everything ends up in Java. Java isn't a web technology and would induce rabid insecurity into crappy developers who spent way too much on their education to qualify their insecurities. You quickly end up with really crappy code and needing 5-10x people to maintain it.
Eventually JavaScript got fast, so the business had the bright idea to offload everything in JavaScript. In the past nobody (well very few) wrote JavaScript well, because web technologies were slow and nobody took them seriously. Now there are still very few people who understand web technologies well and everybody else lives behind multiple frameworks and abstraction layers.
The horrid bloat before you had with Java... well now you have that in JavaScript too but you are continuing to develop and maintain on both sides of the fence so you need thousands of engineers just to keep the lights on. Oh, but wait it gets worse.
By now you should be asking yourself how the hell there are so many bad developers in the world and why hasn't the big corporation solved the bad developer problem. It is in their financial interest to solve this problem.... right? No, this is a cultural problem in the corporate world and so long as profit outpaces spend there isn't any financial incentive to fix anything particularly when fixes carry risks.
That cultural problem is that training and mentoring are rare in the corporate world. Furthermore, most developers aren't properly motivated to want to improve substantially enough to solve for valid business concerns. You have to understand that programming is a skill and like any skill the only valid discriminator of competence is deliberate practice (developers with initiative to takes risks to do innovating things). Most developers DO NOT want to take risks. They want to be employed.
Many developers want to go to work to perform only assigned tasks in their comfort zone, like in a factory, and then immediately turn their brains off as they go home according to a set time-frame. Personally, I would rather earn more money and have the freedom to easily move between employers if the need arises, which is only a common reality if you are more competent (more skilled) than other developers.
Ok, so, many developers suck because they aren't motivated to do wonderful things, and therefore you need A LOT of developers to compensate for the bad code (and as they continue to write bad code). The next logical question is why aren't the big corporations doing a better job of motivating their people.
Counter-intuitively, this problem is not solved by increasing compensation. If you increase compensation under the agreement that teams of developers will solve drastically more ambitious problems in more original (innovative) ways you are introducing risk to the developers' career. What happens in the case where a developer accepts higher compensation and yet fails to perform to the higher expectations? Remember that most developers want to keep their jobs. Employment is almost universally preferred to increased compensation others everybody would be entrepreneurs and nobody would be employees.
People capable of appreciating and accepting risks are self-motivated. This means such people tend to identify risks with their own initiative and are self-motivated to solve for the risk without awareness of an immediate reward. This is where increased practice becomes important and the resulting benefits aren't immediately clear, such as increased job security or a future promotion. This is also a behavioral quality much of the corporate world isn't willing to produce, so they leave it to the marketplace. Increased risk acceptance isn't the sort of quality that drives favorable annual reviews in much of the corporate world, as annual reviews reward quantitative performance metrics.
Talented people (people with the proper combination of practice, personality, and accomplishment) are rare and they take time to produce. It is so much cheaper to hire 5 times the crappy developers at 15 times the price than to wait for the golden unicorn to appear when you have work that needs to be performed RIGHT NOW. At least that is the common perception. There is also the common perception that many hands make light work.
I am of the mind that technology failures don't exist. There are only natural disasters and really bad decisions. One person's bad decision is another person's comfort blanket.
Building a product isn't that hard.
But you also want:
- A product upon which you can build on more features while maintaining 100% uptime and remain mostly bug-free
- Build up ad infrastructure with real-time data and bidding
- Instrument everything
- Consume all that instrumentation to make product/business decisions
- Feed all that instrumentation into your ad infrastructure
- Optimize all of the above
- Have all of the above secure
Or you could do none of that, but then you won't be the next Facebook.
But you also want:
- A product upon which you can build on more features while maintaining 100% uptime and remain mostly bug-free
- Build up ad infrastructure with real-time data and bidding
- Instrument everything
- Consume all that instrumentation to make product/business decisions
- Feed all that instrumentation into your ad infrastructure
- Optimize all of the above
- Have all of the above secure
Or you could do none of that, but then you won't be the next Facebook.
In comparison, Valve has 360 people (2016) and they do a lot. [0]
[0] https://www.pcgamer.com/valve-misses-deadline-to-respond-to-...
[0] https://www.pcgamer.com/valve-misses-deadline-to-respond-to-...
> and they do a lot
That's extremely generous. They update the client in imperceptible ways every few hours, and they push CS:GO patches every few months. Not sure what everyone's doing over there, but it's not "a lot".
That's extremely generous. They update the client in imperceptible ways every few hours, and they push CS:GO patches every few months. Not sure what everyone's doing over there, but it's not "a lot".
Steam does several billion dollars in sales each year. Just maintaining that alone must take a significant portion of their 300+ employees.
Steam team size is apparently 10. [0] (2017)
[0] https://www.youtube.com/watch?v=d3bQpF16vnE&feature=youtu.be...
Took me around 20 min to find this reference again... I don't think they only talk about a content management team here as the organization is quite flat at Valve and a lot of people do a lot of different things.
[0] https://www.youtube.com/watch?v=d3bQpF16vnE&feature=youtu.be...
Took me around 20 min to find this reference again... I don't think they only talk about a content management team here as the organization is quite flat at Valve and a lot of people do a lot of different things.
develope Dota 2, support the Dota 2 tournament scene, work on Artifact, work on Vive...
Don't they also run Dota2?
Dan Luu has a good post on this - http://danluu.com/sounds-easy/
> why build out a huge engineering org?
If the projection you buy into is that you're going to have a billion users, and a business doing $8 billion in sales, you might be less inclined to worry about the cost of those 100 extra engineers and are likely to assume they'll be necessary.
Snapchat probably built out based on old projections that indicated a lot more growth, conceived at a time when they were in the midst of hyper growth. Twitter did the exact same thing, substantially overstaffing for growth that never arrived. The initially fast growing social network trap.
If the projection you buy into is that you're going to have a billion users, and a business doing $8 billion in sales, you might be less inclined to worry about the cost of those 100 extra engineers and are likely to assume they'll be necessary.
Snapchat probably built out based on old projections that indicated a lot more growth, conceived at a time when they were in the midst of hyper growth. Twitter did the exact same thing, substantially overstaffing for growth that never arrived. The initially fast growing social network trap.
Agreed. Baffling for an app that makes substantial iteration maybe once or twice a year. My theory is these companies like to hoard Dev talent in prime locations.
I've worked for a couple of companies that have IPO'd. One thing I've noticed is that the people who are investing in the companies want the companies to be a specific size.
For instance, let's say you have a company that's making an app. Your company is ten people. The venture capitalists will often throw money at your company to grow it to a larger size.
I can only speculate on why this is, but I would guess that it's easier for them to sell the company for a large price if the company itself is relatively large.
For instance, HPE paid $1.1 billion for Nimble Storage. They have 1100 employees. If Nimble only had 30 employees would they be able to justify that valuation? Probably not.
For instance, let's say you have a company that's making an app. Your company is ten people. The venture capitalists will often throw money at your company to grow it to a larger size.
I can only speculate on why this is, but I would guess that it's easier for them to sell the company for a large price if the company itself is relatively large.
For instance, HPE paid $1.1 billion for Nimble Storage. They have 1100 employees. If Nimble only had 30 employees would they be able to justify that valuation? Probably not.
At dinner last night with a VC, company sizes came up.
One of the most appealing business models, which I shared is DNVB's(1). For example, NATIVE, the deodorant brand I use. Had four employees, 1m customers, in business for 2.5 years and just sold for $100m to P&G(2). Yes please.
(1) https://medium.com/@dunn/the-future-of-brands-6682841bd4
(2) https://www.racked.com/2018/1/19/16905724/natural-deodorant-...
One of the most appealing business models, which I shared is DNVB's(1). For example, NATIVE, the deodorant brand I use. Had four employees, 1m customers, in business for 2.5 years and just sold for $100m to P&G(2). Yes please.
(1) https://medium.com/@dunn/the-future-of-brands-6682841bd4
(2) https://www.racked.com/2018/1/19/16905724/natural-deodorant-...
Interesting. My primary business happens to be a (bootstrapped) DNVB with comparable customer count. And despite stories such as Bonobos, etc, we have seen virtually zero interest from outside investors.
I suspect your contention is accurate only for founders who are previously "connected" to the Silicon Valley world.
I suspect your contention is accurate only for founders who are previously "connected" to the Silicon Valley world.
As mentioned above, the anecdote Native received funding I was also unaware of. However, you could continue to scale and be just as appealing for M&A. What’s your DNVB angle? Proctor and Gamble isn’t quite “inner valley”
Without going into too much detail, it's men's apparel and accessories - primarily accessories.
Yes, P&G isn't SV. I meant more that the founding team was already pre-connected to the VC world, possibly through law school connections. They had already raised prior to P&G noticing them in the first place, and very likely leveraged those connections for an introduction to P&G.
DNVB businesses whose founding or management teams have no such connections is not in a position to even meet such people, let alone attract interest from them. Hence, we quietly bootstrap and slowly build our businesses away from any serious equity funding opportunities.
Yes, P&G isn't SV. I meant more that the founding team was already pre-connected to the VC world, possibly through law school connections. They had already raised prior to P&G noticing them in the first place, and very likely leveraged those connections for an introduction to P&G.
DNVB businesses whose founding or management teams have no such connections is not in a position to even meet such people, let alone attract interest from them. Hence, we quietly bootstrap and slowly build our businesses away from any serious equity funding opportunities.
4 employees, 4 years ago, before they got their investor that scaled up and sold the business.
They actually had 100s of employees at the time of sale.
They actually had 100s of employees at the time of sale.
Thank you.. didn’t question the fact as their packages come from an outsourced fulfillment center.
To take it a step further, the formulas were likely done in a lab not their own, potentially using third party bookkeeping and what’s left? Customer service and marketing which both can be outsourced as well.
To take it a step further, the formulas were likely done in a lab not their own, potentially using third party bookkeeping and what’s left? Customer service and marketing which both can be outsourced as well.
A company is only people after all. Once a small start up is taken over there will be a clock ticking for a lot of the engineers who will leave when they can sell their shares. Having a larger number of people involved, including newer people (with no shares) mitigates this.
In a company I worked at the mode was pretty much to take new investment and immediately hire a bunch of new people. Later they would figure out what these people should do. It almost seemed required by the VCs. I can imagine a similar thing happening at Snap.
[deleted]
Yik Yak comes to mind; the product died but they got acquired by Square for the engineering talent. I can see VC's seeing a solid team of engineers as an asset that's potentially more valuable than the actual product.
At the company I worked they seemed mostly concerned with the number of engineers, not quality. We pretty much had the marching order to hire 30 engineers ASAP without knowing what they would do.
Dan Luu wrote a good post on this back in 2016: https://danluu.com/sounds-easy/
The question isn't whether it's necessary, but whether it's profitable. Many programmers have an effect that's a % of existing metrics, for example a performance improvement that increases subscription renewals by 5%. As volume increases, it becomes profitable to hire people who have a smaller and smaller impact.
Two reasons why startups amass huge numbers of people:
1. CEO is a shithead who doesn’t know what to do, so hiring is a futile attempt to do everything at once
2. Huge number of employees looks better when coming up with valuation for a round.
The two tend to be self reinforcing. And #1 survives and blossoms after IPO.
1. CEO is a shithead who doesn’t know what to do, so hiring is a futile attempt to do everything at once
2. Huge number of employees looks better when coming up with valuation for a round.
The two tend to be self reinforcing. And #1 survives and blossoms after IPO.
I wonder this about TrueCar.com, too.
Ssshhh what's wrong with you?
I got an email from them no longer than a month ago that they were expanding like crazy and opening a new office in Seattle. I don't completely understand their situation.
same here. got a linkedin message from a recruiter in Seattle
Former Snap engineers in Venice feel free to get in touch. We're hiring at our Santa Monica office for all types of engineering roles.
what's your email?
If you write to our support@ address I'll keep an eye out for it
Their history is a lot of job posting for sureapp.com. Though not sure where their careers page is
Could be hardware engineers after the Spectacles failure.
Have they confirmed whether they are giving up on their hardware play or not?
They are reportedly working on two new versions: https://techcrunch.com/2017/06/12/snap-is-developing-a-secon...
Ten percent of all engineers is pretty significant. Curious what the motive is.
I can posit a few things. My work is "down the street" from them and they hired extremely quickly. From murmurs I've heard that seemed to actually work out ok. Having experienced really fast growth at my work, but not their rate of fast growth, I can trow some spaghetti on the wall that will probably hit somewhere near the mark for some set of the 100 firings.
1. Managing out.
If you hire quickly and perhaps not carefully, you'll hire people who don't necessarily perform as well as you thought (generally), don't perform well in your environment in spite of their talents (i.e. Chris Lattner's short stint at Tesla), or don't get along with the team and hurt culture.
2. Under the same fast growth, you may also hire a specialist for some technology you decide to get rid of.
While the ideal situation is finding a new role or moving them to a different team with a similar technology (i.e. one NoSQL DB to another), you may not be able to do that if you hired lots of folks all at once.
3. They simply over hired.
This can mean they don't have enough managers and people are being poorly utilized, they hired opportunistically, or they were just poorly coordinated.
4. They need to make their accounting look better.
People cost money, until you stop paying them. Not much to say here.
1. Managing out.
If you hire quickly and perhaps not carefully, you'll hire people who don't necessarily perform as well as you thought (generally), don't perform well in your environment in spite of their talents (i.e. Chris Lattner's short stint at Tesla), or don't get along with the team and hurt culture.
2. Under the same fast growth, you may also hire a specialist for some technology you decide to get rid of.
While the ideal situation is finding a new role or moving them to a different team with a similar technology (i.e. one NoSQL DB to another), you may not be able to do that if you hired lots of folks all at once.
3. They simply over hired.
This can mean they don't have enough managers and people are being poorly utilized, they hired opportunistically, or they were just poorly coordinated.
4. They need to make their accounting look better.
People cost money, until you stop paying them. Not much to say here.
Insightful...thanks for sharing. It's a shame companies don't consider the personal turmoil they create when moving that fast.
Meh. Remember, they're paying you for a service, and they can terminate the relationship largely at-will when that service is no longer required.
I'm not saying I agree with how the US employment system currently functions, but them's the facts. If you value stability or loyalty, definitely don't join a hyper-growth startup.
I'm not saying I agree with how the US employment system currently functions, but them's the facts. If you value stability or loyalty, definitely don't join a hyper-growth startup.
2. Under the same fast growth, you may also hire a specialist for some technology you decide to get rid of.
This would only lead to a very small (less than 3-5), if any, part of the 100 engineers getting fired.
3. They simply over hired.
I guess some part of this could also have been because they de-prioritized some big features, that led to some engineers not having enough work.
This would only lead to a very small (less than 3-5), if any, part of the 100 engineers getting fired.
3. They simply over hired.
I guess some part of this could also have been because they de-prioritized some big features, that led to some engineers not having enough work.
Right. I’m not saying these suggestions cover every person being let go. My position is that rather than this being a doom and gloom event for Snap, like some other comments have suggested, there are many reasons. These are the ones I’ve seen happen personally.
> Ten percent of all engineers is pretty significant
Not if 20% or even 30% was from 'fat' / over-hiring -- they TRIPLED their staff from 600 to over 1,800 within a year[1] -- in the year leading up to their splashy IPO
[1] Source: https://marketingland.com/snap-reportedly-lays-off-18-employ...
> The company, which went public in March 2017, has been on a hiring spree over the past couple of years.
> Between December 31, 2015, and December 31, 2016, the company’s full-time employee base rose from 600 people to 1,859, according to the company’s most recent earnings report.
Not if 20% or even 30% was from 'fat' / over-hiring -- they TRIPLED their staff from 600 to over 1,800 within a year[1] -- in the year leading up to their splashy IPO
[1] Source: https://marketingland.com/snap-reportedly-lays-off-18-employ...
> The company, which went public in March 2017, has been on a hiring spree over the past couple of years.
> Between December 31, 2015, and December 31, 2016, the company’s full-time employee base rose from 600 people to 1,859, according to the company’s most recent earnings report.
Thanks. That's pretty crazy growth. Just onboarding and training them on how things work seems impossible at that growth rate.
Also shows how little they care about the personal/family turmoil they create when doing that.
Also shows how little they care about the personal/family turmoil they create when doing that.
Given the number, there is probably zero on boarding and training. Only a new employee surrounded by other new employees.
The motive is probably to save money.
[deleted]
Headspace is Santa Monica is hiring for engineering talent. Feel free to email me at [email protected] for more details
Snap Engineers interested in working in Santa Monica - Join us down the road at YogaGlo! https://www.yogaglo.com/careers
[deleted]
adding to the set of hiring comments. Factual in Century City is hiring across engineering.
[email protected]
https://www.factual.com/company/careers/?gh_src=1pt2v8
[email protected]
https://www.factual.com/company/careers/?gh_src=1pt2v8
clearly a bad sign from management as the co is looking for growth: $22b can’t afford it and if you’re left, you’re next ..
Poor Snap. Long live Snap.
Layoffs? Oh snap!
Probably gearing up to spend more on compelling original content as that's harder to produce than the software at this point.
And they'll probably end up losing 20-30% within a year. Engineers aren't stupid, and know they have tons of other options. This smells like VCs pressuring them to grow, grow, grow and management thinking they can just throw devs at the problem until the accountants stood up and said enough.
>This smells like VCs pressuring them to grow, grow, grow
They are already public
They are already public
That's a very recent development. And who do you think owns most of the company and controls the board seats?
[0] https://www.forbes.com/sites/clareoconnor/2017/08/23/women-f...
[1] http://www.businessinsider.com/how-markus-frind-bootstrapped...