Holy shit. How do you even spend 10M/Month?
What software engineers can learn from the rapid collapse of Fast
51–60 of 482 posts
Re: What software engineers can learn from the rapid collapse of Fast
#52Oof, 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 should be a part of a cockroach team, in my estimation.
Re: What software engineers can learn from the rapid collapse of Fast
#53An important lesson I learned while working for a startup - pay attention to the revenue stream and pay attention to expenses. The two will not stay out of alignment for long. I've talked to start-ups not paying any attention whatsoever to their revenue stream, they seem to think the bonds are the revenue stream. Many of those startups are quickly gone. When looking at a start-up make sure they have a good grasp of their revenue, their expenses, their revenue forecasts, etc. If they start hand-waving or show numbers that are out of whack then you're better off passing on their "opportunity."
Re: What software engineers can learn from the rapid collapse of Fast
#54Wow, 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.
So is 600k
Re: What software engineers can learn from the rapid collapse of Fast
#55Earlier 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.
Even startups benefit from job titles and hierarchy.
Even startup employees benefit from a visible promotion path. Remember, they had hundreds of employees. Not just a couple people in a small office somewhere.
Most likely, the levels corresponded to pay bands and helped determine where people fit into the seniority hierarchy (such as determining who receives sensitive daily information updates)
Re: What software engineers can learn from the rapid collapse of Fast
#56I 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…
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…
At some point managers often fear the "red flag" of "we have a giant team with no work/customers". Hence, they will often push for dubious consulting(ish) work to at least ensure everyone remains busy.
Unfortunately this can lead to the outcome that the company just loses more money.
Re: What software engineers can learn from the rapid collapse of Fast
#57Holy shit. How do you even spend 10M/Month?
It can be done. It's expensive. But it can be done.
Re: What software engineers can learn from the rapid collapse of Fast
#58Earlier 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.
That's what happens when you go on a crazy hiring spree.
Re: What software engineers can learn from the rapid collapse of Fast
#59Incentives matter. Aligning everyone's correctly matters. So much of the story sounded "yeah but you can survive that" right up to the point here:
>>> Sales, however, wanted the opposite: close many deals and hit their targets of signups
If your salespeople are focused on selling to the wrong people nothing matters. You are either Shopify taking years to build or you are a rocket ship taking shortcuts - decide
Re: What software engineers can learn from the rapid collapse of Fast
#60Earlier quoted context omitted.
But working at FAANG is not much fun. I think a mix of both startups and Big Tech leads to a happy life.
What's fun about working at startup that is just cloning a bad old Amazon feature? Besides getting to call yourself a "staff+" on Twitter, I mean.
The meteoric title inflation is definitely interesting. I consistently see people who were Analyst level at Fortune 500s getting up to Director of X in a year or two at startups. Seriously makes me question the quality of people at these places if any random analyst is qualified to be a manager of managers.