What software engineers can learn from the rapid collapse of Fast • Hacker News Board

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

#201

Post by IMTDb » Thu, Apr 07, 2022, 11:21 PM UTC

dymk wrote: post #189

IMTDb wrote: post #147

The key informations are here : > Fast offered $200-240K/year in base salaries with full remote work > Sign-on bonuses were common and large. Those who asked for almost always received sign-on bonuses of $20-50K as a one-off payment > Equity issued was lavish and presented as potentially life-changing > A good part of people are echoing how working at Fast was an amazing experience. People liked the culture, and how…

> What's not to like here ? I think as a serious counter to that, look at the offers that a FAANG will give you - similar base salary, similar sign-on bonuses. Generally WLB is fine. The real differentiator - they're offering you equity which is liquid right now. If one is risk averse, one wouldn't touch Fast with a ten foot pole.

Some reasons :

- FAANG aren't/weren't remote

- The appeal for working at a startup vs an established company, and the sense of freedom associated with that

- Some guys that would love the idea behind FAANS...but would not like the management/process in place there (OKR, reviews, career ladder)

- Some guys that would love to work for FAANG... but didn't pass the interview (either failed or didn't try)

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

#202

Post by 1231232222q » Thu, Apr 07, 2022, 11:25 PM UTC

how did they even raise any funding with that low of revenue?

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

#203

Post by ushakov » Thu, Apr 07, 2022, 11:29 PM UTC

emgeee wrote: post #196

I was an engineer at Fast for over a year and wanted to clarify a few points-- - engineers did have access to data and could write their own queries to check revenue (but few people did until the article came out). - the strategy leadership decided on was to go after massive enterprise sellers which would, in theory, result in step-change functions in revenue. Many people knew about the low numbers but were willing t…

> The company spent a lot of money on marketing events including sponsorship deals with the Tampa Bay Lightning and the rumored million dollar concert by the Chain Smokers

here we go, this is late 90s all over again

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

#204

Post by jimbokun » Thu, Apr 07, 2022, 11:32 PM UTC

vosper wrote: post #71

EinsDueTresFour wrote: post #45

Earlier quoted context omitted.

I would add that the "Sales vs engineering and sales winning" would be a very relevant warning also: > [sales] signed up a large number of smaller businesses on the platform. [...] However, integrating these smaller businesses was challenging thanks to several customizations needed for each new customer. The ratio of revenue per each small customer vs the total cost of integration (and very likely on-going maintenanc…

> The ratio of revenue per each small customer vs the total cost of integration (and very likely on-going maintenance) was probably at least an amber flag somewhere for those who had visibility of it. At the last company I worked at (won't call them a startup, just a 10-year old small business that somehow kept raising funding but has never made a profit) I was astonished to learn from a new CPO that in our tenth yea…

I worked on a project that had similar issues.

I think what saved us was the unlimited license we had negotiated for the database server we were using (which wasn’t bad technology), expired and then the company was going to charge us through the nose for any new servers.

That triggered a rearchitecture of our system, into micro services that made sense for the kinds of queries, volume, and load we were dealing with. We did have a lot of data, but many of the queries could be satisfied by a key value store, for example, which didn’t require the same amount of hardware resources.

The original project did lead us to products our customers wanted to buy. Then we just had to change the architecture to fit those actual products.

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

#205

Post by throwmeariver1 » Thu, Apr 07, 2022, 11:34 PM UTC

ushakov wrote: post #203

emgeee wrote: post #196

I was an engineer at Fast for over a year and wanted to clarify a few points-- - engineers did have access to data and could write their own queries to check revenue (but few people did until the article came out). - the strategy leadership decided on was to go after massive enterprise sellers which would, in theory, result in step-change functions in revenue. Many people knew about the low numbers but were willing t…

> The company spent a lot of money on marketing events including sponsorship deals with the Tampa Bay Lightning and the rumored million dollar concert by the Chain Smokers here we go, this is late 90s all over again

You think we get parties with Kid Rock again?

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

#206

Post by tootie » Thu, Apr 07, 2022, 11:38 PM UTC

kevan wrote: post #95

enra wrote: post #80

Earlier quoted context omitted.

> Sounds like the engineers were just entertaining themselves with shiny toys rather than solving the problems they actually had. This is often the problem when hiring too fast. New employees don't have context or direction but generally people try to be productive, so they start inventing work. Management team is new too, and not built up either direct or handle the bandwidth and they also are lacking the direction.…

It's not just limited to startups. When my business unit in Amazon spun up we hired way too fast and ended up having a harder time shipping v1 of the product than if we would've started lean and grown organically. We ended up spending a lot of time on a modularized platform to enable ~5 matrixed feature teams to contribute across iOS and Android apps. Looking back, a small dedicated team for iOS and another team for…

There's always misalignment incentives. If you put a tech manager in charge they're going to look for tech solutions that increase their head count.

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

#207

Post by maybetoofast » Thu, Apr 07, 2022, 11:38 PM UTC

emgeee wrote: post #196

I was an engineer at Fast for over a year and wanted to clarify a few points-- - engineers did have access to data and could write their own queries to check revenue (but few people did until the article came out). - the strategy leadership decided on was to go after massive enterprise sellers which would, in theory, result in step-change functions in revenue. Many people knew about the low numbers but were willing t…

I joined Fast towards the end of last year.

I didn't get as much exposure to the rest of the company as parent comment, but I'll say I saw a weird air of complacency and assumed success.

I first ignored my instincts that something was wrong, but as I saw more of how the company operated, I became convinced that the single largest problem the company had was the culture. On the surface, I agree with the parent comment, things were definitely positive, but rather than toxic, I think it was more of a naive one, like most of these people had never worked at a startup before, and didn't understand that it's always easy to snatch defeat from the jaws of victory, and that if they didn't understand what they were doing and how it affected the company then probably nobody else did either. It felt like everyone was very smart, but somewhat foolish (myself included).

That being said, I enjoyed my time there, and definitely learned a lot, especially organizationally. The people are solid and I think Affirm is going to get a pretty sweet deal.

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

#208

Post by weezin » Thu, Apr 07, 2022, 11:41 PM UTC

jonas21 wrote: post #42

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…

It would not have made a difference. Maybe they'd be losing $9.9M a month instead of $10M a month.

The problem was that the engineers were building a scalable infrastructure rather than a scalable business.

from the article: "The average volume of Fast customers was low because most customers were from small businesses. And yet, every small business needed custom engineering work to be done, making integration slow. Several engineers mentioned how they did not understand how spending lots of engineering effort for each small client resulting in little revenue would result in building a company that could be worth $12B one day."

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

#209

Post by RC_ITR » Thu, Apr 07, 2022, 11:42 PM UTC

ushakov wrote: post #203

emgeee wrote: post #196

I was an engineer at Fast for over a year and wanted to clarify a few points-- - engineers did have access to data and could write their own queries to check revenue (but few people did until the article came out). - the strategy leadership decided on was to go after massive enterprise sellers which would, in theory, result in step-change functions in revenue. Many people knew about the low numbers but were willing t…

> The company spent a lot of money on marketing events including sponsorship deals with the Tampa Bay Lightning and the rumored million dollar concert by the Chain Smokers here we go, this is late 90s all over again

This is such a revealing comment and here's why:

The reason late 90's start-ups invested the way they did is because they had no meaningful way to track the effectiveness of their ads, much less the payback. A Super Bowl ad for Pets.com seems fine if you can (more or less) guess that it adds a bunch of customers.

Since then, start-ups have built a bunch of tools to track customer acquisition costs and paybacks in a pretty sophisticated way, and some of the obviously crazier ads dies (or at least become more one-off).

But now we are in a fintech/crypto era and nobody really knows how to calculate paybacks once again, because the business model is so new vs. a traditional ads or commerce business (will this new crypto.com user do $1k of transaction volume every year for the next ten? sure why not?)

As a result of all this, we see crazy 'spaghetti on the wall' style advertising again, usually focused in the crypto/fintech space (See: this year's Super Bowl). I wonder when the music stops.

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

#210

Post by robot » Thu, Apr 07, 2022, 11:45 PM UTC

The article has good points but misses the actual answer in my view to "what software engineers can learn" or in fact anyone can learn from this.

Don't join a company only because there is more money. If you don't know what one click checkout is or have any intellectual interest in it, but jump on it just because you can make more, you will be disappointed. This works the same way in everything in life.

One must have genuine interest in what they do, before compensation.