Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What software engineers can learn from the rapid collapse of Fast

newsletter.pragmaticengineer.com

Post reply on HN
Print view View original

31–40 of 482 posts

Re: What software engineers can learn from the rapid collapse of Fast

#31

Post by lmeyerov »

Oof, just one of our customers pays about the same as their full revenue, and we're a cockroach team.

The real thing here is they're not that surprising. A lot of companies with their kind of funding use enterprise sales to force say $5-10M ARR, but there's only so much VC money can force for a leaky funnel, broken product, and overall incorrect market + fit. I didn't appreciate this until maybe a year or two ago. Valuation multiples in 50-100X range are super common (and even wackier numbers in seed/a). Think make believe stories like "well with another 12-18mo of growth this really just a bit over a 30X on some future forward revenue multiple...". The cash almost always leads to overspending, and it's highly unlikely the next 2-3 raises won't blow up and everyone goes home. I'm actually super impressed by the Docker team because they've been one of those rare cases of crawling out of that trap, even if with a lot less of the team.

We get job candidates with high competing offers for companies I know to be rotten inside, yet there's only so much I can say. "Our new hires are getting paid from customer revenue and with equity that doesn't have $50M-$500M of investor thumbs on the scales already cutting you out in 95% of the likely scenarios" generally doesn't punch through the kool aid.

Re: What software engineers can learn from the rapid collapse of Fast

#32

Post by gregdoesit »

gowld wrote: post #21
gregdoesit wrote: post #12

Earlier quoted context omitted.

Author here. I was wrong on this information and updated the article - got a correction since. L6 and above employees would receive this: staff+ engineers, eng leadership, sales etc. There are companies where this information does go out to all employees in the spirit of radical transparency. Skyscanner is an example where every day, every employee gets the full revenue breakdown. These numbers are also shown on moni…

> staff+ engineers, eng leadership, How does this even exist at a company with essentially no revenue? This should be at most 1 person in "staff+ engineers, eng leadership"

This is a hallmark of a scaleup which assumes it will become a massive company in a short amount of time, and sets up its structure accordingly.

There are times when a gamble like this pays off. Take how Uber built their organization and systems similar to how Google did it, even when they were smaller.

In the case of Uber, their approach, you could argue, paid off in the sense that Uber did get traffic that would have been non-trivial to handle, and complex business use cases that it could handle easier thanks to it's structure.

My view is that this approach is an all-or-nothing setup and it might end up poorly - and spending WAY more money than needed - than if taking it one step at a time.

Also note that Uber did operate in an environment when it could raise ridiculous amounts of money as it scaled up. This doesn't seem to be the case in the current funding environment of 2022, which has cooled down considerably from 2021.

Re: What software engineers can learn from the rapid collapse of Fast

#33

Post by lolsoftware »

mwcampbell wrote: post #20

I think the most applicable warning for engineers when it comes to the actual work, as opposed to whether one should join a particular startup, is this: > Engineers calculated the load Fast had in needing to serve their traffic. The Fast button was rendered less than 500,000 times per day - rarely needed to ever serve more than a few requests per second. > One of the few warning signs engineers noticed is how Fast sp…

The TailScale folks caught a bunch of flak for their "do things that don't scale" approach to databases. But, honestly, most startups would be better off following that approach than what Fast did. Sounds like the engineers were just entertaining themselves with shiny toys rather than solving the problems they actually had.

Re: What software engineers can learn from the rapid collapse of Fast

#34

Post by mwcampbell »

lmeyerov wrote: post #31

Oof, just one of our customers pays about the same as their full revenue, and we're a cockroach team. The real thing here is they're not that surprising. A lot of companies with their kind of funding use enterprise sales to force say $5-10M ARR, but there's only so much VC money can force for a leaky funnel, broken product, and overall incorrect market + fit. I didn't appreciate this until maybe a year or two ago. Va…

I'm not familiar with the phrase "cockroach team" in this context, and the obvious web search didn't help. Can you please elaborate?

Re: What software engineers can learn from the rapid collapse of Fast

#35

Post by Spivak »

mwcampbell wrote: post #20

I think the most applicable warning for engineers when it comes to the actual work, as opposed to whether one should join a particular startup, is this: > Engineers calculated the load Fast had in needing to serve their traffic. The Fast button was rendered less than 500,000 times per day - rarely needed to ever serve more than a few requests per second. > One of the few warning signs engineers noticed is how Fast sp…

And if you think this is undersized for comedic effect I did ops for a company that went from <1mil to 15mil revenue (with the same sales strategy of targeting lots of small clients) on 4 1u white label supermicros. Two app servers and two MySQL dbs. Never in my life had such reliable infrastructure.

Re: What software engineers can learn from the rapid collapse of Fast

#36

Post by Jemaclus »

lmeyerov wrote: post #31

Oof, just one of our customers pays about the same as their full revenue, and we're a cockroach team. The real thing here is they're not that surprising. A lot of companies with their kind of funding use enterprise sales to force say $5-10M ARR, but there's only so much VC money can force for a leaky funnel, broken product, and overall incorrect market + fit. I didn't appreciate this until maybe a year or two ago. Va…

> we're a cockroach team

I think I know what you mean by this, but I'm not sure. Could you elaborate on what this means? Thanks in advance. :)

Re: What software engineers can learn from the rapid collapse of Fast

#38

Post by ChasingEchoes »

AYBABTME wrote: post #18
adamsmith143 wrote: post #7

That Startups are fundamentally risky and despite all the talk on HN you are highly likely to spend years working in a high pace high stress environment for equity that will ultimately be worthless or at best match comp at FAANGs all while having questionable WLB.

But working at FAANG is not much fun. I think a mix of both startups and Big Tech leads to a happy life.

i guess its up to what everyone is looking for.

I personally avoid start-ups like the plague. To the point where i dont even bother accepting linkedin requests from startup people

Im not that big of a fan of "Big Tech" either, i wouldnt go for something like FAANG, even if maybe the pay would be good

What gave me a happy life was "industry" firms. In my case those were either consultancy/strategy firms (MBB/Big4 ) at first, which was stressful, but had good advancement chances (jumping steps based on performance) and very good networking opportunities.

Now i've retreated in "an industry". In my case a forbes 100 company in the automotive sector (they have cloud systems and develop software too). And life is bliss.

Re: What software engineers can learn from the rapid collapse of Fast

#40

Post by lupire »

gregdoesit wrote: post #32
gowld wrote: post #21

Earlier quoted context omitted.

> staff+ engineers, eng leadership, How does this even exist at a company with essentially no revenue? This should be at most 1 person in "staff+ engineers, eng leadership"

This is a hallmark of a scaleup which assumes it will become a massive company in a short amount of time, and sets up its structure accordingly. There are times when a gamble like this pays off. Take how Uber built their organization and systems similar to how Google did it, even when they were smaller. In the case of Uber, their approach, you could argue, paid off in the sense that Uber did get traffic that would ha…

Uber had revenue and millions of customers begging for someone to offer the service.

Google did not have "staff+" when it was starting out. It had founders and a couple of hires.

Post reply on HN