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

#421

Post by ben7799 » Fri, Apr 08, 2022, 1:08 PM UTC

cormacrelf wrote: post #373

maybetoofast wrote: post #207

Earlier quoted context omitted.

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…

This whole thing is strange to me. It's targeted at software engineers, and the dominant theme is that you should be wary of toxic positivity and a number of specific indicators that you should be able to see from your desk as an engineer. The discussion in here is also focused on that. But if you are an early employee with equity, you are not just an engineer. You are, figuratively, a shareholder. One of the reasons…

This is an excellent post. I've worked at 4-5 different startups over the past 22 years with a range of exits including shutting down and getting laid off, 3 acquisitions while I was still at the company, and one acquisition after I left but had kept my equity. They all existed on a spectrum between what Fast sounds like and what you're talking about with "extreme" transparency.

You want to be at the company where the CFO gets up at the monthly all hands and goes over the numbers in gory detail and doesn't hold anything back. You do not want to be at the cargo cult company where they get up and cheerlead and never talk about numbers. It took me a shockingly long time to figure this out.

In the end the stock gains have all been in the periods where I didn't work at startups but instead worked at public companies. Go figure.

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

#422

Post by weatherlite » Fri, Apr 08, 2022, 1:15 PM UTC

AtlasBarfed wrote: post #336

kevan wrote: post #95

Earlier quoted context omitted.

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…

If you have a small team, and well hired, then the stack rank grim reaper kills off 20-30% of your labor each year. For your huge hires, 1/3 of the people were hired to be fired in the stack ranking, which of course is a huge morale hit. The ones that aren't setup to fail lose 20-50% of productivity doing machiavellian backstabbing, defensively or offensively, for promotions other culturally ingrained/highly encourag…

Where the hell were you working? This isn't normal for any company.

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

#423

Post by fbanon » Fri, Apr 08, 2022, 1:19 PM UTC

weatherlite wrote: post #422

AtlasBarfed wrote: post #336

Earlier quoted context omitted.

If you have a small team, and well hired, then the stack rank grim reaper kills off 20-30% of your labor each year. For your huge hires, 1/3 of the people were hired to be fired in the stack ranking, which of course is a huge morale hit. The ones that aren't setup to fail lose 20-50% of productivity doing machiavellian backstabbing, defensively or offensively, for promotions other culturally ingrained/highly encourag…

Where the hell were you working? This isn't normal for any company.

They're talking about Amazon.

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

#424

Post by throwawaygal7 » Fri, Apr 08, 2022, 1:25 PM UTC

OK, great discussion in here about hype and toxic positivity.

Does anyone beleive this would have worked if they went with a Leander team and decreased spend? Made a simple MVP and tried to slowly grow?

Just wondering. I feel their idea is pretty mediocre and some very similar solutions already exist. The basic pitch 'one click buying for grandma' is not something I would enable for my parents or my grandmother - they'd just buy too much crap on qvc like sites.

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

#425

Post by ben7799 » Fri, Apr 08, 2022, 1:30 PM UTC

l2silver wrote: post #229

Am I crazy, or is the answer "Nothing"? The product was built, they just couldn't sell it fast enough. Engineering culture had nothing to do with this failure. And if they had landed one of those big clients, they would be kicking ass. You never know how it is going to go. Sometimes you go after the small sales and die. Sometimes you go after the big ones and live.

How big is big? If they landed a "big client" and it was a $5-10M/yr account that doesn't sound like it would have enabled them to survive.

Even if they had landed Amazon that one client would not have paid enough to make this business work when you look at their numbers.

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

#426

Post by BigJono » Fri, Apr 08, 2022, 1:43 PM UTC

brian_cunnie wrote: post #419

belval wrote: post #270

Earlier quoted context omitted.

This echos my experience at a $100M startup that I worked for and that ultimately failed. HR would tell us we were extraordinary, we would have world-class catering for lunch every day, and yet we had no customers, no contracts, and no money except the investors'. It was a sobering realisation on the damage that can happen when you are submerged in toxic positivity. You forget that companies still need to earn actual…

> we would have world-class catering for lunch every day I'd like to point out that this is not the case for every Silicon Valley start-up: the three start-ups I worked at (CollabNet, Aeluros, Ardatech) were incredibly frugal with money (exception: salaries were competitive). At one of the companies, the CEO and I took a trip to Safeway to buy soft drinks for customers. When we got back, I walked around the office te…

That sounds like way too far in the other direction at both places. Stuff like drinks and printers are basically noise compared to engineering payroll when you're paying people $250k a year.

The lesson should be buy whatever the hell people want, just stop buying people until you need them. They're the expensive bit.

3 great devs can do about the same work as like 30 average ones. People massively underestimate communication overhead. As soon as you lose the 'startup feel', you lose the speed, and it's gone for good. The transition is probably inevitable, but there's a threshold of revenue you have to reach before you make it. If you don't reach it, you're cactus.

150 devs and 50 sales people to generate $600k yearly revenue is laughable.

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

#427

Post by nailer » Fri, Apr 08, 2022, 1:50 PM UTC

tomatowurst wrote: post #227

RC_ITR wrote: post #209

Earlier quoted context omitted.

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 p…

Very good point and you are not alone seeing the deja vu Remember beanie babies? We call them NFTs today. Remember HYIP and e-gold? We call them cryptocurrencies now. The point is that crowd behavior, especially markets driven by envy & greed, lead to the same outcome. every. single. time. this is why guys like Warren Buffett and Charlie Munger keep making money.

Beanie babies aren’t scarce and can only be produced by a single company.

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

#428

Post by thegginthesky » Fri, Apr 08, 2022, 2:06 PM UTC

somehnacct3757 wrote: post #236

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…

If you're at a SaaS startup that tries to solve a churn or burn problem by moving upmarket, run. It means your leadership can't think of a way to make the business work other than to get bigger checks from the same size customer base. "If only all our customers could pay us an extra zero!" Moving upmarket doesn't work that way. They are totally different companies with purchase requirements and habits that will gener…

Agreed.

I've been on companies that did the opposite from going small to big. They started big, very big, with Fortune 50 costumers. That meant they hired a small but very specialized sales team with the right connections very early on.

Because the burn rate was very small (due to needing just a few engineers and employees and a small infrastructure) and the sales cycle took months, we could easily develop a strong product with the requested features, and then it turned out when we moved down to medium and small businesses most of the features were already in place all we needed to focus was on scaling the architecture.

Plus, big costumers pay very good and are loyal as long as you don't cause them headaches.

The only downside of this approach is if we hired the wrong sales people, the company would never take off.

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

#429

Post by teaearlgraycold » Fri, Apr 08, 2022, 2:07 PM UTC

Nextgrid wrote: post #388

teaearlgraycold wrote: post #225

Earlier quoted context omitted.

Seeing someone using nothing but tried and true tech to solve new problems is a resume green flag.

Is there a place where such "green flags" would net me money? It seems like as a software engineering employee , the roles that require me to waste time reinventing the wheel and battling self-inflicted complexity pay significantly more than those who require solving actual problems with boring tech.

> Is there a place where such "green flags" would net me money?

Well the best way to reap the benefits of your experience is to run your own company. Not screwing yourself over with BS tech is a competitive market advantage. However you might need to hire people so you can’t pick something too old.

Working for other people it’ll mostly net you less on call headaches.

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

#430

Post by b20000 » Fri, Apr 08, 2022, 2:17 PM UTC

JumpCrisscross wrote: post #392

b20000 wrote: post #312

Earlier quoted context omitted.

this doesn't answer the question at all, it's just a bunch of bullshit words strung together. we never raised any money, and we had more to show than Fast although we were in a completely different industry. this goes to show that all that matters is knowing people, it doesn't actually matter whether you have a real business and have achieved anything at all.

> we never raised any money Who? (Also, given an open market, as was the case when the Amazon patent expired in 2017, the company fundraises to scale will beat its more timid competitor. This is basic strategy.) If you were in a different industry…great execution in the wrong industry is as good as a Ferrari in a swamp. > all that matters is knowing people Sounds like you’ve been through some shit. I’m sorry for that…

you can build a great business in any industry. VCs think this is limited to a handful of industries which they happen to think are hot. because of that thinking many good deals are lost.

maybe Bolt knew a couple of things Fast did not.