I've seen this abused where co-founders were only paid in equity. Instead of being told their percentage ownership, they were shown a similar extremely hypothetical graph. Unfortunately, in reality their equity only was worth ~$600/year (when computed using their percentage ownership and current valuation, which takes into consideration future risk).
What software engineers can learn from the rapid collapse of Fast
221–230 of 482 posts
Re: What software engineers can learn from the rapid collapse of Fast
#222Re: What software engineers can learn from the rapid collapse of Fast
#223Earlier 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.
What could be a legitimate reason for giving silly titles? If it were a startup, it would be a huge red flag for an auditor.
Re: What software engineers can learn from the rapid collapse of Fast
#224I 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…
this sounds like Ridgeline, a startup most have never heard of, founded by the founder of Workday and some of its early employees.
Re: What software engineers can learn from the rapid collapse of Fast
#225Earlier quoted context omitted.
> Sounds like the engineers were just entertaining themselves with shiny toys rather than solving the problems they actually had. Programmers love to add the latest tech to their resume then move on to a new position within ~18 months
That may be specific to early-mid career focus If/when a developer builds deep knowledge of a problem domain, things like framework-of-the-month may become an unwelcome distraction.
Re: What software engineers can learn from the rapid collapse of Fast
#226Re: What software engineers can learn from the rapid collapse of Fast
#227Earlier quoted context omitted.
> 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 p…
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.
Re: What software engineers can learn from the rapid collapse of Fast
#228I 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…
Going after large enterprise sales is a well known trap, and it's just so easy for a startup to spin its wheels for months, and eventually years, and realize that all the efforts got nowhere. The first 1B+ seller is precisely the hardest: Even when you are a relatively well known company, you'll still see reticence in bids if they know you are going to be their biggest costumer by volume. The companies I know that su…
I'm currently at a seed-stage startup with a few Fortune 500 companies as users. We're lucky to have a great sales team that can bring that business in. If we're solving a problem for them, they're willing to use us regardless of our size, though they do care about some small particular issues around size.
Re: What software engineers can learn from the rapid collapse of Fast
#229And 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.
Re: What software engineers can learn from the rapid collapse of Fast
#230Back then, it created a chain reaction. Even relatively established companies like Yahoo turned out to be dependent on startups for much of their revenue. As public companies they had to announce large misses from revenue targets. And that scared investors, which chilled the capital flows to startups, which led to even more startup deaths.
Personally I wouldn't invest in recent software IPOs that sell to startups. Nasty revenue surprises may be on the way.