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

91–100 of 482 posts

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

#91

Post by Twirrim »

gregdoesit wrote: post #12
PragmaticPulp wrote: post #6

> Tiny daily sales numbers which all employees received was the first such warning sign. Internally, Fast was transparent on sales. Every day, every employee would receive a sales summary email that listed the number of sales completed with Fast checkout, and the total sales amount. > Fast did less than $300K worth of sales and below $6K in revenue on most days from January 2022 to April 2022. There were days with ar…

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…

>L6 and above employees would receive this: staff+ engineers, eng leadership, sales etc.

So all the people that have the authority and capability of saying "woah, woah, woah, we're building something far too complicated" had all the information they needed to prove it, and didn't. That's a fascinating sign of immaturity, and arguably incompetence, at some level in the org. The article points out engineers pushing up about scaling down infrastructure, but it's not clear if that came from the staff+ level or below (or both?), and leadership pushing back, or quite what.

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

#92

Post by deepinsand »

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 believe startups should implement levels once you hire 2 engineers. It's hard to retrofit a system, especially if you're trying to be thoughtful about any pay imbalances.

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

#94

Post by [deleted] »

nly wrote: post #49
photochemsyn wrote: post #44

Wow, these numbers are like those from pets.com: > "During its first fiscal year (February to September 1999) Pets.com earned $619,000 in revenue, and spent $11.8 million on advertising." (Wikipedia) > "The company raised $82.5 million in a February 2000 IPO but filed for bankruptcy nine months later." (Investopedia) Fast rasied $102 million in capital and had $600k in revenue that year... Is Big Finance about to hit…

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

[deleted]

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

#95

Post by kevan »

enra wrote: post #80
lolsoftware wrote: post #33

Earlier quoted context omitted.

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.

> 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 Android probably could've shipped v1 in less than half the time with a lot less tech debt.

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

#98

Post by tschellenbach »

eweise wrote: post #93

I don't understand why $600K in revenue wasn't a giant red flag. Maybe they don't tell the employees the revenue numbers? If so, that is a giant red flag.

I tend to tell potential new hires about our revenue, funding raised, valuation etc. You wonder if there needs to be more education on equity or if these people just went for the high base salary.

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

#99

Post by lmeyerov »

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?

Hard to kill because they're financially independent. We believe enough in the technology we're building (gpu-powered graph ai & visualization) and the missions we're powering (security, fraud, anti-misinfo, healthcare, etc.) that we turned down large initial funding as it would have broken us. So awhile back, being cockroaches meant running as cost-effectively as we could (and still do, in fact, just not as extreme) as we figured it out, and now that things are working, it means prioritizing sustainable growth vs financial games likely to fail.

In contrast, popular models prone to failure and largely fueled by market phenomena like low inflation rates include ad-based social media ("we'll turn on revenue in 5 years, no, really!"), blitzscaling ("we'll eventually figure it out!"), sales-driven growth ("our federal team will make our $ back in 3-5 years, no really!"), acquihires ("with enough AI talent we'll just sell our staff!").

I like venture capital, such as for deep tech and true growth, but the reality is most tech VC funding is more about financial engineering that assumes most of the portfolio fails. They push for commercial scaling too early and wipe out, which is fine for the rich VC who just needs 1-3 bets to win. Fine for them, but sucks for most founders & employees unless they job hop every 2 years. If we take VC $ again, it'd be on our terms and with a clear payback/growth return.

A great way to kill an otherwise great idea & company is putting VC $ in, which puts a company on overdrive and financially implodes before it has a chance to figure things out. They're addicted and likely can't stop relying on VC without layoffs (or less likely, succeeding), at which point many of the A players leave as well and hard to recover. Instead, if a cockroach raises > $2M (so commercialization phase), that should generate enough sales revenue that they can keep organically growing in 18-24mo later even if a follow-on round doesn't happen. You'll hear such cockroach founders saying they don't even touch the money for months. Numbers-wise, most Series A companies fizzle out, which is because of this unicorn-or-bust structure.. and especially whenever the market is not on a bull tear. With a bit more time, they probably could have figured it out... but they blew it.

Some articles: - Paul Graham's article on this: http://www.paulgraham.com/badeconomy.html . - https://medium.com/swlh/how-to-build-a-cockroach-startup-ins... - https://medium.com/the-mission/be-a-cockroach-not-a-unicorn-...

Post reply on HN