"As of January 31, 2022, we had 7,461 employees, of which approximately 67% were in sales, marketing and customer success, 20% in engineering, product development and customer operations and 13% in general and administrative. We had approximately 69% of our employees based in the U.S. and the remainder in international locations."
> 67% were in sales, marketing and customer success, 20% in engineering, product development and customer operations and 13% in general and administrative
Ratios like this are fairly common.
I think the confusion comes from engineers who look at a SaaS and assume it's mostly engineers like themselves. Engineering is a small portion of the headcount.
A lot of customer-related needs scale with the number of customers. Any company with a huge number of customers is going to have a lot of headcount related to dealing with customers.
For some, the confusion comes from "wow, that's about half the headcount that Microsoft had when I started in the mid-90s, and MSFT was building, selling, and supporting Windows, Visual Studio, Office,..." Perhaps DocuSign's products are, in fact, about half of Microsoft's big three products, but of what I know of DocuSign it's still a big number to me.
Microsoft in the mid-90s outsourced the majority of sales and customer support to retailers and VARs. If you add up all the employees working to sell and support Microsoft products in external companies the total staffing was enormous. The same situation applied to their competitors like Novell.
I wasn't around then but is it possible that we have learned more about B2B SaaS since the mid-90s through trial and error? And the conclusion the industry has come to is Microsoft would have been better off at that time with more sellers and customer ops hires?
How many programmers did Microsoft need for 1 million OS installs vs 1 billion? The reason software can be such a money maker is that the marginal unit costs are close to zero.
I don't know the answer to either of those questions. But I don't think the economics of desktop OS distribution have changed all that much in the last 30 years. I'd imagine the marginal unit costs have gone from very cheap to basically nothing now that physical media is a rarity. If modern OSes take more development effort (which seems likely), I don't think that changes the economics.
I bet there's some market analysis of SaaS companies showing how differently they can be run. I wonder if it's bimodal - SaaS with <10% sales headcount, and SaaS with >50% sales headcount.
> Any company with a huge number of customers is going to have a lot of headcount related to dealing with customers.
Unless you are Google, which is then again where a lot of people in engineering can get confused as most companies don't hate their users quite as much as Google ;P.
This is also where companies can save a ton of money if they develop tools that allow customer facing employees to do their jobs much more efficiently.
Right, so maybe 750 developers? If that? Some companies are heaver on product and customer success headcount than others, but I would not be shocked to find out they had quite a few less than 1000 developers and developer managers.
I've been impressed by Docusign the few times I've had to use it. And I generally hate 95% of the software I come across. Everything seemed to snap into place, was perfectly intuitive. That stuff is easy to get wrong, as evidenced by all the crap out there.
It's not managed to annoy me, which is quite impressive. I never really considered Docusign anything special for usability, until your comment, but that's because it gets out of your road enough not to notice it.
And to their credit, I've been able to sign documents on Linux via Firefox without hassle. Half the time, some shitty SaaS apps will just sniff my user agent and block me.
And it may be worth noting that the alternative is often to go physically into an office someplace or get various notorizations or Medallion Signatures through your bank.
They do substantially more than the click-to-sign part. ID verification, contract management system, electronic notarization, APIs for automation of the whole thing, mobile apps...
In a very crude way, sales is about landing new deals or expanding. Customer success is about securing renewals for existing customer and increase adoption, prevent churn. It is a post-sales role.
IIRC (It's been a while since I've worked with their teams) Customer Success was handled by the 'integration support' at Docusign.
If I -also- recall, When I did an Auth0 integration (a few years before that) I worked with a similar 'Customer Success' specialist while evaluating for an integration.
I think this is the trade-off that's happening; By putting integration support under a 'marketing' budget rather than a 'support' budget, it allows for a happier adopting customer base.
I must add however; those examples stand out to me not because it was 'sales-y' but because they were extremely memorable times of a vendor team working very hard to lead our teams into a pit of success. The best analogy I can think of is the difference between someone on a call giving a vague phrase you have to search through API docs for, vs a direct link to documentation complete with verbose-yet-sane examples.
What you say is mostly true, but in the case of sound recordings from before 1972, it's actually the opposite. At the time such recordings were made, they were subject to an infinite copyright term! The Music Modernization Act [1] passed in 2018 to put a finite life on those copyrights. As a result, all sound recordings from before 1923 become public domain this January.
> they were subject to an infinite copyright term!
If so, that law was unconstitutional:
"[the United States Congress shall have power] To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries."
Can't speak for the GP but IME, absolutely. It's much easier to dig in deeper with (much) clearer signal about somebody when they are talking/working with their own code/project. Less distractions/confounding factors/proxies, more direct inquiry and you can go as deep and broad as you want to map the edges/gaps of not only what they know but what they care about/prioritize and why. The proof is in the code.
Dilution is a red herring. It doesn't change the value of your shares (theoretically). What will matter is how the company spends the funds that it raises, and whether it does so in a way that generates a positive or negative return on investment.
Here's how I'm thinking about it with example numbers: I own 0.1% of the company. Based on our market and performance and valuation of peers I expect us to be worth $10b.
With no dilution my stock is worth $10mm (minus taxes, strike price, etc.)
With 10% dilution per round and 4 more funding rounds, it's now worth $6.5mm.
You expect the company to be worth $10b at some point in the future, but the question to be answered is how much you think the company is worth today. Let's say you think the company is worth $10m now, which makes your stock worth $10k. Suppose the company then raises $90m in funding and gives the investors a 90% stake. Now your shares are only 0.01% of the company, and you think "Oh no, I got screwed by dilution!" But the company is now worth $100m, because it has its previous $10m worth of assets plus $90m in cash. So your 0.01% is still worth $10k.
What matters now is how the company spends the money. Hopefully they spend it smartly and the value of the company increases 10x. Now your stock is worth $100k. You didn't get screwed by dilution, you got a $90k bonanza because the company was successful.
In case anyone is wondering, interstate wagering on horse races is specifically allowed in federal law by the Interstate Horseracing Act of 1978, so it's not affected by this reinterpretation of the Wire Act.
Not through an ordinary appeal, but they could file for an extraordinary writ. Given the number of small claims cases that Equifax has been facing, it might be something they would consider.
Except that Service Worker support is a prerequisite for supporting the standard Push API, and push notifications are probably the most common usage of Service Workers. So it's a reasonable question.
Safari on the desktop has supported push notifications for a couple of years, with no indication they will be coming to iOS. I assumed go was referring to those push notifications, and not a different type of push notification.
Offline support is the core reason for Service Workers and using the offline capabilities is literally a prerequisite for handling any other events from additional specs.
They were simply confirming the plain meaning of the FDCPA, which applies to people who collect debt that is owed to another person. Junk debt buyers buy their debt outright, so they're not collecting on someone else's behalf, so FDCPA doesn't apply. If people are upset about this, they should direct that toward Congress for not having amended the law.
I believe directing ire at the SCOTUS for being that bone headedly idiotic in that decision, especially in a political environment where they had to have known there would not be a legislative solution anytime soon is also warranted.
