> 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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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

Whose perspective is that, though?

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

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.

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).

> 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.

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

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?

What do you think drives the unnecessary growth?

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.

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).

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.

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.

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.)

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.

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..

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

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 ;)

>> 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.

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.

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.

There's always a comment here on HN wondering why company X has so many engineers for such a seemingly simple product.

The answer is, unsurprisingly, not that they're terribly inefficient. Rather it's that running a popular service at scale is hard, the long tail of features is really a long tail, and a lot of effort goes into even simple things because small differences really add up when multiplied by large N.

This is a big part of it, but I wouldn’t downplay the inefficiency too much. A pattern I’ve personally seen:

* Small team of 5 devs and maybe 1 manager working on some large area of the product is very efficient

* Startup is growing users/revenue very fast, attracts big VC investment

* Major hiring, a year or two later that same area of the product has 30 devs, 5 product managers, 5 dev managers, 3 designers, a manager of the dev managers, a manager of the product managers/designers, and a manager of the dev and product managers

* There’s too many cooks in the kitchen, nobody feels empowered to make decisions, meetings multiply like crazy, every decision takes exponentially longer to make than before

* Instead of planning 1 sprint ahead, you start doing quarterly plans, 3 year visions, customer facing roadmaps, etc. “Predictability” becomes more important than productivity

* Teams know that only predictability matters, so they start making really conservative estimates, just to be safe

* If you have 2 months to do 1 month of work ... it’ll take 2 months. And this starts becoming the new norm

* Plus, you start spending more and more time planning, “scoping out epics”, etc., to get “better” estimates

You get the idea - pretty soon that 45 person team ships not much more than the 6 person team used to. Nobody is purposefully dogging it, or trying to go slow, but it happens when companies grow unless you’re really, REALLY good at fighting it. And few companies are. Everyone is BUSY, but they’re busy doing quarterly plans, “full potential analyses”, change management, meeting with stakeholders, working on all sorts of checkboxes to get all sorts of security certifications to sell to one or two big government buyers, working on “business development” projects that users don’t care about, etc.

It's also about the kind of features you implement. At the start you implement all the easy features, that's no problem. Once you mature and want to get B2B sales, you need to start supporting all kinds of connectors to legacy Enterprise software, networking stacks and environments. That's much harder and much more frustrating than building a simple ticketing system.

As an example, supporting OAuth is easy. But making sure your software works with all kinds of on prem LDAP for authentication is much harder.

Yeah totally. I think most feature work at a B2B SaaS company can be classified as either trying to drive retention, or trying to drive new sales. The “new sales” features are often focused on one or a handful of potential large customers with very specific needs, who won’t buy without feature X. This kind of work is basically invisible to almost all of your customers, but is necessary to close the largest deals.

I would argue that some of that baggage doesn't make you less efficient. I mean it makes you less efficient at the features per hour metric, but what about the business value metric? If you have meetings to really think things through and plan, maybe whole areas of sterile development work are avoided and that is valuable.

Remember there are businesses that do well writing no code at all! Code or features isn't what it is al about, but in a tech company it is somewhere between nothing and everything.

Yeah, fair point. This is more an answer to “how can you have such a large product/development team, and ship so few new features”, as I believe that’s a natural consequence of having a larger business, with far more communication overhead, far more focus on planning and predictability, etc. That’s not necessarily bad for the business, but it does mean you have a lot of people shipping a relatively small number of features, especially compared with your velocity in your startup days.

Yes companies definitely get more inefficient as they grow, for all the reasons you cite and more. I've experienced it first-hand.

Adding an engineer to a team slows down the whole team a little. There comes a point where adding head count actually results in less productivity overall. This is typically countered by splitting up work into various teams with minimal interaction between them. Like Amazon's famous two-pizza team strategy. This is the main attraction of microservices, each team can own their own piece of the code and change it and deploy it without (ideally) having to consult with anyone else.

There's always a mix between "now we're at scale and need to solve this really hard data sync problem" and "let's build an internal slack clone because we can".

Ouch, data sync his close to home for me. That was my first job. Not an easy problem at all.

Tip for those of you with the same problem, if you can, try to sync both the data and the actions taken to produce the data (event sourcing) and try to eliminate sources of indeterminism.

why both? isn't that wasteful? which one wins if they disagree? do you sync both at the same frequency?

It depends on the business logic. If e.g. a user updates a numeric value on an entity, and there's a conflict probably you choose the most recent value. The action taken (user updates value) is pretty useless in this case. In other cases, e.g. inventory reduced by X because X units purchased/consumed - then it's more important to have the action itself, and a conflict would involve applying both actions and possibly alerting someone if that causes the value to be invalid (e.g. inventory below 0.)

Except for the part where even if you ignore the sales and marketing expenses they're barely breaking even. They're failing to make software for less than they can sell it for, and perhaps some of those hard problems which took 50 engineers to solve would have been better to have gone unsolved even if they lost some sales as a result.

That's normal in a SaaS. They gear everything towards growth in revenue, not necessarily profit, since it's much easier to keep existing SaaS customers (most good SaaS have 95+% retention) than to earn new ones, and at a certain point you've got a flywheel going so that you can perhaps reduce headcount increases or stay flat while your revenue continues to grow, and then you coast into profitability from there.

and a team told their manager they needed to redo all the unit tests in order to stay relevant

I mean, I think the real answer is that most companies use inexpressive languages with heavy emphasis on mutation.

Costs a lot of money to build your own programming language and then throw it out. https://blog.asana.com/2017/08/performance-asana-app-rewrite...

"Our founding engineers had learned from their experience working at Google and Facebook that to ensure a performant and stable application, they would need to build their own framework"

Wow. Interesting.

I didn't believe that was an actual quote from the article until I read it. It sounds like a joke and I can't imagine anyone reasonable would say that.

There are definitely good reasons to build your own framework but performant and stable applications isn't one of them. Usually it's a solution looking for a problem.

In fairness the decision was made in 2009. I still don’t think it was the right decision but it feels a lot more understandable to have made that choice when looking at the frameworks available in 09 rather than 2020.

Was this a front end web framework or back end?

I never worked at Asana but I heard it was both, it had code sharing between client and server, some server-side javascript before node.js (I think it was based on JSC) and something similar to isomorphic javascript before this term was coined by Airbnb. If you look at Meteor, a lot of similar ideas migrated there.

By this logic nobody would ever build a framework designed around performance and stability?

Stability is the result of smoothing out bugs the hard way. A new framework has bugs, you just haven't found them yet.

What? Facebook built react to solve these problems.

When they built Luna stuff like react didn't exist.

Investing in developer tooling including frameworks is a fine use of time and often pays off hugely. There wasn't a better alternative 11 years ago.

At Google or Facebook that makes sense. If you encounter much larger scale than pretty much any other company, it's hard to find libraries that work for you. So the observation was correct but they should've concluded that this is just a result of scale and complexity, not a general strategy.

Keep in mind, Asana was founded in 2008.

Luna had some of the same concepts underpinning React, about 5 years earlier.

That was in 2009 apparently. Maybe it made sense then.

just use nodejs

weird. Not sure how they would have been hired at Google or FB with this mindset.

Dustin Moskovitz, one of the "founding engineers", was a co-founder of Facebook.

Luna wasn’t a programming language, it was a framework. The link you yourself provided equates it to “React, RxJS and Firebase” and states the closest OSS equivalent as Meteor (developed by ex-Asana employees).

Sorry, my bad. Here's the blog post where they announced LunaScript, the ill-fated programming language that they built and then tossed.

https://blog.asana.com/2010/02/lunascript-our-in-house-langu...

IMO this will be one of the failed IPOs of the 2020.

I understand (but not approve) 300 devs - they got a ton of integrations, enterprise client handling, lot of mobile, frontend and backend surface area to cover, lots of devops and support, teams to build new features, maintain tooling and so on... given time, any software team will slow down and scale up, unless it is specifically countered by the company. There's always stuff to be done (create, maintain, or both), pressure comes from the top and the usual response is "throw bodies at it". The less hackerish/the more corporate the company, the faster the engineering team blows up. Kinda inverse function of the red tape.

But the reason I believe Asana is going down is that their product is just what it sounds like - boring. It's a problem that's been solved a million times and they are just lucky they got on the ride in the early days. But they never evolved and the marked is getting new competition every day that is fighting to take their users away the moment they google asana alternatives. On one hand, they got Jira/YouTrack to fight on the enterprise side and Trello/Monday/Clubhouse/Notion to fight at the startup & SMB sides. If they don't evolve their product and bring something unique that will differentiate them and save their customers more time or mental context, they will remain the "boring" choice in a time where people are looking for the "fun" thing. And while it's good to be the boring choice, it's also a good way to haemorrhage users and profits.

If I was steering Asana, I'd look at stuff like Notion and JetBrains Space for inspiration and product evolution, focus on minimising users context burn rate, developer and general UX optimisation and visual noise reduction. If there is no large changes soon, grab some popcorn and watch it burn - I give it about a year before it starts tumbling downwards.

You're making the mistake of valuing this IPO on its fundamentals while currently the market is largely being driven by liquidity.

It's really hard to have a failed tech IPO at the moment with all the demand which is why they're all rushing the gates.

It'll take a large, broad recession to bring tech stocks back down

I'd expect Asana, Unity, Sumo and Snowflake to all pop and stay up in the short term

I'd add AirBNB to the list considering booking is only down 10% off it's high and Expedia is up 100%+ from it's covid-low

This is a Brilliant comment

I was wondering who was going to hit the nail on the head

LIQUIDITY

-> looking for a return, ANY RETURN

That's why all large tech stocks are booming

that's why Tesla has 1,000 P/E

Anywhere that all this Feb Printing Press Money can park itself, that might be safe and/or give return

IT WILL RUSH TO

Anyone who can IPO, should IPO

We are currently in a large, broad recession. Unemployment is at 10%.

We were. It's doubtful that we still are. GDP growth has clearly popped back above negative for the third quarter, which will break the two quarters technical requirement. Most economic readings right now are strong, from manufacturing to retail to job creation.

It's more like we're in the equivalent of the first or second inning of the post great recession recovery now.

This recession isn't broad, it's unusual in its disjointed hit. It's primarily hammering lower income labor and specific types of small businesses. 40% of low income households lost jobs just in the March and April shutdown. That's where most of the job damage was at:

CNBC "Households with income below $40,000 were hit hardest by the coronavirus pandemic. Almost 40% were laid off or furloughed by early April, according to the Federal Reserve."

Jobs in the top 2/3 have largely been unscathed, which is why the broad housing market continues humming along in most regards (whereas housing got smashed in every way in the great recession). It's also why hiring has been so ferocious and unemployment has recovered dramatically faster than during the great recession; it's specifically because the context isn't all encompassing. The great recession didn't spare the middle class and higher income groups nearly so much, it was a very broad recession.

Which all makes sense, this wasn't a normal recession, it was a temporary forced shutdown of some parts of the economy due to a pandemic (further, not all of the economy was shuttered during the second quarter, the majority of the economy kept functioning throughout the pandemic).

A thousand people are dying of COVID-19 every day, it’s not a normal recession, but pretending it’s over is silly. The markets have likely priced in a second stimulus which at this point probably depends on a different president.

Ignoring the importance of the bottom 1/3rd for consumer spending.

There's no alternative to equities. These prices could continue to go up for years, even if the bottom totally falls out.

Where are you getting your unemployment numbers from?

BLS numbers for July: https://www.bls.gov/charts/employment-situation/civilian-une...

By this logic, Zoom shouldn’t exist.

Product innovation and quality represent very little of a company’s value. Distribution is where value is derived, and Asana’s distribution is incredible. And their product isn’t bad!

Many of the highest valuation companies are boring. Boring isn’t a bad word when it comes to enterprise software.

No, you're oversimplifying a lot. Just security and infrastructure operating at Asana's scale requires several dozen engineers. Additionally, Asana has been developing all sorts of features around working with "tickets" - Gantt charts, automation, 3rd party APIs, mobile apps, etc. All of this while working with a large legacy codebase that makes development slow.

(Note: I worked at Asana when it was ~100-150 engineers, and it felt like we could use double that. Having since moved to a FB team, I find I can develop UI features at probably 3-4x the speed in comparison to my time working on Asana UI, simply due to using modern React code with jsx and functional components using hooks)

that relay rebuild tho

Believe me, changing / writing queries ("projections" in Asana parlance) at Asana took longer.

wait and hear, all the justifications around hn that they need 300 engineers. when their competitor basecamp has around 50 engineers. only difference is one is vc funded + dustin's fb funds, while basecamp is bootstrapped. and a lot of sv hype in terms of the tools they use to build asana. basecamp html + sprinkles of js. asana react + redux. on the backend asana 100s of microservices, basecamp 1 monolith. reading the comments, based on experience at fb | google they made their own language. if that's not peak sv shoot me!!

> Investors / boards are wanting to get money out before things turn south I feel.

How would you distinguish that motivation from "Investors / boards feeling that the business is in a strong position, and the worldwide uncertainty from the pandemic has stabilized enough to feel confident about continued growth, so they're ready to go public"?

Why assume such a negative viewpoint without giving any reasoning or arguments for it?

One other conflicting thing about your view, is that if filing now investors are still probably a year out from being able to sell their shares. If they thought things were about to turn south, that's a long time to wait. Surely it would be better for them to sell on a secondary offering and get out sooner if they were sure of that?

I think at least part of the motivation to IPO is that if the US has a new president starting 2021, said person has stated his intent to vastly increase capital gains taxes, probably starting with tax year 2021. Add to that increased corporate tax (which probably affects VCs' math, although I'm not sure how), there's probably a lot of people who would prefer to accelerate their taxable events.

Any IPO at this point (combined with standard 6 month lockout) will result in capital gains being realized no earlier than 2021.

And you don't plan IPOs depending on polls. They're way too expensive and complex for that. You can accelerate the process or delay it if markets aren't receptive but the general decision to IPO won't be made because there might be an unfavorable election.

I'm at a company that grew from 10 to 200 engineers. Basically the first 10 build the actual product, and the next 190 build one-off customizations for enterprise customers.

> Wow, this is a torrent of IPOs today. Investors / boards are wanting to get money out before things turn south I feel.

People have been saying this for months now. Is there evidence that there are disproportionally more IPOs recently?

Snowflake, SumoLogic, Asana, Unity all filed S-1's today.

4 relatively large, well known companies filing IPO's today.

and JFrog (I don't know anything about them, but the S-1 was posted on HN today).

And AirBnB is much earlier in the process but has filed confidentially.

If Airbnb filed their S-1 last week, and these companies filed their S-1s today, then wouldn't Airbnb be further along in the process and not "much earlier"?

They filed confidential paperwork - the actual public S-1 will come months later. E.g. Asana had confidentially filed back in February.

Maybe a surge in IPOs for HN crowd? An IPO of a construction company won't make the front page but Asana does. Maybe VCs increase pressure to cash out or management is motivated by other successful IPOs of the recent past.

I don't know any hard evidence to say if overall IPOs increased but the examples named in this thread are very biased towards tech.

Have they? This is the first time I've noticed a surge of IPOs this year.

Very crowded market - not very sticky either relative to other SaaS type cos. I would avoid this one personally.

Am going to short this one once it is out- saying this as someone who has been a user.

This is a hell of a market to short anything. In the near term anything that helps remote work like this is probably going to spike up. Good luck with that. I know that I wouldn't personally be comfortable being confident I could make collateral to outlast a bubble or guess correctly when the tide is going to turn to make money off of an option trade when it comes to a remote enabling company in a stock market as crazy/driven by politics and the fed as this one

You can offset your short with a long in a competitor. That takes out the market beta. However, it isn't free and it can take a long time until a bad company goes under (not saying Asana is one, haven't used their product).

Wirecard laundered money over years and the FT reported on it, it still took a long time for it to collapse.

Not really - considering the massive premium a lot of "remote" tech stocks are getting I'm surprised that Slack ($WORK) is basically going nowhere.

Asana is closer to Slack than other cloud stocks imo, and given Slack's mediocre performance could easily see the same thing happen with Asana.

Slack's not sexy. Slack will always be what it is, and a dongle or peripheral isn't going to improve that core product.

Similarly, there is no iPhone or GoPro waiting for unleash Asana's potential.

Needful stuff.

Shorting anything now is shorting the federal reserve.

if that were the case why are banks still closer to their 52 week low than high?

Banks generally benefit from steeper yield curves. The yield curve is still quite flat and will likely stay that way due to the Fed buying-back long term treasuries.

"If only you knew how bad things really are"

Hope you have good margin rates, you could be waiting a long time. A lot of these are steaming piles of shit if you think about fundamentals but the market doesn't care about fundamentals.

Interesting, I would say that once an organisation has gone a year or so with Asana, they are very unlikely to move as it would involve creating new processes and re-skilling non-tech savvy colleagues, therefore making it incredibly sticky. Which SaaS companies would you say are more sticky than this?

Zendesk?

Intercom?

Salesforce?

I bet half of their R&D is spent to figure out how to do Kubernetes the right way.

Things already turned south (in March) and are on the rebound now. Those who would've IPO'd a few months ago are starting to do it now.

>Things already turned south (in March) and are on the rebound now.

The stock market is not the economy.

What has changed since March, except a whole lot of small-business bankruptcies and closures, cities burning in mass protest, and an even-closer, tightly contested election with massive political consequences?

There’s plenty to be worried about in the real world, but what’s changed is in March the market was down 30%, and now it’s back at all time highs. The Fed is the most important factor in the market these days, not the economy, and since we’re talking about ipos the market is what matters.

This was my take on it as well, bottoming out around June-ish (off the top of my head. can't exactly recall). I thought we were beginning the steady slog back up?

I’m astonished by all the sibling comments to the affect of “takes a lot of R&D to scale.” Spending to scale some things, like fb, makes sense because the value of the participant network is higher than the cost to scale. What value is created by scaling a todo app past the group of teams level?

Are you going to stop signing up new customers because you've scaled enough?

I know it’s hip to assume the market crash is days away, but what makes more sense is: saas companies have proven to be the most resilient type of company in this market. It couldn’t be a more perfect time to IPO.

The reason the market looks so good right now is because tech stocks represent a significant portion of the indices. Many other stock are still way down (appropriately)

> How does a team grow to ~300+ developers ($89M R&D)

Is it possible to reach a S-1 with a decent valuation with just ~30 employees "market confidence"-wise?

Instagram?

Bought by Facebook?

That's just the way corporate America operates. They hire lots of people because it's a better utilization of money than just giving money back to investors. If you give money back to investors, you're not growing anymore and have failed. If you reinvest (and for a pure tech company with no physical assets, that has to be hiring), maybe one of them can grow the company.

See: https://danluu.com/sounds-easy/

What specific indicators besides covid / asymmetric v-shaped recovery (v-shaped recovery not distributed evenly across economy) are you pointing to? I understand VC's want to favor profitability earlier on in the funding cycle now than say in 2014 - 15, but that was kinda expected before the 'rona hit in March anyway.

Related - why are there so many IPOs particularly right now?

It seems like there is more than usual IPOs this August compared to previous years: https://www.nasdaq.com/market-activity/ipos

There are a few more coming, too.

My armchair guess would be, this is a win win market. Its booming, so you can ride it as it goes up. And if you don't do well, you can blame COVID. A lot of companies were on the cusp and this probably accelerates them all.

Just look at the price action on any big tech stock and pretend you're a tech investor looking for a big exit. People are pouring money into equities, particularly tech.

How about the government stimulus has ended, the economy is in horrible shape, and people are just waiting for the economic crash...

Yes I am surprised too

We do need a return to the regulatory environment where IPOs are non-news due to their frequency and prevalance

Most of the tracking systems require enterprise integrations and need to support migration from other platforms.

Look at Service Now.

I really don't understand how Asana excels at anything, let alone is a '10x'. They probably need to spend a fortune in marketing just to get people to sign up.

It makes a lot more sense for marketers and others like us. I've tried getting away from Asana over and over but keep coming back. Everything else either isn't feature rich enough or is too difficult to use. They manage to strike the right balance. To me Asana is the epitome of the Churchill quote "Democracy is the worst form of government except all the others that have been tried"