[PragmaticPulp]

> How does a team grow to ~300+ developers ($89M R&D) to figure out how to attach PDFs and videos to tickets, and email people when there's a change in status?

As with most of these companies, user-facing feature development is only a small part of the engineering workload.

I would assume the majority of those engineers are working on less visible tasks: Devops, build systems, infrastructure monitoring, security, backups and data integrity, internal tooling for customer support, billing and accounts management, and other critical but otherwise invisible tasks.

Duplicating the core 80% of Asana's features as a one-off product wouldn't be extraordinarily difficult. Scaling it into something that can operate as a business with hardened security, reliable data storage, consistent uptime, and reasonable internal tooling for customer service is where things get difficult.

That said, companies often go overboard with hiring in the run-up to IPOs or acquisitions. Excessive R&D spends can be fixed on the road to profitability. Restoring a company's reputation after a major data loss disaster or a security breach is much more difficult, so it's safer to err on the side of throwing too many engineers at polishing everything. If they can't scale revenues to match, expect the engineering workforce to be cut down significantly.

[dcolkitt]

This makes a lot of sense. But in some ways it shows the downsides of the modern obsession with SaaS.

How many of those jobs would be required if Asana was simply sold in a shrink-wrapped box that you installed on your desktop or the downstairs server run by the corporate IT guy.

In some ways SaaS is a big win because it offloads all those tasks to a centrally hosted service. No IT guy or tower server in the corporate mail room required. OTOH not everyone has the same ops requirements. Not every customer needs 99.999% reliabilty. Or ultra-hardened HIPAA-compliant security. Or heck, even remote access outside the office LAN.

By delivering Asana as SaaS instead of shrink-wrapped software, it means the Asana hosting team has to deliver to insanely tight operational requirements to every single customer. If one customer requires 5-9s of uptime, then basically every customer requires it. That certainly explodes the cost-of-goods-sold beyond selling shrink-wrapped software.

[freehunter]

If it was shrink wrapped software they would need a bigger sales team, a bigger support team, a bigger professional services team, etc. It’s just trade offs.

[dcolkitt]

That's a really interesting point, and it piqued my curiosity. I decided a pretty fair comparison was Red Hat at the time of its 2005 IPO.[1] Its annual revenue for FY2005 was $278 million, so adjusted for inflation, a little smaller than Asana. (I'm annualizing the last reported quarter for Asana, because of its meteoric growth rate.)

But, still a fair good comparison of the shrink-wrapped software startups of yesteryear to today's SaaS business model. Operating systems certainly seem inherently more complex, so that should handicap things in favor of Asana. Of course, Red Hat is just re-packaging what's mostly developed by external open source contributors. But still, if we're talking about the overhead of support/services/sales, if anything that should make things harder for Red Hat.

In terms of COGS (cost of goods sold), its amazing how close the two land together. 14% or revenue at Asana and 17% at Red Hat. Since COGS includes technical support, it doesn't really seem that shrink-wrapped software is significantly more costly to support than SaaS.

For both companies sales is a major expense item. Still Red Hat's model seems to have a handy advantage. Its "only" paying 32% of revenue to sales, whereas Asana is paying a whooping 76% of revenue to sales. To be fair Asana is achieving a much faster growth rate than 2005-era Red Hat. Still, there doesn't really seem to be any clear sign that shrink-wrapped software is more expensive to sell than SaaS. At least in the enterprise space.

However with R&D costs the discrepancy's pretty clear. In 2005, Red Hat was spending 16% of revenue on this line item. Asana triples this rate by spending nearly 50% of revenue on R&D. And again, ipso facto it certainly seems like Red Hat is developing a much more complex product.

[1]https://www.annualreports.com/Company/red-hat-inc

[AlphaSite]

And honestly its actually even more work in many ways, since you need to be able to work anywhere, not just in a well known environment.

[jmnicolas]

In the age of VMs and containers I'm not sure it's still true.

[dx034]

I've been involved in debugging a bug in a software that occurred on Kubernetes cluster at the client site but couldn't be reproduced locally. Reproducing that is so much harder than a similar software installation. You have so many moving parts that it's pretty much impossible to create a test cluster with the same properties.

Also, with SaaS you can get access to log files, if it's installed on prem that can be heavily restricted by regulation.

[sujinge9]

Sure, but it's economies of scale. You only have to do the hard stuff once at the source, instead of having every node do it individually.

Also if stuff goes wrong in the node model, the customer will blame you even if it's mostly their fault. So it's also important for brand benefits.

[bryanrasmussen]

On the other hand if stuff goes wrong in the centralized model it goes wrong for everyone everywhere, and it almost certainly is really your fault.

I agree trade-offs, but I sometimes feel the gain has not been all that great.

[thehappypm]

The point is, Asana has 300 people, but with a SaaS model, their clients need less IT staff than with an in-house server. If Asana has 10,000 customers, they’ve just reduced IT personnel costs across the industry with 300 Asana employees, which is almost guaranteed to be a net cost reduction for the industry.

[vmurthy]

One of the subtle things about SaaS is far less "up-front" costs or fixed costs. This helps sell to business around the lines of pay-as-you-grow rather than commit to x years of SLAs. Shrink-wrapping software takes away this key sales lever and leads to longer sales cycle which might be part of the reason why SaaS models are so attractive.

[janee]

Good luck now having to build and maintain software that needs to reliably and correctly update itself on +70K instances not under your control.

That's not even taking into consideration the fact that you no longer quite know what's going on in those 70K instances, which leads to extremely rigorous tests or the need for a big support team.

It would be interesting to know what costs the Jira self hosted option has put on the product for comparison to Asana's running costs.

[dbtc]

Those downsides could also be considered upsides from a certain perspective: More work, more jobs; the industry grows.

[eru]

Whose perspective is that, though?

Individual companies don't benefit from low productivity, and neither does the economy as a whole.

[dbtc]

I think at least a segment of (an, The?) economy grows from some kinds of unproductive churning. Maybe it depends how you define productive. I'd argue that gambling or gaming are not productive even though they are lucrative for some and fun for many.

[eru]

Well, now we are getting into philosophical territory.

As a simple example, watching a movie doesn't produce anything, but it does give people joy. Similarly, eating anything tastier than the bare minimum gruel to keep you alive and healthy mostly just gives you extra joy.

Orthodox economics is perfectly fine with that. They deal in 'utility'. Fun is a perfectly fine product to deliver.

So eg gambling or playing the lottery can be perfectly rational, as long as you are aware that you are doing it for the entertainment value, and not as a financial investment.

Now for our situation: I hold that the extra work here doesn't provide any net gain in utility. Not even for people who like programming: there's enough other programming work left that's not just churn and that's not any less enjoyable.

Of course, the humble agnostic choice of orthodox economics is not the only possible one. If you are some kind of puritan or a paperclip maximizer, you'll know for a fact that producing fun is not productive. Only paperclips count (or whatever puritans optimise for).

[underwater]

> Duplicating the core 80% of Asana's features as a one-off product wouldn't be extraordinarily difficult

Not to mention that they didn't have the advantage of duplicating features. Developing an application from scratch requires significant experimentation, false starts, deprecated features, associated tech debt, reinvention, etc.

Just because you can drive across the US in four days, it doesn't mean the first explorers to make the journey were lazy.

[manquer]

This is common reason cited . I don’t disagree as such, as my own product grows I see it happening .

However I am not sure how much is strictly necessary.

I honestly think a small team could achieve lot more . You loose the agility of smaller team at >50 have large company problems without the benefit of sheer manpower 500-1000 typically brings.

Scaling devops is not as hard as it sounds . There are plenty of cloud native services which scale pretty well more or less out of the box( you still domain knowledge I.e. need to know that service’s unique limitations)

scaling it for cheap is harder, still not as hard as it used to be, plenty of mature tech is available today. Ironically devops engineers with modern cloud skills generally are more expensive than the ones who know how to stand a server in a DC.

A lot of startups like WhatsApp , Instagram built great products at scale with less than < 50 so it not impossible to achieve

[aahortwwy]

A major reason why engineering teams at these sorts of companies grow so large is because of how quickly the business operates and the company's rate of growth. These factors put the engineering team in a position where they're constantly having to choose the faster, easier option in the present despite the fact that it will produce a lot more work for the team in future. When the future rolls around they're still under the same constraints so they hire more people to deal with the problems caused by their past decisions while making the same kinds of decisions in the present. Rinse and repeat for several years as the company grows into a behemoth before going public.

One interesting thing to note is that as these constraints relax (business stabilizes, growth slows) the engineering teams can make better decisions in the present, clean up the decisions of the past, and reduce their overall need for people. If the company has built a money-printing machine the redundant people are then moved to new lines of business funded by the money-printer. If there's no money-printing happening, margins are super thin, and there's an incentive for the company to cut costs... where do those people go?

[dbtc]

What do you think drives the unnecessary growth?

[manquer]

I wouldn't say 'unnecessary' as such, adding people is one way to solve problems just not the only way

It is easier to solve problems by adding more people, especially when financial resources is not a constraint. However like technical debt, process and people debt will keep growing. There are some methods to have handle on it like the Spotify pod model, but no method is the magic bullet.

Every resource you add is additional cost not just on the payroll but also on the work overhead. 2x sized company will not do 2x work after all. At some point the incremental value of new resource is not worth the incremental cost.

I am not sure many startups consciously think this through while scaling up.

[sheeshkebab]

A lot of internal tools is overengineered bullshit... if that’s what they are spending it on (doubtful though - it’s probably mostly some form of sales).

[dx034]

For most companies I've seen, enterprise sales is what costs most money. It's worth it in the end but there's nothing you can automate around all the calls, forms and processes you have to go through to get a big enterprise client.

Yet many companies invest in it because in the end, the client is happy to pay for all your additional expenses, knowing that they can trust your service.

[rsp1984]

Also keep in mind the old wisdom that the safest way to delay a project is to throw more engineers at it. Hiring engineers breeds hiring more engineers. To give you an idea how many engineers are actually needed, Instagram hat 13 engineers when they were acquired, WhatsApp had 60. And that was 8 or 6 years ago respectively.

[jariel]

Isn't AWS supposed to handle most of that?

Kik messenger had 300M users and a tiny team. Same with WhatsApp - and it's reliable.

Asana scales more or less horizontally, meaning that they don't do anything much at the scale of all of Asanas customers. No individual customer repo should be massive (unlike say Facebook, where a user search searches the entire world.)

[waheoo]

Messenger services live or die by network effects.

SaaS services with easily replicatable software live or die by building barrier to entry, usually this is done by building up a wall of feature add ons and integrations, in the case of Asana, integrate with all the things and suddenly it's a pain in the arse to replicate it all.

I would hazard a guess most the development effort is based around building up that wall of features.

[jariel]

Yes I agree. But my point with the Messengers is that it's not really 'scale' so much. Or dev ops. It's more likely the 'wall of features' and perception in business as being the Gartner 'Magic Quadrant' leader etc..

[tootie]

Ops and Infra should be a fraction of feature development though. Not most of your team.

[zaphirplane]

a technology company’s operational work is larger than its development is a bad signal.

The reason reminded me of when I get quoted a large price for an hours work like dentist or plumber and they are like i have insurance and car expenses ;)

[cryptica]

>> I would assume the majority of those engineers are working on less visible tasks: Devops, build systems, infrastructure monitoring, security, backups and data integrity, internal tooling for customer support, billing and accounts management, and other critical but otherwise invisible tasks.

Most of these other things are absolutely useless.

[dx034]

Companies saving money on backups pay for it at some later date. Also, you won't/shouldn't really pass any audit without sound processes in place.

Billing is easy until you have to serve 200 countries, each with their own regulation and tax systems. Sure, you can outsource that but it won't be much cheaper once you reach scale (as parts remain manual).

And I don't think many would agree that customer support is useless. As a developer, I wouldn't want every customer request to hit my desk. Having customer support that cannot only filter out requests but also respond in a less technical way than most developers is invaluable.

[eru]

Useless in what sense? And which of those things?

Eg backups and data integrity sound rather important.

Eg build systems are only useful as an enabler for the other things your company wants to do, true.