Snap is laying off about 100 engineers
cnbc.com
cnbc.com
[0] https://www.forbes.com/sites/clareoconnor/2017/08/23/women-f...
[1] http://www.businessinsider.com/how-markus-frind-bootstrapped...
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.
> 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.
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...
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.
The employee count was like 260.
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.
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.
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.
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.
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...)
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.
There's tonnes of examples backing up your first point though, 100% accurate.
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.
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.
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.
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.
[0] https://www.pcgamer.com/valve-misses-deadline-to-respond-to-...
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".
[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.
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.
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-...
I suspect your contention is accurate only for founders who are previously "connected" to the Silicon Valley world.
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.
They actually had 100s of employees at the time of sale.
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.
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] 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.
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.
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.
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.
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.
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.
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.
Caveat: worked only once, no guarantees provided...
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.
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.
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.
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.
Also shows how little they care about the personal/family turmoil they create when doing that.
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.
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.
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.
benmayne@factual.com
They are already public