“ As hard as this is for all of us, our future is bright. I look forward to working with you to propel Elastic into that future as we make Elastic a generational brand”, especially since he earlier says those being laid off may not even know that for up to 24 hours.
I've had this happen somewhere I worked: "ceo: well be laying off a big portion of the company, you'll find out who tomorrow". I don't know the right way to do this, but I know this is the wrong way. What possible good does this achieve?
At Yahoo in 2016, layoffs were announced as "planned" in an earnings call and they happened department by department, always on Wednesdays. This was right around when Blind got popular (but before each post was just whining about TC) and so every Wednesday morning we'd all check Blind to see which teams got hit this week.
The really hilarious thing is no matter how far down Yahoo continues to sink they will always have at least my dad and those who refuse to use anything other than Yahoo Finance in the foreseeable future to keep them somewhat afloat.
Edit: for the record this is not a slant against those who use Yahoo Finance. Even back when I used it in high school it was good.
I left Yahoo in 2011, I remember layoffs being dysfunctional, but it seems like they really leant into it. My favorite was when they announced layoffs in November, and couldn't figure out who to lay off until after the deadline for finalizing the company holiday party, so I got to see some of my colleagues who had been laid off for a couple weeks at the party.
According to the article most of the affected have been informed, but they have not informed everyone yet. I think it's a fair compromise.
Nobody wants to be told they have been laid off by finding your name in a power point in the morning, just because you live in a different time zone. They have offices around the world, so it is difficult to inform everyone at the same time without calling someone in the middle of the night.
At the same time those who have been informed are talking to other employees, and news spread fast. So they end up with a compromise - inform the company about the process.
They are handling it better than what I experienced not long ago. After announcing the layoffs and informing the affected, they did not communicate who was affected until the week after. Colleagues who had a good network knew who were affected by talking to each other, while others were left in the dark
Another precious tidbit: congratulatory emails for wins and renewals were received on Nov 29. They should have just combined them - "Congratulations on that incredible 6 figure win! OBTW you're FIRED.' LOLOLOL
If you scroll down to the very bottom there is a big "we are hiring" icon. I wish everyone who was laid off all the best. I wonder if Amazon with it's elastic fork will try to acquire some of the talent.
That's unsurprising since they have had layoffs and been upfront that there is more to come. Unlike layoffs that make the news, allowing/encouraging "natural attrition" allows companies to fly largely under the radar.
>"I didn't take this decision lightly. Since becoming CEO, I have had the opportunity to spend time with Elasticians around the globe."
One bizarre side-effect of these layoff announcements is learning all the cringe-worthy names these companies have for their employees. Elasticicans? Tweeps? Stripes? I'm guessing this is a SV thing? Do these infantilizing names actually do anything to build company culture?
In all fairness, there is more than just cost when choosing a provider. Elastic has had higher uptime than the AWS alternative. I had to switch off AWS Elasticsearch hosting because it kept going down.
If your use case is faster search - ES cloud is way more efficient/performs better than AWS. They manage their cloud stack pretty well. I hate those `amazon.internal` stack trace in thread stack ( when you try to troubleshoot something in prod) as you have no access to code to see what it even does.
True, last I check the gap wasn't too big anymore, I think even comparable for certain machine configurations.
One thing is that the "mainstream" ELK develops at a much faster speed than the OpenSearch fork, and a lot of the nice features in new versions are nowhere to be seen in OpenSearch.
Well, companies are doing it to avoid a PR disaster. It's a business move. The big players took the hit from the public (fb, amazon, etc...), then we do it and the public can blame it on the current climate. Let's not forget the Feds literally saying businesses have to ramp up firings to slow down inflation on one side and the current government on the other side is trying to tell the public they are creating more jobs.
The cynic in me is telling me this is all planned by big tech and government. Heck, Zuckerberg waited to fire his staff a day after the midterms were done. This is no coincidence.
Yeah it’s amazing how much potential that company had and then blew it with a series of questionable business decisions. They had a ton of really quality talent too but much of it has moved on the last few years.
Pretty much everything MongoDB did right, Elastic did the opposite and failed. Instead of being the best place to run Elasticsearch, one of the most popular open source projects ever, they blew all that brand equity on a series of mediocre solutions that were outcompeted.
As someone that worked at Elastic for 4.5 years on the Elastic Cloud team and really loved it there for the majority of that time, I saddens me to admit it but this is spot on. Despite all their best efforts, everyone I've ever spoken to just wants to run the "ELK stack" and doesn't care about their confusing solutions strategy.
One thing about Elastic is that their roots are in on-prem / self-managed software and selling support to enterprise customers. This led to our cloud strategy being based around ECE (Elastic Cloud Enterprise), with the idea we would eventually fully unify this on-prem version of our Cloud product with our actual SaaS, and just run ECE "at scale". During that time we got stuck in the slower Elasticsearch "quarterly minor + monthly patch" release cycle (SaaS did have a shorter one but it was also troubled) and spent countless engineering effort troubleshooting enterprise customer's own infrastructure (imagine stuff like "ohhh, I see, you V-Motioned a server hosting ZooKeeper containers, and you're running on spinning disks" after 2 weeks+ of back and forth). We couldn't easily add table-stakes features to our SaaS because we needed it to run on-prem too, even though ECE is very limited in the types of supporting infrastructure we could add (basically just ZooKeeper and Elasticsearch). I think they are trying to move past this strategy and onto a SaaS-only K8s based approach but I fear too much time was squandered. I hope I'm proven wrong.
Thanks for the info - it just sounds like a completely bizarre approach. Like, why even make it the same (SaaS and OSS versions)? If you're going to do SaaS ELK then why not just do that and add whatever features you need to be better than DataDog or w/e? Make the SaaS ELK better than a version anyone could even imagine self managing.
It's especially weird to me because if I was a casual user then I wouldn't even know Elastic had anything to do with Elasticsearch. You certainly wouldn't know it from their webpage. I literally see this at the top:
"Accelerate results that matter, across any cloud. Easily deploy anywhere, and extend the value of Elastic with cloud-native features."
What does this even mean? How is the marketing department not 100% of these layoffs, lol?! why is a so-called SaaS company talking to me about deploying to any cloud and what even is "Elastic" and just what problem is it solving?
This is so bad it's hilarious.
You have to scroll for awhile to even see the word "Elasticsearch" and I don't see anything about ELK anywhere.
What pathetic execution. You were smart to leave that place!
Thanks for the input. Had similar experience with solution based on top of on-prem flavour (gravity - name came from pulling stuff from cloud back into traditional data centre) of k8s. Countless effort and resources have been wasted on troubleshooting customers' infrastructure rather than focusing on the real goal, get apps/APIs up and running quickly to generate value and realise goals for the business. The solution ultimately become a burden to both engineering and customers... Long sad / bad story.
Fortunately, decision makes heard the voice from the field and customers, eventually offloaded the container orchestration layer (and underlying infrastructure) to managed k8s service provider, the solution is delivered as helm charts to be installed on customers' own managed k8s (EKS, AKS, GKE and OpenShift - oh, the Red Hat OpenShi(f)t is just another rabbit hole...). But again, lack of knowledge and hands-on skill operating / running k8s (not yet a commodity although it is hyped to be...) makes the journey quite turbulent from a business PoV (technically it's easy, built the skills in house, hire the right talents).
> You wouldn’t even know they are the Elasticsearch company.
When I interviewed there a couple years ago, was told by a leader they are trying to not just be "the Elasticsearch company". (Due to competition from AWS OpenSearch)
I would have left the interview right there. All they did was concede Elasticsearch to AWS, a brand worth 10’s of billions.
Had they executed their Elasticsearch cloud story would have been top notch and then they could put solutions behind it as additional upgrades. Instead they have a confusing story and aren’t a leader in anything they do.
Just a terribly sad outcome for a company that had everything going for them.
Considering the widespread layoffs even at superb places like Stripe, I'd guess this has more to do with overhiring during "the good times" than with product-related decisions.
Other things I have heard: 1) the claim is that lower levels of management "were not told". I suspect that is not completely true, since many people's projects had new people parachuting in the last week or two. 2) Survivors are wondering if the selection process was "random". 3) Survivors are wondering if there will be another layoff in January.
Here's a question: why on earth didn't Elastic offer a voluntary separation package? They probably would have gotten at least a good chunk of people to accept, reducing the need to behead 13% of the company yesterday.
Indeed. It's up there with Andy Jassy's recent announcement about upcoming layoffs at Amazon that ends with "we should all be very optimistic about Amazon’s future. I know I am."
Yes, it is meant to cause panic in general population but with a purpose of them putting pressure on politician s which in turn put pressure on central banks to tone down the rate increases.
We’ve been in a recession for two years. People just seem to have been pretending we aren’t.
Not even totally COVID or Russia’s fault either… stock prices really bubbled since 2008, with many companies trading well above a level that there is any rational justification for.
yeah, it would be so nice if our industry hadn't over-hired for the last five years on the promise of everlasting ZIRP and trickle-down funding from adtech giants. alas, here we are.
Why would that be nice? Having over-hired and still doing just fine means that for the period that companies were over-provisioned they were disbursing profits to labour (workers) rather than capital (shareholders).
> Having over-hired and still doing just fine means that for the period that companies were over-provisioned they were disbursing profits to labour (workers) rather than capital (shareholders).
Shareholders caught wind of that and are taking corrective action.
“ As hard as this is for all of us, our future is bright. I look forward to working with you to propel Elastic into that future as we make Elastic a generational brand”, especially since he earlier says those being laid off may not even know that for up to 24 hours.