Apollo Layoffs
apollographql.com
apollographql.com
* 15 weeks base pay + 1 week per year of employment
* 6 months COBRA + $300 mental health
* no 1-yr cliff, options can be exercised thru next year
* you can keep all your equipment
It will easily cost 10x to work with a mental health professional (and insurance companies sadly pay a very small amount of it). So why add this to an otherwise reasonable package?
I'm sure their heart is in the right place and offering mental health coverage is a good thing, it's just the number causes a double-take.
Maybe Apollo's health care plan has much better out of network coverage than what I'm familiar with, in which case I stand corrected (and agreed that its good to help cover copays, if this is what this actually does).
When I worked in the US, my health plans had pretty good mental health coverage. You could spend 1,000s of USD per year for psychotherapy / counseling with zero-to-minor co-pays. If you required medication (prescribed by a psychiatrist), that was also well-covered with zero-to-minor co-pays. I remember specifically that mental health care had "higher coverage" because therapists were rarely part of the insurance company's network. You paid the health professional directly, then require reimbursement from health plan. (Yes, I know this isn't true for all health plans.)
To hire an experienced mental health professional in SF Bay Area, I guess the rate is 100 to 200 USD/hour. Most will have sliding scales, but that will not apply to well-paid engineers.
Folks on an HDHP or who don't get through their deductible most years would probably end up spending most, if not all, of this out of pocket. Even if they would get something back they have to do all the dealing with the insurer.. and that's assuming that they understand superbills and all the BS that insurance companies make you wade through...
In short, $300 just clears all of this out of the way. You go; you get reimbursed for the visit; you get to decide what to do next.
I see it as a coupon to try it out.
I agree it might help someone make a decision to try out therapy and see whether its a good idea for them.
Almost 60% of US workers are hourly and most of them don't get severance. A lot of the other 40% dont either.
https://www.workstream.us/blog/hourly-vs-salaried-jobs-benef...
In the UK, it's common for employers to have contractual obligation to pay a notice period, and for longer term employees they are legally obliged to be firing them on capacity or redundancy grounds - so it is common to pay some severance in order to pay the employee to resign themself and sign some legal paperwork saying it's okay.
I don't get why employers pay extra money "just to be nice" where there isn't some legal reason to do it...?
The owners are now billionaires.
(They sold the company to a Fortune 100 about 18 months later.)
Unfortunately your statement is painted with a wide brush, covering everyone from Jeff at Amazon to the owner of a corner grocery store. Everything from profitable FAANGs, to VC funded startups with hypergrowth ambitions, to small, finally profitable, boot-strapped endeavours.
Clearly among that group there are some who have embraced late-stage capitalism, who are milking their custoners and employees at every turn.
However, I would suggest, that many more have spent a life-time working harder, with less income security, doing what it takes in good times and bad. Looking after employees, treating them, and customers, fairly.
If after all this time they become well compensated, perhaps even rich, calling them "theives" belies the effort, and sacrifice, to reach that place.
I haven't mentioned anything about the effort or value employers provide. I don't think hard work from owners is relevant to the amount they thieve. And I wonder why you don't mention anything about the hard work provided by the labor who are victims to the largest category of theft, who by definition do the majority of the work obligated in business to begin with.
https://calmatters.org/explainers/when-employers-steal-wages...
Re: risk staked, I will add that for many business owners their greatest risk and fear is simply having to work for a wage themselves.
If the company keeps you on payroll and pays you weekly, then you cannot collect unemployment. If the company gives you a lump sum then you may be able to.
If a condition of the severance is that you sign a document saying you are quitting instead of being fired, then you cannot collect unemployment.
My understanding comes from recent googling because of similar layoffs that happened at my company. I'd welcome more informed thoughts on the matter.
This is false. If a company makes you sign a statement that you are quitting instead of being fired as a condition of getting severance, they are committing unemployment insurance fraud and are subject to civil and criminal sanction in most states.
(The point of trying to make employees do this is to avoid claims against the company's unemployment insurance account in the state. How UI works differs from state to state, but in all instances claims against UI increases the company's ongoing UI expense.)
Yep, in the case of the lump sum you're not being paid after you're given the lump sum. I was laid off in 2014. Got 4 months in a lump sum when I went out the door. There were no problems applying for unemployment.
I went with the latter because it paid better.
For a while I was always stressed out about background checks, because it showed that I was working two jobs. (I got a job to replace it almost immediately, but continued to get paid by the old place.)
"The Work Number" is a very popular service for this. They are owned by Equifax.
edit: apparently in some states you can - at least in Colorado in 2008, you could not. Generally your unemployment would be reduced by the amount of income you brought in. So, in any case, severance payments from a typical tech job would far exceed UE anyway...
Including laptops with likely the customary IT spyware as well as confidential company data? If I were in this situation, I would at the very least wipe the drive completely, and probably reflash the BIOS too before actually considering it safe for personal use.
More hands /= more productivity, at least on a linear scale
The insights from 50 years ago is fine abstractly but it has its limitations.
Not only are there many more roles to fill but things like translation and QA scale pretty well.
It's an adage, not a hard and fast dogma.
Also it was specifically limited to when in the project people are added and often gets misremembered as some linear programming inspired exercise in optimal team configuration.
The latter is obvious and useful (right size the team for the job) but IIRC, Brooks doesn't actually address it in the famed literature.
Sometimes it's more! You have nine projects you want to do. A, B, C, D, E, F, G, H. You have 2 developers. You hire 3 more. One of the new hires has more familiarity with what projects E and G needs than anyone on the existing team had. One of them is slower than the average of the existing devs. One of them is MUCH faster. The five of them complete those nine projects in three months (15 total people months, with boosts from one of the new dev's skills and the other's increased speed) when it may have taken 9 otherwise (18 total people months).
But I've seen a lot of companies not be quite that smart in their hiring...
(The faster scenario I've outlined above also potentially bites you in the butt if you don't have enough more valuable projects lined up behind that first set...)
This was the relevant part of what you replied to:
> It doesn't certainly doesn't mean anything as broad as "a company cannot do more things by increasing its employee count."
And yes, managers do expect close to linear productivity gain past that spot. Managers, that are a little smarter, start thinking about how spotify did squad (without actually knowing anything about it).
https://developers.redhat.com/blog/2022/10/21/coming-terms-t...
I think a well composed small team can have greater than linear improvement in effectiveness because of skill stretch and decreasing blindspots.
What I was talking about is something like this: SRE team has 1 member and productivity of 1, that person is overworked and if vacation is taken productivity goes to 0.
Hire second person, after onboarding productivity goes to about 2 (i.e. linear scale). Hire third person, productivity will probably be a little under 3 because now they need to spend time to be on the same page. Vacation is still shaky because with such small team, knowledge will be 100% siloed due to outside performance expectations ("hey you worked on X last time, I'm going to assign this ticket to you" repeated many times).
Eventually team grow to a point where they can handle all work load, share knowledge between each other and take vacations without fear (btw if you fear taking vacations - don't, it's not your fault if team can't handle without you).
You can think of "work load + process" as a data structure. If work load is bog and process requires a lot of synchronizations (every meeting is essentially a Mutex for the entire team) - you won't get linear productivity increase, instead you will increase lock contention.
I’ve actually spent a long time working at engineering orgs that run super lean. On the upside there are never layoffs, on the downside you’re really constrained on what problems you can tackle - and that can have some major (negative) business implications.
Anyway I can’t help but feel we are slowly reverting back to the aughts where people thought you could clone Google or whatever with like 5 engineers and didn’t understand why nobody took them seriously.
I have my own distaste of "MBA Culture" but one thing I would not say is that they teach people to ignore the business and not learn it. From what I've learned, is completely orthogonal to what they teach you in any regionally accredited business school what you are asserting here.
I'd wager most core engineering teams in a co like Apollo are probably quite small and focused. I'd guess the cuts are coming from the ancillary teams.
Less often, but much better, are people being hired and put onto new teams, focused on new projects and products. Developers can scale horizontally, but not vertically.
So, companies did anything to show growth, which means marketing and incentives to acquire users, to adjacent services, to hiring more staff. I'm sure leadership either knew that this is what needed to be done to get more funding, or they actually drank the cool aid.
"Twitter 2.0 or How I Stopped Worrying and Loved the Mythical Man Month"
Making open source tools is not something I'd consider bloat, I'm talking more about those in the book Bullshit Jobs by David Graeber.
Having fewer people also leads to people achieving more, ie one company with 1000 employees versus n companies that are 1/n the size, I'd say the smaller companies are much more likely to produce innovations that are useful for society as a whole.
From The Mythical Man-Month: "If there are n workers on a project, there are (n^2 - n) / 2 interfaces across which there may be communication... The purpose of organization is to reduce the amount of of communication and coordination necessary". I doubt anybody would ever expect adding large numbers of employees to have a linear effect on productivity, especially if they aren't well coordinated. More people usually means more meetings and more communications costs, as well as more bureaucracy in the way. I find it hard to believe that a leader in software would expect otherwise.
Why do CEO's always say this empty nonsense. If you accept responsibility, you accept consequences - what consequences is Geoff Schmidt going to be facing? Hurt feelings? Give me a break.
The explicit consequences are up to the owners of the company, not the court of public opinion. The owners wouldn't be beyond their rights to demand the CEO's resignation, although neither are they obligated to do that either since everyone makes mistakes. And as others have pointed out there are implicit consequences as well -- less trust from remaining employees, etc.
Unless there is someone else who can do better job, it doesn't make sense for him to step down. However, I do wonder if it would appeasing to take voluntary pay cut as a more visible form of taking responsibility. Just a thought.
I often view these statements with knee jerk cynicism (though I recognize it as such) because too often you read about layoffs while executives get golden parachutes. Why should the CEO get the 30 million payout to leave the failing company while everyone else gets comparative peanuts and loses their job.
I can sympathize a bit with why people feel bitter about these things.
I also know some business owners and people who run start ups, those who do it with integrity do have genuine feelings they have to process around this. I try to also remember that not everyone is Jack Welch.
it’s clear they want people in charge to suffer, because some other powerful person hurt them in the past
sad. start up founder have a lot of benefits but it comes with pain.
pick your poison
I tell potential hires explicitly that this can fail, and that there's a runway, and that it's uncertain. I've seen so many places try to sell people that it's just kicking ass all the way to the bank.
So, when a CEO makes this kind of statement, I would refer back to the initial messaging before getting out my coals and rake. Nobody made anyone sign on to a nascent software company. It absolutely sucks to find yourself without income, but you've got to know your risk tolerance. And, by that, I mean you need to know how well you tolerate risk, and you need to know your exposure. If management wasn't forthright, well, that's really shitty.
The entire industry has had layoffs, regardless of size. In fact, in my experience there's plenty of startups that are still growing and hiring the laid off talent from the big institutions. Apollo was not one of those companies, but it doesn't seem like it being a startup had any impact.
I stand corrected.
But, then again, the CEO does say: "we are not yet profitable: we’ve taken full advantage of outside capital to speed our growth. That was good stewardship in a time when interest rates were low and venture capital was widely available on good terms. But economic conditions have changed and we believe that it’s no longer prudent to rely on outside capital to support us"
I just don't know what to make of it. It was a healthy company.
> it doesn't seem like it being a startup had any impact
A true mystery.
I always get massive push back when I suggest this, but it's the only remedy that makes sense. If you have to layoff 15% of the workforce when the growth was under your command, and you want to take responsibility, then step down. Own your mistake.
Loss in confidence of his employees, fear of mass exodus, pressure from stakeholders, etc...
I don't usually defend CEO's, and it sounds like this one has committed some pretty serious errors, but I certainly would not want to be sending that email out.
2018 July. Apollo server 2 released woo! (mostly ignored)
2019 Feb. We switched away from Slack woo!
. . . (Some PRs everybody ignored)
2019 June. We got a $22M investment woo!
. . . (Many PRs everybody ignored)
2022 Dec. Oops, we are laying of lots of people...
If you need you consume a Graphql API you most certainly reach out for Apollo on the clientside to query data.
Over the last couple of weeks I’ve been assessing whether to use Apollo in a Swift iOS application. If your backend is using GraphQL then it’s almost impossible to find even a StackOverflow answer from anyone not using Apollo.
But when I tried it out, I found the package was cumbersome to use, and the generated code was over-dimensioned and inelegant, and the dependency itself pulled in other dependencies.
With bitter experience of using other packages in the past, which start out as helpful, but which end up a burden to the codebase, I decided to write some queries and mutations by hand. And it was super-simple.
https://supabase.com/blog/pg-graphql
Anyway, these are all tools to generate a backend based on your database which might work for simple situations but breaks down for more complicated ones. I also don't want to give my backend away to Hasura or Supabase either.
No. I have not been spamming the same comment. I have made several related comments, which I'm free to do just as anyone else is.
Now, YOU'RE free not to use Hasura Cloud (a fine cloud-managed product by a company I work for) or Supabase (a fine cloud-managed product by a company I don't work for). You're also free to use Hasura CE (a self-hosted OSS Docker image), Supabase (another self-hosted OSS Docker image), or Postgraphile (another self-hosted OSS Docker image) if you don't want Hasura or Supabase to host your application. You're even free to believe these tools work only for simple situations but break down for more complicated ones. The thing is, other people are equally free to make other judgments.
For the record I have used Hasura before, both cloud and self-hosted versions. At the time Hasura didn't have serverless functions so it was very difficult to do anything custom even with workarounds. Now it seems Hasura has serverless functions now but now I feel that I shouldn't need to tie my backend and code to a database product lest anything happen to said product, lock-in sucks. That they are OSS or self-hosted does not make them any less susceptible to lock-in. I could also use, for example, Vue, also an OSS product, but if something happens to the primary contributor and no one else wants to maintain it, now I either have to deal with bugs slowly creeping in over time or rewrite my frontend.
So, no thanks, I'd rather keep my own backend and not use a BaaS product.
I see no good reason to accept that proposition. Moreover, I'm not recommending Hasura in this thread (see below). That would be odd, given that I have also said good things about competing products (Potgraphile and Supabase).
> Your comments are also near copy-pastes of each other
I made 4 comments originally:
1. rejecting the claim that Apollo is "_the_" GraphQL company: https://news.ycombinator.com/item?id=34007957
2. rejecting the claim that Apollo client is the only one to use: https://news.ycombinator.com/item?id=34008121
3. answering the question of what to use on the backend besides Apollo: https://news.ycombinator.com/item?id=34018101
4. rejecting the claim that Apollo can't "be beat" on the backend: https://news.ycombinator.com/item?id=34018095
Numbers 3 and 4 are similar but not the same, given their contexts.
For the record, Hasura has never had serverless functions. It never had them before and it still doesn't have them now. We view that as a product decision, but you're free to view it however you like. As for your other reasons for not wanting to use Hasura, you're free to have them just as others are free to reject them. My objective has never been to persuade people to use Hasura. Use whatever you want. My objective was counter claims that I believe are untrue.
>> I see no good reason to accept that proposition.
You should absolutely disclose that you work for Hasura when talking about Hasura. Like the other commenter mentioned, this is basic decency on this medium. Failure to do so will reflect very poorly on you and your employer here.
What I have done is present not matters of judgment, but matters of fact.
Fact: Apollo is not _the_ GraphQL company.
Fact: Apollo isn't the only one with a GraphQL client library
Fact: Apollo isn't the only path to creating a GraphQL server
As matters of fact, these are either true or false, but readers are free to evaluate which they are on their own. They shouldn't trust me, because I'm a stranger on the Internet. But then again so are you and so are most or all people here.
You say that if I don't disclose who I work for people will trust me less. That's silly, because people here shouldn't trust me at all, nor should they trust you, or anyone else, for the reasons I just gave.
In short: don't accept without careful scrutiny anything you read on the Internet, no matter who says it.
> Have I tried to persuade people to use Hasura? No.
> Have I tried to persuade people that it's good or better than the competition? No.
> For the back-end, Apollo Server absolutely can be beat by tools that don't require you to write any code:
> https://supabase.com/blog/pg-graphql
> https://www.graphile.org/postgraphile/
The careful reader will note that I presented three alternatives, with the one provided by my company last. Moreover, what I wrote is in fact a matter of fact. If you wish to have a GraphQL server without having to write server code to do it, as fine a product as Apollo is you cannot use Apollo to do it because that's not what Apollo does.
It's basic decency on Hacker News or elsewhere. Feel free to accept it or not but know that others will think less of your comments' veracity and trustworthiness by not doing so.
> * Moreover, I'm not recommending Hasura in this thread (see below). That would be odd, given that I have also said good things about competing products (Potgraphile and Supabase).*
Even if you recommend other products, merely linking to it in a list while not disclosing you work there is distasteful.
> I made 4 comments originally:
Regardless of what the claims you were responding to were, your comments themselves for 3 and 4 are copy pasted in content. That is what someone means when they say one's comments are copy-pastes, or said another way, spam. Out of 4 comments, if 50% of them are the same, that's pretty spammy to me.
> For the record, Hasura has never had serverless functions. It never had them before and it still doesn't have them now.
That's funny, I just googled it now and it does seem to have support for them, at least a page that says so. If that's not really using serverless functions (while literally being titled "Using serverless functions") then perhaps they should change the title and clarify the content [0]. I also don't mean that Hasura should have serverless functions itself, like AWS Lambda, I meant that there was not a good way to trigger database events and if you wanted to write custom logic, the recommended way was running a whole other server, which at that point, I'll just write my own backend myself [1].
All this leads me to believe you're shilling for Hasura, don't actually work there, or some combination of both.
[0] https://hasura.io/docs/latest/event-triggers/serverless/
That documentation page says that you can use serverless functions with Hasura, which is true. Hasura custom events call a web-hook, which can be and often is implemented with a serverless function, thought it need not be.
> I also don't mean that Hasura should have serverless functions itself, like AWS Lambda
Thank you for clarifying.
> your comments themselves for 3 and 4 are copy pasted in content
No. I typed out comments 3 and 4 independently "long hand." No copy/paste was involved, save for copying the URLs over.
As for the rest...let's just score that as "a difference of opinion" and call it a day, shall we?
I’ve personally never used Apollo stuff in prod —- there’s always been a more suitable alternative, but I’ve always appreciated their code for being quite clean. Federation is an interesting technology, but I haven’t had cause to use it yet.
Also, big aside here, but is Meteor still a thing?
I was there during the transition period. Originally joined to work on the Meteor hosting platform that was called Galaxy. Handled integration of Meteor APM (which was an acquisition) both of which got sold off when the old Meteor business was sold.
I then worked on what was called Apollo Optics, the GraphQL APM product. Rewrote the time series backend to port it to Apache Druid (which remains in use today!). Was somewhat unceremoniously let go of during a bad personal period. Don't think I would have stayed anyway though, main reason I stayed as long as I did was I had a really good mentor there that taught me a lot.
Worth mentioning the company had already raised an absolute crap ton when on the original Meteor path, then the following pivot raised even more money. No idea how many rounds of financing the company has been through at this point but to say it exemplified the excesses of cheap money would be an understatement.
Developer tools is a tough business, no-one really wants to pay for that stuff at the low end which means catering to enterprise. Long sales cycles, annoying requirements etc.
To be honest I don't understand Apollo's business model, not once did I feel like I needed to pay for it, its free version solves all my needs.
I believe the compelling part of the current offering is the schema management features. We started building these when I was there. I don't know to what degree the alerting part of the APM product survived. It was originally requested by an enterprise customer and I re-implemented it on-top of Druid to make it much more scalable. My assumption is that should be a bit of a draw. etc.
Generally you get there through a senior or staff engineering role where you can demonstrate the technical and leadership aspects. I would focus on mentoring your more junior engineers and taking part in force multiplying efforts, i.e tooling, processes etc.
The expected growth of revenue by growing our workforce did not happen. Together with the tough economic climate, we came to the conclusion that letting 15% of our workforce go will put the company in a better position to survive and navigate the future. Hopefully there will be future opportunities that allow us to grow again.
We are all very sorry for this. Personally, I can barely sleep thinking about the stress and troubles my former colleagues will face having lost their job. We feel it‘s our duty to provide a fair severance package with at least x more months of pay, y months of health insurance, etc.
I am not a writer! Others could do this much better!
At least pretend to be a fucking human and don‘t write disgusting copy-paste trash that sounds like it came from a lobotomized HR junior like Mr. Schmidt did.
Article starts with a title on gradient background and company logo. This is implemented as an almost 3 MB png file [1] How come?! Why not a simple text and couple of CSS tricks? Why not an SVG? Don't they notice it takes ages to load?
[1] https://www.apollographql.com/blog/static/Skylark-R-1-d25f13...
Architecturally it seems to be adding a massive hop to requests made, but its not clear to me what the benefit is?
For JavaScript, I originally used graphql-js and express-graphql, as these were the original libraries and I was a literal day 1 adopter. All the libraries are essentially just wrappers around graphql-js, so it's still viable to use directly. But for schema-building I now use Pothos (https://pothos-graphql.dev/), I'd probably use graphql-helix as the http layer (https://github.com/contra/graphql-helix).
In my experience it’s very uncommon for anything other than simple prototypes to not have at least some divergence between the UI model and the persistence model.
> Say you have a web app, an iOS app and an android app
and
> let’s say the model of the data that makes sense for the purposes being the UI for these apps is different from the model that’s used to persist data
Question: If we stipulate that the UI models are different from the persistent model, are the UI models are different from each other or are they they same? What I mean is this. Do the web app, iOS app, and android app models differ from each other? This is important for my reasoning that follows.
The situation may change if you also add internal tools to the mix, since they’re often operating on a superset of data that the consumer apps might have access to - though still not necessarily the same model as the persistence layer.
In any case, your requirement can be satisfied by SQL views, which transform the persisted model (tables), and which are 'below' the GraphQL server.
They also provide libraries for both the client and server so they can tell you what versions of your client are using specific data.
Also personally, I think I'd rather know about being laid off before going into the new year.
https://www.yahoo.com/news/why-different-companies-different...
Doing layoff before that is beneficial for employer to save on labor cost (not paying low productivity time), and employee (allows better planning)
If you have to do layoffs, the best time is now. The second best time is a couple weeks before financial reporting ends.
https://www.wsj.com/articles/why-companies-do-layoffs-around...
I really like GraphQL but agree that it‘s not trivial to implement well.
I also think it recently became a bit less relevant for web applications (React server components come to mind) but it‘s still very useful for some web apps, mobile apps and generally for designing nice APIs.
What does this even mean?
> What I am saying is that GraphQL should not be used at runtime to do these dynamic magic queries, which is the key feature in Apollo.
What does this even mean?
How are you defining "dynamic magic" and "deterministic content"? GraphQL sends a query to a server that resolves it into the requested data. Is it not true that if you plug this into something like PostgreSQL via Hasura, you naturally have "determinism" in the same way Postgres offers it?
Please, expand, I have no idea what you're saying and I'm a full time web guy
It is not a silver bullets but it has advantages like self-documenting (Playground), ease of discovery on big API (generated documentation with types) and can have TypeScript type generated for your (reduce the number of interfaces/types to maintain).
Federation is also a good concept if you have many teams that need to converge into a cohesive API gateway.
Overall, if you use it properly it can be a great tool.
> Modern apps are built on the supergraph
Lots of companies have been hiring for growth or for investment. What the companies should have done, though, is hiring to unblock. A couple of engineers build a product that turns out to be generating amazing growth, and then hire a team to polish the system.
So I hope I don't come across as rude or anything, but I want to provide a counter-anecdote.
I was laid off in very early November. I took about 2 weeks just to get over about 80% of my saltiness at what I considered to be a betrayal. (I won't go into detail, forgive me, I'm still not able to talk about it without being salty yet.)
I then asked my two best tech friends (1 from college, 1 from my first job) for referrals to the companies they worked at. I did 2 interview loops, got 2 offers, and picked one. I got a ~10k raise over my last position in the process, though mostly out of region arbitrage (last job was geo-adjusting me down ~10% whereas my new job was not, but it's a smaller company and an earlier stage company, so less cash to sling around, but more equity).
(for the record, I have 9 years of experience and the position is "senior software engineer" which was the same as the job I got laid off from).
So - to all you fellow laid off peoples - don't rely on anecdotes from strangers on the internet. I wouldn't have ever made this post as a top-level post, but I hope my 2c calms folks a bit.
(And for the record... I was intending/expecting to apply to more than 2 companies, but I was a bit sick of applying to companies where I didn't have an inside opinion on the culture bc I felt like I got burned by tha tlast time, so I gave these 2 companies (where I did have that inside opinion) the benefit of being the only 2 companies in my first salvo of interviewing, so I could give them extra attention. And I happened to get an offer I really liked at a company I feel good about, so I took it, even if I guess I probably could've optimized a few more k of base pay if I'd grabbed more/bigger companies in my first round.)