Wait - there’s a lot of assumptions being made in this thread. Is everyone you’re referring to a former employee? Are you sure you had RSUs, proper, as opposed to options?
If you have options, this is entirely because of the different treatment between ISOs and NSOs.
Is it possible you thought you had RSUs but instead had options?
Yes, all former employees (current employees that hold RSUs are offered sell-to-cover, no worries on upfront tax by cash). And yes, they are RSUs. As for options, ex-employees need to pay to buy options when leaving the company within 90 days.
Well, for options it's more complicated than that - you can have ISOs that convert to NSOs to allow people to defer having to exercise illiquid options when they leave the company. So that's where my options question was coming from - the scenario you describe is VERY common in a scenario where ISOs have converted to NSOs upon leaving the company.
But okay, you have RSUs - how familiar are you with your agreement? It could have been a double trigger vesting arrangement, where the shares "semi-vest" over time, but then they don't fully vest until a liquidity event, at which point poof suddenly all of those ghost shares become REAL shares. If that's the case, they likely baked in a process for employees to have those shares withheld, or auto-sold during the lockup period. It's all tied in with their HR system and other payroll processes to make that easy.
Another scenario is that at some point since you left, or right before the IPO, they re-issued everyone's shares to be a different share class, because they wanted to clean up their cap table before going public. For employees they could just fix that for them, because again - all baked into the existing systems. For previous employees (and people who were gifted stock and former board members and advisors and angel investors and whoever else), they don't have an easy way to fix this. The old stock class technically doesn't exist because its been converted, so they can't sell to cover, and when they convert, they couldn't automate that because they don't have your withholding information and other payroll details for compliance purposes.
In either scenario, it's worth either reading your agreement carefully and/or talking to an attorney. Regardless, however, if this was related to an IPO, the legal and compliance stuff on this is going to be buttoned up and carefully done, so assume that (however unfair) they either have to do this in this fashion or it's much easier for them to do it this way (or some combination of both). It is possible to do very shady things during a private transaction, even a private transaction with a publicly traded company, but not for an IPO.
There are companies that will loan you money to cover vesting costs or these types of situations - they'll do it at shitty rates, but if the options are losing out on a windfall or losing an extra 10-20% on the windfall, it's worth considering.
> It could have been a double trigger vesting arrangement, where the shares "semi-vest" over time, but then they don't fully vest until a liquidity event, at which point poof suddenly all of those ghost shares become REAL shares.
Exactly this.
> If that's the case, they likely baked in a process for employees to have those shares withheld, or auto-sold during the lockup period. It's all tied in with their HR system and other payroll processes to make that easy.
In the agreement, they said this is up to the company, and the company chose the "pay tax to me or forfeit" option.
> There are companies that will loan you money to cover vesting costs or these types of situations - they'll do it at shitty rates, but if the options are losing out on a windfall or losing an extra 10-20% on the windfall, it's worth considering.
Thanks for this advice. Agree that this seems like a viable approach. Appreciate it!
I spend a lot of time on pricing and packaging of SaaS software and the challenge is real. Everybody says they want simple pricing, which often aligns to seats or MAU - but then they want usage-based pricing, but then they're concerned about unpredictable costs and spiky usage.
Unfortunately, there's no such thing as a free lunch - you can have simple and predictable but you will have some users that you pay for that aren't getting value. You can have usage-based billing, but then you run the risk that anyone who uses an antipattern for the product will suddenly cost you a ton (or consume all of their allocated quota and be dead in the water, which is differently bad).
The more flexibility you offer, the more complexity you're putting onto customers and sales teams to understand what's the best way for them to consume the software.
There's also a lot of market pressure to "follow the crowd" - even if you have an option that is (in your mind) more customer friendly/favorable, if you are structuring your pricing differently than the competition, there will be customers who are concerned that they're not getting "a good deal" or concerned that the structure will end up being less favorable to them over time (after all, why does everybody ELSE do it this other way?). Sales reps also prefer pricing strategies that are at least structurally consistent with other products on the market, because it makes their lives easier.
Similarly, it's very difficult to change pricing nad packaging later on - changing price is relatively simple, but changing units of billing or retiring an old offering can be an extremely difficult task.
(disclaimer: these are just my own opinions, everything is hard)
I've seen companies square this circle with capped hybrid billing strategies. Customer gets charged the min of bills. Bureaucratic customers that need specific billing models can pick them but most people will accept the savings.
It's funny, this was actually one scenario that I thought about mentioning but I had to get on a plane and was running out of time.
It is true you CAN do this, but very few do, for a few reasons:
One is, it's bad for margins - when you build a pricing model, you inevitably end up creating a system where some customers subsidize other customers. You assume each user or unit of usage is going to cost you X/unit and you charge X+Y. There is inevitably going to be a distribution of users and their usage patterns and costs, and the 90% percentile is probably going to be 5X, and the 10% is probably going to be .2X. There's not any malice there, it's just that different users have different usage scenarios and they use the product differently.
Another reason relates to the issues with usage-based billing. Even in that scenario, whatever usage dimension you measure on will have users that don't fit the profile and they still end up being subsidized (from a margins perspective) by customers that DO map to the profile. A really naive example - you're a database company, you want to be cheap for people to get started, you go with usage based billing and charge based on storage. For most customers, that works - assuming your product value is apparent and differentiated, I think most people would understand that "I have to pay more because I'm storing more data, and accessing that data can be more expensive, queries more complex, and the utiltiy that I get from the database scales as the quantity of storage increases". Great, usage based billing, let's do it.
But - then you have users who store very small amounts of data but with incredibly high query volumes. Your options are to either just eat the cost of those users (which might be fine for some amount of time) or now start to add additional dimensions on which you meter usage. So now you charge for storage AND cpu time AND maybe concurrent connections if that's a problem AND bandwidth. Congratulations, you have now created the perfect usage-based billing model, which perfectly assigns customer charges to handle the multitude of usage patterns that customers experience.
BUT, it's really complicated to explain to people, and it's really complex to predict costs. That has two implications, one of which is that your value proposition has to be increasingly compelling as complexity increases. To use the database example, at some point someone at a customer will say "honestly, wouldn't it be more predictable if we just spun up a couple of VMs and ran a database instance ourselves?". Complex usage-based pricing works if you've got incredible technology that would be difficult to impossible for a customer to deploy themselves, but if your value prop is convenience and/or abstraction, you're diminishing that value as you make the pricing model increasingly less convenient and less abstract.
The other factor is that someone has to build and manage the metering of all of these things. Even a single dimension like storage is complicated - how do I bill for additional storage? Do I look at the total storage at the end of the month and multiply by X? That hurts users who, say, run end of month batch jobs - but for you, users that use huge amounts of temporary space and then free them before the end of the month, that hits your bottom line (depending on your own architecture). So maybe you want to charge on a daily basis, but now every problem gets more complicated.
Then, if you extend that across multiple billing dimensions, it's just gotten harder and more complicated. Now it's rock and a hard place time - you can stick to one abstract usage measure that is easy to reason about, but you're inevitably going to have some users that underpay based on that usage measure and some that overpay. Or you can add more dimensions and make things more "fair", but everybody's lives are harder, both for the customer and for you and your team.
When you give customers automatic optimization, you get the worst of both worlds - you make less money on the bottom 10% (usage-wise) of users/customers because they end up falling into the usage based billing, and you make less money on the top 10% because there is capped upside for you as the provider. For customers, sure, it saves them money, but what you're really giving them is a price cap (not to exceed X).
I would say for the sales teams, it's also not great, because they have all of the challenges of explaining two different models. For enterprises, it's a mess because 1) they'll probably want to negotiate specific billing terms for their use cases (we don't want to pay X for bandwidth, we want to pay Y) and other structural terms, all of which your billing system needs to support.
At the end of the day, however you charge for anything is an abstraction layer on top of your costs. That's true if you charge per user, or per object, or per gig, or per connection, or whatever else. It's all unit-based pricing even if it's not usage-based procing. You have to decide how much work you want your engineers, customers, salespeople, etc. to do in order to build, explain, and understand how much someone will pay for software.
My general advice is to pick the simplest pricing model that protects your margins and prevents abuse. For infrastructure-y products, things like storage, compute, network, are all reasonable meters. For SaaS products for business users, per-user pricing is well-understood, and there are things you can do if you really want to apply a usage-based element there (bill based on MAU, or have a MAU component separate from seats purchased). But there's really only two scenarios - you pick a small number of meters and understand that some customers will subsidize other customers, or you meter across a bunch of dimensions that align to your costs and create a lot of complexity for your customers. Blending the two gives you worse margins and the complexity of both options combined.
Yes, it's worse for margins. However, we're in a thread about how potential customers don't want to risk either spending lots of money for services they won't use or dealing with spikes. Not choosing one or the other inherently puts the cost on the provider, shrinking margins.
I don't think it's an especially hard model to understand though. It's commonly called pay-as-you-go in consumer mobile plans and sold as the cheapest option to customers that may not even speak the language the fine print is written in. Those consumers still understand the service they're getting.
Telecom is actually a good example of how granular billing can get, but still produces an incredible profit margin even with simple pricing strategies.
Sure, it’s also very easy to understand paying for deli cold cuts by the pound, but it doesn’t make it a good comparison.
Consumer telecom is a great example of a very constrained problem space. There’s two levers, call time and data. And the population of people who are consuming that are limited to the size of the family.
By contrast, enterprise telecom is incredibly complicated, with variable pricing by region, by time, type of inbound number, and then the software that sits atop that telecom is an additional license.
Telecom is also largely a commodity - one provider is the same as the other. SaaS providers are fundamentally trying to not be commodities, and so the comparison is weak at best.
Consumer telecom is simple because providers have chosen to simplify the pricing strategy, not because they don't have other billing metrics available. You aren't required to have a complicated pricing structure even for incredibly complicated services. Doing so is a deliberate product choice with consequences.
They're also not truly fungible, though that's mostly for the higher end of the consumer market. Think about TMobile's "uncarrier" marketing, or Verizon's network coverage marketing.
And they have high enough volume to average out the outliers.
Did you know that in New Zealand, some business/server telecoms offer different plans based on how much of your traffic goes overseas? It's connected to the rest of the world with, like, five really long and expensive underwater cables, but it's also a not-quite-tiny market itself and if you can serve customers in NZ from a server in NZ, you can avoid expensive routing. (Your customers will also appreciate having a ping time lower than 300ms, even if they don't know what ping time is)
Meanwhile, ISPs in Europe don't charge you extra based on how much traffic you send to New Zealand, because you could max out your 1Gbps flat rate with NZ-bound traffic and it would still be a tiny percentage of all their traffic anyway.
I think now we're just arguing semantics. The only billing metrics for cell phones that are visible to the user are usage in minutes and data. This is the easiest type of metric to understand and meter - because it's pure aggregation, and you have a fixed window over which you count the number of bytes or minutes consumed. Compare that to technology metrics like storage consumed, query executions, etc. where the variability in units and behaviors can be massive.
What would be other metrics that you could bill consumers for that they could do anything about?
> You aren't required to have a complicated pricing structure even for incredibly complicated services. Doing so is a deliberate product choice with consequences.
You're making my point - the simpler you make it, and the more abstractions you put, the more decoupled each billed object is from the underlying costs. The implications of that are that you have to be careful about making sure that the economics work out, and that means either you have some customers subsidize others or you are very confident that customers can't use your product in such a way that it turns your numbers upside down. At the same time, that abstraction that you choose will not map to how every customer wants to buy.
To go back to several posts ago, "per user" pricing is a per-unit abstraction that lots of customers like and understand. Sure, customers recognize that some users will use more than others, but it's a deliberate product choice that you abstract the more complicated dimensions from the users.
It sounded like YOU, as a buyer, want a DIFFERENT abstraction, which is "usage" - and again, that's reasonable, but as a product team have to make exactly the same calculus, which is "what metric do we use instead as a proxy?", with the understanding that there are lots of SaaS products where usage patterns are highly variable and it is difficult to come up with single units that cover your bases without making the per-unit price higher than it might otherwise be.
It's not hard to imagine yet another buyer who says (assuming the product metric chosen was "storage consumed"), "wait, I like usage billing, but your per-GB cost is really high for us, because we store a lot of data, but we don't access most of it - why can't you just charge me for data accessed?". You either say no or add more billing dimensions.
> They're also not truly fungible, though that's mostly for the higher end of the consumer market. Think about TMobile's "uncarrier" marketing, or Verizon's network coverage marketing.
It's interesting, because that ALSO proves the point, because the only differentiation you are citing are things other than what customers are being metered for. There's availability differences, but that's orthogonal to the billing metric. If I have connectivity, my minute on tmobile is the same as my minute on verizon is the same as my minute on mint, and the differentiation is everything OTHER THAN the billed minute.
To wrap up - I don't disagree with you that there are benefits to usage-based billing. The point that I am making is that for essentially any SaaS product that has any depth, it can be difficult to pick a single metric at an attractive price point that a) covers your margins across the spectrum of usage behaviors, and b) maps to the metric that the vast majority of your users want. If you try to make everybody happy, you either lose the simplicity or you hurt your underlying margins while simultaneously making everybody's lives harder.
But by their own admission, other than for two states they don’t uniquely count people, it’s counting admissions. That could skew the numbers meaningfully.
Yeah, I think this is a big factor. I only know maybe 1 or 2 people who had been committed. They definitely have multiple commitments though. That seems to make sense as it's similar to some other medical issues where once you have one problem there can be second admissions if it's unresolved or encounter secondary issues.
As someone who rented for 20 years in NYC, this is a bizarre scenario you describe. You deal with a broker during the leasing process, and then after you lease it, you pay the landlord, they have to sign the lease and approve repairs, and are the person with whom you review lease increases. The most arms length relationship I have ever heard or seen is having an admin assistant for the landlord handle all the operational things.
I have never seen a situation where the broker is responsible for the lease terms, because in the end the landlord has to sign their end.
Brokers have gotten more “savvy” where they’ll actually act as a de facto property manager for a small fee or even for free and absentee landlords buy in because it’s less work for them (no communication at all with the tenant). And then the landlord wonders why tenants never stick around for more than a year!
I tried to confirm your assertion about this grift but someone downvoted my previous comment saying as much. Just to reiterate: you’re right. This a real, relatively normal situation in NYC.
In NYC, rents went way down, to the point where there was a sticker shock from people who moved to NY during Covid and were shocked when prices went back up a year or two later.
ok, I checked .. this article [0] says that rents in 2020 went back to 2011 prices.. new to me, so yes, I could write more carefully.. my mistake. Overall, I don't retract it.. rental prices are steeply greater now than 2020 AFAIK
NYC during covid was crazy. Buildings were offering 12 month leases with 4 months free. So when things normalized in 2021/22 people were facing 33% rent increases and then the pace of the increases basically never slowed down until this year.
Which makes sense if you look at demand. We went from people will never live in cities again at the height of covid, to things like revenge travel and everyone wanting to give big cities a try now that prices were briefly down.
Yeah I got 3 months free to stay in my tiny Gowanus apartment. It ended up saving us enough to get us over the line on a down payment on a house later. It was a really fortunate turn in an otherwise miserable year.
Right, you CAN set that up, but in the US, not accepting visa and Mastercard is essentially untenable if you are a retailer or restaurant. You might be able to avoid accepting AmEx, but from talking with restaurant owners, the biggest spenders are often AmEx holders and are annoyed at having to use a backup card.
It’s not justice towards the employer, but justice towards your peers, both those who you work with directly, as well as those who are negatively impacted because you took a job that could have been someone else’s.
If you want to have multiple jobs at the same time, there is a vehicle available for that, it’s called “consulting”.
I don’t think anyone should have loyalty towards their employer - you should be free to jump ship to a better gig whenever you want, in the same way they are free (in the US) to let you go at their convenience. But taking multiple full time jobs is wrong, imo.
How would they be able to link that? Document owners can't see non-domain users who viewed a particular document (and even for domain users, that can be disabled).
My recollection is that, at the top-right corner of the screen, you can see the email addresses of the other people who are currently editing the document (but not those who did in the past). If they aren't logged in, you'll see them as names like 'Anonymous Aardvark' instead.
That is inaccurate. You only see individuals with whom you have directly shared the document with and/or people in your domain (if a business/enterprise customer). For anything link shared, you see the anonymous animal names.
There are lots of family owned businesses in the US that look after their employees. I think it’s more that there are significantly fewer tech companies in general that are family owned businesses.
I think maybe it's because the tech industry is so young, and because it was mostly populated by the young when it exploded in the 80s and 90s.
In IT I've never has a boss a generation older than me. Folk were/are basically my generation. In the early days there wasn't an "adult in the room" so we made it up as we went along.
We (as people) tended to be more about "people" than "money" (although I'm sure not all ex employees would agree.) There's a fine line between caring for people and staying profitable. But one can do both.
I'm not one for job-hopping (and I've likely left cash on the table for that) but that seems to permiate down. (Half the staff are 10 years+ now). We're also only adding a few posts a year. We don't hire fast. We don't fire fast.
But the industry in general was build by narcissistic folk in their 20s, who had ideas like "young is better", grow-fast, high risk, break things etc. IT culture is still like that (despite us being in our 50s now.)
But I don't think this reflects the world in general, or indeed industries in general. I feel like most people want a stable job, a stable life, and dont feel the need to move all the time.
As an employer, the OPs criteria of caring what happens to our staff has been front and center when succession planning. Just cause we retire shouldn't mean they're out of a job.
- charcoal - no roofs or balconies, but terraces and backyards are okay. You do need 10 feet of clearance from walls and fences, but this is less rare than you might think. I’ve lived in two places that met this criteria and have a few friends that did as well
- propane - illegal in most circumstances except with a very small propane tank
- natural gas - legal in all circumstances as long as installed by a city licensed installer.
It’s true that it’s not as common as it is in the suburbs, but essentially every building built in the last 20 years or major renovations ends up including one or more grills.
If you have options, this is entirely because of the different treatment between ISOs and NSOs.
Is it possible you thought you had RSUs but instead had options?