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

151–160 of 482 posts

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

#151

Post by whymauri »

encoderer wrote: post #17
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…

Lol. L6. Look no further folks. This guy Dominic was clearly LARPing a startup. Leveling frameworks before traction is a joke to me.

I worked at a company where the founder manufactured an inane 13 level hierarchy (at seed!!!). We had two engineers, all level one, lol.

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

#153

Post by meetups323 »

naiwenwt wrote: post #145
meetups323 wrote: post #78

Earlier quoted context omitted.

May help explain some Meta offers I've seen... 2 years out of college? Sure, come as a Senior! That's not enough? Principal it is!

The problem is sometimes this is done for legitimate reasons and genuinely does lead to stronger outcomes for both employers and employees. It's hard to tell the difference between "stop the bleeding" title/pay inflation and "aggressively competing for talent" inflation.

Differentiator is what other companies will pay. If GAM all offer X, F offers 3X, and GAM refuse to budge on their X... either F knows some deep dark secrets about your capabilities which no one else can appreciate, or they're bleeding talent.

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

#154

Post by bogwog »

tlogan wrote: post #149

I never heard about Fast - till now. So my opinion is that they failed in advertising. Maybe they spent too much on engineering but definitely not enough on advertising.

When I read the title, I thought this article was about Netflix's speed test website fast.com, and thought they were having some catastrophic outage or something.

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

#155

Post by eatonphil »

karmasimida wrote: post #87

> the company only generated $600K in revenue in 2021 Ain't none of the investors catch this ... ? Losing money is one thing, but this seems to me as really low growth right?

Presumably they did catch this because they weren't able to raise a new round.

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

#156

Post by whymauri »

cush wrote: post #118
nly wrote: post #49

Earlier quoted context omitted.

$100M is a lot less money today than it was in 2000 after factoring in inflation and low rates.

But the revenue is also inflated, so it all works out in the wash.

So Pets.com actually drove more revenue than Fast?! Oh my god.

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

#157

Post by altdataseller »

mwcampbell wrote: post #34
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?

Cockroaches just care about survival first and foremost. Unlike unicorns that care about growing huge and taking over the world

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

#158

Post by vimwizard »

mywittyname wrote: post #125
xen0 wrote: post #89

Earlier quoted context omitted.

I wonder, how many engineers had full time jobs just developing and maintaining the various integrations with all their small clients?

I have to imagine they were all stepping on each other and/or reinventing slightly different shaped wheels too. My experience has been that companies who will customize integrations for you have poorly designed products. By that, I mean, when we ask for a feature, and they bring on an engineer who does some requirements gathering then comes back with some invisible solution. That's a major redflag. The success of an…

>My experience has been that companies who will customize integrations for you have poorly designed products. By that, I mean, when we ask for a feature, and they bring on an engineer who does some requirements gathering then comes back with some invisible solution. That's a major redflag.

I'm feeling a bit called out right now (not an owner but that's my experience, too)

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

#159

Post by recuter »

jakey_bakey wrote: post #114
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.…

I find it absolutely crazy that companies do this. My company's strategy is get one extremely solid person across all our verticals (Android / iOS / Backend / Infra) to minimise communication overhead and maximise iteration speed (since we throw out half the code we write anyway). I would be very hard pressed to hire more than 2-3 people in each role even if we were offered 10s of millions.

Headcount perversely increases the valuation sometimes. Hence, big head positions.

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

#160

Post by enra »

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…

Yeah for sure. I think even senior leaders forget the team culture/context piece, and try to scale up too fast because they are used to it in their current orgs or previous companies.

If you have a 500 person org that has operated for years you can probably add 10%-20% new people each year without it breaking too bad. But it can be very hard to build a complete function from 0 to 100 people within a year because there is no infra, culture or understanding how things work. The new people cannot be absorbed/aligned because there is no central gravity so people easily end up pulling different directions and spending their time on internal coordination vs actual useful output.

Post reply on HN