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 to let the strategy play out for a while. There was a lot of excitement internally around closing the first $1B+ seller
- Internally, the culture was something akin to "toxic positivity" which meant that we weren't willing to discuss failures or misses in a productive way
- 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. People are talking a lot about high engineer salaries but IMO those were far from the biggest problem (possible biased view)
The story is a lot more complicated and nuanced than the headlines you read in publications but I will say that Fast was full of really talented folks who I'd be happy to work with again. For me, a big lesson I took away from this experience is the perils of an overly positive fully remote culture. It's very easy for leadership to hide things from people when information doesn't easily spread across different organizations
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, things were definitely positive, but rather than toxic, I think it was more of a naive one, like most of these people had never worked at a startup before, and didn't understand that it's always easy to snatch defeat from the jaws of victory, and that if they didn't understand what they were doing and how it affected the company then probably nobody else did either. It felt like everyone was very smart, but somewhat foolish (myself included).
That being said, I enjoyed my time there, and definitely learned a lot, especially organizationally. The people are solid and I think Affirm is going to get a pretty sweet deal.
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 they give you stock options as opposed to actual shares is that shareholders have a ton of rights against companies, and can e.g. sue for investor fraud, vote the board out, get quarterly reports with financial & performance statements therein backed by federal law and the threat of investor fraud lawsuits. You, on the other hand, are given the financial exposure to the company's performance without any of the attached rights. And they will happily lie to you in order to keep you happy & get you to project enough positivity to hide flaws & keep outside investment flowing until it all collapses.
So as an employee, you should be trying to claw back some of what being a shareholder would get you, given you are so heavily exposed. I've worked at companies where there is a monthly meeting, nearly everyone present, where the entire company's business position, prospects and challenges are discussed openly. The employees (largely) didn't even have equity. Any cracks (like an imminent complete collapse in the next three days) would show very early on, but there were none, because the employees were empowered to do something about any challenges.
So, yes, there are warning signs, and your response isn't a binary choice between staying and leaving. I would like people to come away with a better model of this than "if they are hiring exclusively from big tech, that's a red flag, get out of there". You can demand more transparency if you know what transparency looks like. If you are content to sit at your desk and happily churn out React components, satisfied with management sending enough emojis at you via slack, then you can't protect yourself at all.
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 money, that it's not a party every day.
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 generate tons of work orthogonal to your core product. Spend a few quarters on compliance accreditations so you can tick boxes, multi-month sales conversations where you aren't even sure if you're just there to pressure the real Belle of their ball, etc.
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.
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 succeeded with that strategy either have great starting relationships with insiders in their first sales, and had contracts signed before committing to a big staff, or got into said companies when they were small: If one of your customers turns into a rocket ship and you are tied to their revenue stream, their growth is your enterprise-sized company.
Enterprise sales might not even be all that profitable when it's all said and done: How many other companies are going to try to bid on their business? With their large size, how good is their leverage to squeeze down the profits of the winning bid.
You might have a relatively unique product, the right connections, and end up being Palantir, but it's a very narrow road with steep cliffs everywhere.
Yeah I’ve worked places where the product was clearly superior to competitors in every possible way, including price, but selling to anyone beyond a small business was still VERY tough for multitude of reasons.
You would have companies where you have existing relationships, they love what you offer, and really want to work with you, but the deal just gets delayed by some other priority or reality of their business.
The solution they already have is good enough (even if it’s barely good enough), and sticking with it is not actively putting them out of business for the time being.
It’s just reality… just like VC investing, selling into 100 small companies and growing along with some of them is waaaaay more likely to pay off than landing one whale
But didn't Bolt succeed (order of magnitudes more revenue) by taking those enterprise customers while Fast was only getting SMBs?
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.
i worked for a startup with a promising product in a lucrative niche but rather than invest in their unique value propositions and use that as a sales ratchet they instead pursued a sales strategy of "outsourced IT" at below cost. engineering time was devoured by integration issues and custom work for customers that were paying far less than the cost of the custom work
I've been in situations somewhat like this before, definitely not as extreme, but the same sort of overall feeling. Everything talked about in Slack/Email is super positive and highlights all the great things customers are saying, but the financial results tell a different story.
It definitely is hard to have conversations about what isn't going well, even though it doesn't have to be negative or gloomy. Often the disconnect in results is chalked up to external factors outside of your control, which is sort of depressing because if that is true then you can't do anything about it.
It's like when someone encounters a bug in the stuff they wrote and look every which way they can to blame it on the library, framework, compiler, etc.. - I'd rather have the bug be in code I wrote because then I can fix it easily. You can show someone simple data that shows a strategy isn't working, and then they'll spend a week torturing the data to come up with a contrived counter-explanation.
Ultimately, it is tough because part of doing a startup is remaining positive even in situations where it isn't warranted and there are times where the strategy may not be working out in the short term but needs more time to play out. Being unwilling to ever even entertain the idea that what you're doing isn't working seems like it might be problematic though.
An overly positive culture is default behavior for most startups. It does appear to be poisonous and there is nothing you can do about it. If you call people out on BS, you are painted as a negative person. Not sure there is a fix.
Makes me think about theranos or wework. Charismatic leaders can get a lot of people/talent following them without necessarily having a solid grasp on all of the complicated aspects of the business they run. Of course you have really great charismatic leaders in startups like Marc Benioff for example who kind of get everything right.
If you rock the boat, you are toxic and not a team player. That’s how it works at most startups. It’s career suicide to say anything else other than what the team wants to hear.
Think this is a particularly American trait - though infecting other parts of the world. Brits, e.g., tend to be more cynical by default, so it’s hard to run a sycophantic culture like that.
> 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
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 pretty sophisticated way, and some of the obviously crazier ads dies (or at least become more one-off).
But now we are in a fintech/crypto era and nobody really knows how to calculate paybacks once again, because the business model is so new vs. a traditional ads or commerce business (will this new crypto.com user do $1k of transaction volume every year for the next ten? sure why not?)
As a result of all this, we see crazy 'spaghetti on the wall' style advertising again, usually focused in the crypto/fintech space (See: this year's Super Bowl). I wonder when the music stops.
What I couldn’t understand was that there were times where something like ApplePay was a clearly superior way to pay. E.g. JavaScript says the user has it configured and able to make payments, so one click payments were actually possible.
At least publicly, Fast never addressed this, and insisted on requiring the user to log into Fast to make a payment even when it was a worse option.
Browsers like Safari are explicitly designed to prevent people from remaining logged into third party sites like Fast. All this was just brushed under the rug and instead it was just a bunch bluster on how Fast was a revolution.
At least Bolt allows payment via ApplePay, and seems more about doing whatever it takes to maximize each seller’s conversion, rather than having an ulterior motive to push its own brand everywhere.
I briefly made an MVP of 'basically Fast', and had to deal with mobile Safari, so I can tell you (hell, I can give you the code if you want it). We had to load our own site in a zero-sized iframe, at a specific endpoint which ran a script that read the cookies and sent them over the Window.postMessage API to the merchant page, where our JS was running and intercepted the cookie contents. But that was an MVP, and I was uncomfortable about the security implications even so - not sure how Fast's engineers hacked it together, if they even did.
The two of us ditched it when we realised how inhospitable the economics were, but even then we knew Fast's shitty play was bound to fail, and I heard the news from my prospective cofounder sending me a text ("we called it!") when it happened...
There is a lot of truth in that. Refusal to acknowledge failures and hard truth, ignoring the elephants in the room, default assuming success, hiding or keeping information secret... That's quite a risky combination.
“I could not be happier or more proud of my teams and what they have accomplished.”
If the company wasn’t successful, then that’s partially on engineering. As employees, we win as a team and lose as a team.
It seems like they were way overbuilt and should have gone much slower from a hiring perspective.
Perhaps these are just words that folks say to put best light on things as they leave, but it strikes me as disingenuous and lacks that ownership mentality that engineering leadership should display.
I 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 spent far more on infrastructure than the scale of the operation would have called for. Engineers sometimes brought up suggestions to scale infra down, and save costs - given there was not much revenue generated.
Sounds like the whole thing could have run on a single cheap VM, perhaps with a second one for redundancy.
I did an interview screen with them at the end of last year for a data engineering position (former coworker was high up on the design side of things and he gave a referral). The first bit of the technical question was just "write a SQL query" and boiled down to doing a group by, count, and limit. The second was something like "what if we needed to return this query from a distributed system without going to the database?" without much context.
As any sane interviewer would do, I asked for context around scale, infrastructure, and what "without going to the database" even meant. The interviewer just reiterated the question. I started talking about different approaches depending on context and all the interviewer did was tell me to program a solution. Turns out all he wanted was a time-windowed hash-map to cache values and the fact that it's a distributed system didn't matter at all.
I think that just about sums up their approach to engineering solutions.
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. Senior leadership and founders are likely busy hiring more folks and potentially trying to sort through the chaos described before.
IMO, pre-product market fit company shouldn't have 500 employees, maybe not even 10. These things don't become easier with more people, usually everything gets harder and slow. You also shouldn't have massive marketing or sales force before you actually have product to sell and have figured out your sales motion.
It seemed that Fast was just trying to shortcut their way to be the next Stripe by hiring people instead of actually working on the fundamentals like the product and business.
I've done startup engineering for a while. I've seen exactly 1 issue that we couldn't solve easily (N+1) or with simply turning our server count up (often way cheaper than putting an engineer to a problem).
Basically, to move development velocity faster we "load everything". Seems like a really bad idea on the surface. In practice, we only ran into an issue with a single customer that was literally 1000x as large as the other customers. It took about two weeks by 1 engineer to rework a select few calls that were egregiously slow and we were back at it.
----
In other words, even with some arguably inefficient technical decisions, I've rarely if ever seen performance issues at early stage startups.
It wasn't "doesn't scale to 10-100X bigger" but "doesn't burn themselves and their teammates out 6mo from now and needlessly risk a stressful & prolonged sev0 when one of the 1-2 people who did weird things gets COVID / goes on a honeymoon / leaves for netflix".
Spending time on needless infra (scale you don't need, AI you don't need, infra you don't need, things could have been postgres as in this case, ...) both prevents building useful stuff ($-generating features/experiences/...) and increases operational cost (maintenance, debugging, ...). Both the lost revenue growth and the increased costs are compounding. Imagine a maniac steadily piling on a bit more technical debt every day and eat a bit more of the seed corn every day instead of growing it.
> Sounds like the engineers were just entertaining themselves with shiny toys rather than solving the problems they actually had.
More like, sounds like management was trying to get as much money as quickly as they could from their VCs before it all imploded. The engineers aren’t at fault that management didn’t have a real product or vision.
Tailscale's "database from 2022" is neither here nor there. What you should do in this situation is use the most boring tech, such as PostgreSQL with a simple HA setup. Thus avoiding the "play with nifty toys" trap and maximizing the chance of making appropriate choices.
Staying employed for another few decades without losing seniority in an industry that expects you to stay current on all of the latest hottest fads is a problem the engineers actually had.
I've seen a few startups that seemed to overengineer things (or build custom solutions rather than use something off the shelf) in expectation of massive growth.
I also thought it might have been due to resume driven development and the need to keep engineers engaged so they didn't leave.
I've also seen successful startups with a monolithic rails or PHP application that ran on heroku with next to zero custom architecture components.
Pretty sure the reason they caught that flak is because they chose to reinvent the wheel instead of do a normal thing that would work until later - they're on their what - third rewrite of that now?
I would hope this problem doesn't exist at startups but I've seen it at entrenched institutions any number of time:
If your boss's boss or peers signed a contract for $1m a year from Oracle, you're going to use Oracle even if Postgres is a better product. And the only way to use Postgres in this situation is if they don't know you're running it. Which puts you in the uncomfortable situation of wanting to say, "But Oracle sucks, look how successful we've been at using Postgres?".
Basically if you don't already know that someone higher up the food chain is comfortable with saying, "I've made a huge mistake", you aren't going to 'help' them learn to do it by pointing out they fucked up. What they're going to hear is that you're asking them to say, "I just wasted a million dollars of company money on something everybody hates," which not only are they not going to do, but they're going to start thinking about how to shoot the messenger.
As many conversations go in a couple of my hobbies and talking to friends and acquaintances about health concerns, the answer often starts with, "first, get a time machine" and ends with, "or learn to live with it," often with some useful compromises in between.
One of the important things to do early in your tenure at a place is to bid various people in the management chain and those who seem to be on a management track to see how open they are to having their minds changed. Because you want to know this when the stakes are low (also the blowback on low stakes things seems to be less problematic). Then you know if or when a boondoggle is in the making whether you can stop it before it starts, or amplify all of the problems and kill it along the way, or whether you should keep your head down and conspire to keep the 'doggle at arm's length with those who agree with you.
> If your boss's boss or peers signed a contract for $1m a year from Oracle, you're going to use Oracle even if Postgres is a better product.
What you'd do in that situation is make the best of that $1M contract you're stuck with anyway, while being flexible enough to migrate away from that solution when it actually makes sense to do so. Just because you've made a huge mistake doesn't mean that making a different choice after-the-fact is more sensible. Hindsight is always 20/20.
It's always funny to read about crazy overspending on infrastructure and I have a few funny stories myself, but this was far from their biggest problem. For one, we don't know how big those costs were or how much time it would take to wind some of it down.
I absolutely hate waste and was always proud of myself when I found ways to shave a thousand here and there off our AWS bill, but it was a bit depressing when I went through the thought exercise of "What would it be like for the company if I managed to get everything onto the AWS free tier?" And then compared that to what it would be like for the company if we found a way to make 1 or 2% more in revenue.
Early on, the math heavily favors worrying less about infra spend and more about product enhancements that can build revenue.
(Although often reducing the size of your infra for other reasons - usually around complexity for ops or ease of development can also have the side benefit of reducing cost and it seems worthwhile in those cases.)
And if you think this is undersized for comedic effect I did ops for a company that went from <1mil to 15mil revenue (with the same sales strategy of targeting lots of small clients) on 4 1u white label supermicros. Two app servers and two MySQL dbs. Never in my life had such reliable infrastructure.
Early in my career when in a discussion with my manager at the time, he threw out the "planes with two engines have twice as many failures as single engine planes" line.
So in my now close to 30 years of experience later, working on systems expected to run 24/7/365, I can't tell you what percentage of failures and outages were caused by the redundancy/fail-over/etc software and hardware layered into a system, but its definitely a very significant part of the problem. Frequently because its just that a "layer" someone bolted on, even if that layer was some software engineer designing for "web scale". All the edge cases are frequently not completely thought out, and when you hit one its a lot harder to recover, than simply restarting a single service running on a single server.
This is a big lesson to heed. Sure, sometimes a startup really needs extravagantly scalable infrastructure. For the 99.9% of startup, no, you don't.
So the odds are you don't. Keep it very simple, very small. I can't highlight this enough. A few boxes will get you very far. If you ever actually hit the limits, throw a big party to celebrate success and only then start to think about making your infrastructure a bit (just a bit) more complex.
We have 10 petabytes of storage and a ~terabyte scale Postgres instance. It runs on a few racks and we get a respectable amount of traffic. It’s not “WeBScALe” but it’s not peanuts. Better uptime than AWS and our operational expenses are negligible. People forget how insanely powerful and cheap hardware is nowadays. Now, you can buy a 64 core chip for $7k. That alone could handle some serious traffic.
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 maintenance) was probably at least an amber flag somewhere for those who had visibility of it.
But maybe there was on-going hope that they would be able to sign up a big customer and integrate them before they ran out of money?
> The ratio of revenue per each small customer vs the total cost of integration (and very likely on-going maintenance) was probably at least an amber flag somewhere for those who had visibility of it.
At the last company I worked at (won't call them a startup, just a 10-year old small business that somehow kept raising funding but has never made a profit) I was astonished to learn from a new CPO that in our tenth year we didn't know if we were making money from a customer.
We had no idea how individual customers used the application, which was very data intensive, or what that was costing us. The information was there, but no-one ever looked. Every sale was considered a success, even if it turned out to cost us 3x in data costs and customer support. Often customer support alone would make a sale into a loss.
We spent a relatively large portion of our revenue running very expensive servers to respond instantly to searches that no-one ever performed. I created detailed monitoring to show this. I talked about them to everyone, including Product and the CEO. No-one disputed those facts. But instead we had several people essentially dedicated to downsizing application servers and deleting unused S3 buckets, trimming three zeros a month when we could have trimmed five.
I have learned not to assume that warnings are visible, that people pay attention to them if they are visible, or that anyone cares.
They're still circling the drain, still raising money (somehow!) and I doubt anything's changed.
Management probably really screwed this up if they were really only making $600k/yr.
Places I've worked yearly contracts for B2B have been in the $100k-$5M/yr range.
The customers paying $100k/yr barely get any integrations and feature changes... they go for the ride. The customers paying $1M+/yr get features on the double.
If Fast was doing integrations and customization for customers that were paying $1000 or less a year something was very very wrong.
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.
The problem was that the engineers were building a scalable infrastructure rather than a scalable business.
from the article: "The average volume of Fast customers was low because most customers were from small businesses. And yet, every small business needed custom engineering work to be done, making integration slow. Several engineers mentioned how they did not understand how spending lots of engineering effort for each small client resulting in little revenue would result in building a company that could be worth $12B one day."
Sure, their primary problem was extravagant hiring, but I think this is still an important warning for developers working in fledgling companies that are appropriately cautious on the hiring side.
I have actually heard of this startup amazingly, as well as the founder, but I wasn't aware it was/is? as much of a s.show that the article portrays at Fast. Do you have any context you might be willing to share, I am genuinely curious.
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. Valuation multiples in 50-100X range are super common (and even wackier numbers in seed/a). Think make believe stories like "well with another 12-18mo of growth this really just a bit over a 30X on some future forward revenue multiple...". The cash almost always leads to overspending, and it's highly unlikely the next 2-3 raises won't blow up and everyone goes home. I'm actually super impressed by the Docker team because they've been one of those rare cases of crawling out of that trap, even if with a lot less of the team.
We get job candidates with high competing offers for companies I know to be rotten inside, yet there's only so much I can say. "Our new hires are getting paid from customer revenue and with equity that doesn't have $50M-$500M of investor thumbs on the scales already cutting you out in 95% of the likely scenarios" generally doesn't punch through the kool aid.
> We get job candidates with high competing offers for companies I know to be rotten inside,
I fell for this trick once when I was younger, but never again.
As it turns out, when companies are bleeding talent and struggling to hire they suddenly find ways to pay well above market rate. You can have a fancy title, too!
We had a competitor do something similar at a prior company. I would tell candidates that we can't match their compensation numbers but to come back if things don't work out at the other company. I'd often get a message about 3-4 months later asking if the job was still available
I'm not the op and this is the first time I've seen someone else use the term, but I've used it too. Aspirationally - small and impossible to kill. While a unicorn's goal might be growth at all costs (with associated high chance of failure), our goal is to survive anything that might get thrown our way.
Look into the early history of Airbnb. They did anything to survive - even selling politician-themed breakfast cereal. Yes. pg exclaimed, you guys are like cockroaches, you just won't die.
Don't know if that's the origin, but hey it could be. Without the story, calling someone "cockroach" has unclear sentiments.
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.
> 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 around $2,000 in revenue for Fast.
I'm actually surprised that everyone was receiving daily updates of company revenue.
If you're surrounded by 100s of people at a company known to give high base pay but you're seeing daily revenue numbers in the range of $1K to $6K (they had $600K total revenue in 2021, supposedly) then you have to know that your time is very limited.
I assume they were led to believe that more investment money was just around the corner to keep the business going? With a $10 million monthly burn rate they would have needed a staggering amount of capital to just continue to exist, let alone execute any plans to turn the ship around.
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 monitors across the company.
>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.
Amongst a sea of negatives, that they continued to share these numbers with employees is a positive mark for the culture at Fast. Sure, it's easy to say with hindsight that Fast employees should have seen the demise coming. On the other hand, they also watched one of the founders raise $100M+ from Stripe. Perhaps they thought the burn could continue and eventually the product would reach traction.
The entire culture of b2b startups IME is "yes we're burning money now, but just you wait till Moby Dick comes along... just implement XYZ features marketing/sales says are important and we'll have him in no time!"
Of course, this is somewhat tautological: if they weren't burning money, they'd just be a company. Startup phase complete.
> Fast offered $200-240K/year in base salaries with full remote work
> Sign-on bonuses were common and large. Those who asked for almost always received sign-on bonuses of $20-50K as a one-off payment
> Equity issued was lavish and presented as potentially life-changing
> A good part of people are echoing how working at Fast was an amazing experience. People liked the culture, and how employee happiness was a priority.
What's not to like here ? Working for huge amount of money, in a company whose culture puts employees happiness first, and provides an amazing working experience.
Management did "all the right things" : remote ? check ! competitive salaries ? check ! amazing experience working there ? check ! employees-first culture ? check !. Why would you even need to look elsewhere.
And when it all crashed and burned, the feeling is :
> There are people who are frustrated and disappointed with company leadership, and how the bust came out of nowhere.
Trick is that it did not come out of nowhere, people just chose to look away. It's easier to blame management (which is definitely at fault as well !) than to say "I was paid way too much compared to the actual value I was providing". When you are paid $200k / year, you should easily be able to justify that your work generates more than several thousands of USD alone, if you are unable to do that, you need to have a conversation with your mirror as well - or just accept the fact that you are benefitting from a system, which may crash and burn if too many people are in this situation, or keep on living if you are an exception.
I think as a serious counter to that, look at the offers that a FAANG will give you - similar base salary, similar sign-on bonuses. Generally WLB is fine.
The real differentiator - they're offering you equity which is liquid right now.
If one is risk averse, one wouldn't touch Fast with a ten foot pole.
I'm just barely young enough to have missed it. Friends who quit school early were in on it.
I don't know if this was the case at Fast but in a lot of cases back in the 1990s a lot of the engineers knew everything was screwed up.. and they just didn't care, the money was good while it lasted.
The experience almost always helped people get ahead, no one ever gets punished for doing good work at a company that fails due to bad management and investor decisions.
One key difference is pets.com is public and got money from common people.
Fast got money from highly sophisticated VCs. They all made calculated bet.
No VCs would tell you their deals have 100% success.
Employees that join are highly educated. They also know that it is a startup with high failure chance. Much higher than FAANG. Every educated person knows this.
And it is normal to be disappointed when a bet doesn't work out.
I wonder just how much difference it makes that all this wacky startup action is private equity (writ large) rather than the public markets. Seems like... maybe a lot?
https://www.siliconvict.com
These days I just tinker with projects which are listed in that site. Taking a couple years off while I look for the next big thing.
Readit News
The story is a lot more complicated and nuanced than the headlines you read in publications but I will say that Fast was full of really talented folks who I'd be happy to work with again. For me, a big lesson I took away from this experience is the perils of an overly positive fully remote culture. It's very easy for leadership to hide things from people when information doesn't easily spread across different organizations
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, things were definitely positive, but rather than toxic, I think it was more of a naive one, like most of these people had never worked at a startup before, and didn't understand that it's always easy to snatch defeat from the jaws of victory, and that if they didn't understand what they were doing and how it affected the company then probably nobody else did either. It felt like everyone was very smart, but somewhat foolish (myself included).
That being said, I enjoyed my time there, and definitely learned a lot, especially organizationally. The people are solid and I think Affirm is going to get a pretty sweet deal.
But if you are an early employee with equity, you are not just an engineer. You are, figuratively, a shareholder. One of the reasons they give you stock options as opposed to actual shares is that shareholders have a ton of rights against companies, and can e.g. sue for investor fraud, vote the board out, get quarterly reports with financial & performance statements therein backed by federal law and the threat of investor fraud lawsuits. You, on the other hand, are given the financial exposure to the company's performance without any of the attached rights. And they will happily lie to you in order to keep you happy & get you to project enough positivity to hide flaws & keep outside investment flowing until it all collapses.
So as an employee, you should be trying to claw back some of what being a shareholder would get you, given you are so heavily exposed. I've worked at companies where there is a monthly meeting, nearly everyone present, where the entire company's business position, prospects and challenges are discussed openly. The employees (largely) didn't even have equity. Any cracks (like an imminent complete collapse in the next three days) would show very early on, but there were none, because the employees were empowered to do something about any challenges.
So, yes, there are warning signs, and your response isn't a binary choice between staying and leaving. I would like people to come away with a better model of this than "if they are hiring exclusively from big tech, that's a red flag, get out of there". You can demand more transparency if you know what transparency looks like. If you are content to sit at your desk and happily churn out React components, satisfied with management sending enough emojis at you via slack, then you can't protect yourself at all.
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 money, that it's not a party every day.
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 generate tons of work orthogonal to your core product. Spend a few quarters on compliance accreditations so you can tick boxes, multi-month sales conversations where you aren't even sure if you're just there to pressure the real Belle of their ball, etc.
If you can't do it small, you can't do it.
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.
The companies I know that succeeded with that strategy either have great starting relationships with insiders in their first sales, and had contracts signed before committing to a big staff, or got into said companies when they were small: If one of your customers turns into a rocket ship and you are tied to their revenue stream, their growth is your enterprise-sized company.
Enterprise sales might not even be all that profitable when it's all said and done: How many other companies are going to try to bid on their business? With their large size, how good is their leverage to squeeze down the profits of the winning bid.
You might have a relatively unique product, the right connections, and end up being Palantir, but it's a very narrow road with steep cliffs everywhere.
You would have companies where you have existing relationships, they love what you offer, and really want to work with you, but the deal just gets delayed by some other priority or reality of their business. The solution they already have is good enough (even if it’s barely good enough), and sticking with it is not actively putting them out of business for the time being.
It’s just reality… just like VC investing, selling into 100 small companies and growing along with some of them is waaaaay more likely to pay off than landing one whale
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.
It definitely is hard to have conversations about what isn't going well, even though it doesn't have to be negative or gloomy. Often the disconnect in results is chalked up to external factors outside of your control, which is sort of depressing because if that is true then you can't do anything about it.
It's like when someone encounters a bug in the stuff they wrote and look every which way they can to blame it on the library, framework, compiler, etc.. - I'd rather have the bug be in code I wrote because then I can fix it easily. You can show someone simple data that shows a strategy isn't working, and then they'll spend a week torturing the data to come up with a contrived counter-explanation.
Ultimately, it is tough because part of doing a startup is remaining positive even in situations where it isn't warranted and there are times where the strategy may not be working out in the short term but needs more time to play out. Being unwilling to ever even entertain the idea that what you're doing isn't working seems like it might be problematic though.
here we go, this is late 90s all over again
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 pretty sophisticated way, and some of the obviously crazier ads dies (or at least become more one-off).
But now we are in a fintech/crypto era and nobody really knows how to calculate paybacks once again, because the business model is so new vs. a traditional ads or commerce business (will this new crypto.com user do $1k of transaction volume every year for the next ten? sure why not?)
As a result of all this, we see crazy 'spaghetti on the wall' style advertising again, usually focused in the crypto/fintech space (See: this year's Super Bowl). I wonder when the music stops.
At least publicly, Fast never addressed this, and insisted on requiring the user to log into Fast to make a payment even when it was a worse option.
Browsers like Safari are explicitly designed to prevent people from remaining logged into third party sites like Fast. All this was just brushed under the rug and instead it was just a bunch bluster on how Fast was a revolution.
At least Bolt allows payment via ApplePay, and seems more about doing whatever it takes to maximize each seller’s conversion, rather than having an ulterior motive to push its own brand everywhere.
The two of us ditched it when we realised how inhospitable the economics were, but even then we knew Fast's shitty play was bound to fail, and I heard the news from my prospective cofounder sending me a text ("we called it!") when it happened...
“I could not be happier or more proud of my teams and what they have accomplished.”
If the company wasn’t successful, then that’s partially on engineering. As employees, we win as a team and lose as a team.
It seems like they were way overbuilt and should have gone much slower from a hiring perspective.
Perhaps these are just words that folks say to put best light on things as they leave, but it strikes me as disingenuous and lacks that ownership mentality that engineering leadership should display.
You could put that as subtext for pretty much every story you read. ;-)
> 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 spent far more on infrastructure than the scale of the operation would have called for. Engineers sometimes brought up suggestions to scale infra down, and save costs - given there was not much revenue generated.
Sounds like the whole thing could have run on a single cheap VM, perhaps with a second one for redundancy.
I did an interview screen with them at the end of last year for a data engineering position (former coworker was high up on the design side of things and he gave a referral). The first bit of the technical question was just "write a SQL query" and boiled down to doing a group by, count, and limit. The second was something like "what if we needed to return this query from a distributed system without going to the database?" without much context.
As any sane interviewer would do, I asked for context around scale, infrastructure, and what "without going to the database" even meant. The interviewer just reiterated the question. I started talking about different approaches depending on context and all the interviewer did was tell me to program a solution. Turns out all he wanted was a time-windowed hash-map to cache values and the fact that it's a distributed system didn't matter at all.
I think that just about sums up their approach to engineering solutions.
Deleted Comment
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. Senior leadership and founders are likely busy hiring more folks and potentially trying to sort through the chaos described before.
IMO, pre-product market fit company shouldn't have 500 employees, maybe not even 10. These things don't become easier with more people, usually everything gets harder and slow. You also shouldn't have massive marketing or sales force before you actually have product to sell and have figured out your sales motion.
It seemed that Fast was just trying to shortcut their way to be the next Stripe by hiring people instead of actually working on the fundamentals like the product and business.
Basically, to move development velocity faster we "load everything". Seems like a really bad idea on the surface. In practice, we only ran into an issue with a single customer that was literally 1000x as large as the other customers. It took about two weeks by 1 engineer to rework a select few calls that were egregiously slow and we were back at it.
----
In other words, even with some arguably inefficient technical decisions, I've rarely if ever seen performance issues at early stage startups.
Spending time on needless infra (scale you don't need, AI you don't need, infra you don't need, things could have been postgres as in this case, ...) both prevents building useful stuff ($-generating features/experiences/...) and increases operational cost (maintenance, debugging, ...). Both the lost revenue growth and the increased costs are compounding. Imagine a maniac steadily piling on a bit more technical debt every day and eat a bit more of the seed corn every day instead of growing it.
A good phrase for this is "playing house": http://www.paulgraham.com/before.html
More like, sounds like management was trying to get as much money as quickly as they could from their VCs before it all imploded. The engineers aren’t at fault that management didn’t have a real product or vision.
Programmers love to add the latest tech to their resume then move on to a new position within ~18 months
Deleted Comment
I've seen a few startups that seemed to overengineer things (or build custom solutions rather than use something off the shelf) in expectation of massive growth.
I also thought it might have been due to resume driven development and the need to keep engineers engaged so they didn't leave.
I've also seen successful startups with a monolithic rails or PHP application that ran on heroku with next to zero custom architecture components.
Deleted Comment
I've seen this repeated on HN, but never saw the alleged flak.
Tootally worth the time /s
If your boss's boss or peers signed a contract for $1m a year from Oracle, you're going to use Oracle even if Postgres is a better product. And the only way to use Postgres in this situation is if they don't know you're running it. Which puts you in the uncomfortable situation of wanting to say, "But Oracle sucks, look how successful we've been at using Postgres?".
Basically if you don't already know that someone higher up the food chain is comfortable with saying, "I've made a huge mistake", you aren't going to 'help' them learn to do it by pointing out they fucked up. What they're going to hear is that you're asking them to say, "I just wasted a million dollars of company money on something everybody hates," which not only are they not going to do, but they're going to start thinking about how to shoot the messenger.
As many conversations go in a couple of my hobbies and talking to friends and acquaintances about health concerns, the answer often starts with, "first, get a time machine" and ends with, "or learn to live with it," often with some useful compromises in between.
One of the important things to do early in your tenure at a place is to bid various people in the management chain and those who seem to be on a management track to see how open they are to having their minds changed. Because you want to know this when the stakes are low (also the blowback on low stakes things seems to be less problematic). Then you know if or when a boondoggle is in the making whether you can stop it before it starts, or amplify all of the problems and kill it along the way, or whether you should keep your head down and conspire to keep the 'doggle at arm's length with those who agree with you.
What you'd do in that situation is make the best of that $1M contract you're stuck with anyway, while being flexible enough to migrate away from that solution when it actually makes sense to do so. Just because you've made a huge mistake doesn't mean that making a different choice after-the-fact is more sensible. Hindsight is always 20/20.
I absolutely hate waste and was always proud of myself when I found ways to shave a thousand here and there off our AWS bill, but it was a bit depressing when I went through the thought exercise of "What would it be like for the company if I managed to get everything onto the AWS free tier?" And then compared that to what it would be like for the company if we found a way to make 1 or 2% more in revenue.
Early on, the math heavily favors worrying less about infra spend and more about product enhancements that can build revenue.
(Although often reducing the size of your infra for other reasons - usually around complexity for ops or ease of development can also have the side benefit of reducing cost and it seems worthwhile in those cases.)
YES! This is VERY true
So in my now close to 30 years of experience later, working on systems expected to run 24/7/365, I can't tell you what percentage of failures and outages were caused by the redundancy/fail-over/etc software and hardware layered into a system, but its definitely a very significant part of the problem. Frequently because its just that a "layer" someone bolted on, even if that layer was some software engineer designing for "web scale". All the edge cases are frequently not completely thought out, and when you hit one its a lot harder to recover, than simply restarting a single service running on a single server.
So the odds are you don't. Keep it very simple, very small. I can't highlight this enough. A few boxes will get you very far. If you ever actually hit the limits, throw a big party to celebrate success and only then start to think about making your infrastructure a bit (just a bit) more complex.
> [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 maintenance) was probably at least an amber flag somewhere for those who had visibility of it.
But maybe there was on-going hope that they would be able to sign up a big customer and integrate them before they ran out of money?
At the last company I worked at (won't call them a startup, just a 10-year old small business that somehow kept raising funding but has never made a profit) I was astonished to learn from a new CPO that in our tenth year we didn't know if we were making money from a customer.
We had no idea how individual customers used the application, which was very data intensive, or what that was costing us. The information was there, but no-one ever looked. Every sale was considered a success, even if it turned out to cost us 3x in data costs and customer support. Often customer support alone would make a sale into a loss.
We spent a relatively large portion of our revenue running very expensive servers to respond instantly to searches that no-one ever performed. I created detailed monitoring to show this. I talked about them to everyone, including Product and the CEO. No-one disputed those facts. But instead we had several people essentially dedicated to downsizing application servers and deleting unused S3 buckets, trimming three zeros a month when we could have trimmed five.
I have learned not to assume that warnings are visible, that people pay attention to them if they are visible, or that anyone cares.
They're still circling the drain, still raising money (somehow!) and I doubt anything's changed.
Places I've worked yearly contracts for B2B have been in the $100k-$5M/yr range.
The customers paying $100k/yr barely get any integrations and feature changes... they go for the ride. The customers paying $1M+/yr get features on the double.
If Fast was doing integrations and customization for customers that were paying $1000 or less a year something was very very wrong.
Unfortunately this can lead to the outcome that the company just loses more money.
from the article: "The average volume of Fast customers was low because most customers were from small businesses. And yet, every small business needed custom engineering work to be done, making integration slow. Several engineers mentioned how they did not understand how spending lots of engineering effort for each small client resulting in little revenue would result in building a company that could be worth $12B one day."
You're describing most startups here.
Deleted Comment
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. Valuation multiples in 50-100X range are super common (and even wackier numbers in seed/a). Think make believe stories like "well with another 12-18mo of growth this really just a bit over a 30X on some future forward revenue multiple...". The cash almost always leads to overspending, and it's highly unlikely the next 2-3 raises won't blow up and everyone goes home. I'm actually super impressed by the Docker team because they've been one of those rare cases of crawling out of that trap, even if with a lot less of the team.
We get job candidates with high competing offers for companies I know to be rotten inside, yet there's only so much I can say. "Our new hires are getting paid from customer revenue and with equity that doesn't have $50M-$500M of investor thumbs on the scales already cutting you out in 95% of the likely scenarios" generally doesn't punch through the kool aid.
I fell for this trick once when I was younger, but never again.
As it turns out, when companies are bleeding talent and struggling to hire they suddenly find ways to pay well above market rate. You can have a fancy title, too!
We had a competitor do something similar at a prior company. I would tell candidates that we can't match their compensation numbers but to come back if things don't work out at the other company. I'd often get a message about 3-4 months later asking if the job was still available
On my way out of the first startup I worked for, there was an offer to double my pay! Nope!
Don't know if that's the origin, but hey it could be. Without the story, calling someone "cockroach" has unclear sentiments.
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-...
is this a reference to http://paulgraham.com/guidetoinvestors.html#:~:text=nuclear%...
I think I know what you mean by this, but I'm not sure. Could you elaborate on what this means? Thanks in advance. :)
Money is fungible
> 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 around $2,000 in revenue for Fast.
I'm actually surprised that everyone was receiving daily updates of company revenue.
If you're surrounded by 100s of people at a company known to give high base pay but you're seeing daily revenue numbers in the range of $1K to $6K (they had $600K total revenue in 2021, supposedly) then you have to know that your time is very limited.
I assume they were led to believe that more investment money was just around the corner to keep the business going? With a $10 million monthly burn rate they would have needed a staggering amount of capital to just continue to exist, let alone execute any plans to turn the ship around.
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 monitors across the company.
Look no further folks. This guy Dominic was clearly LARPing a startup.
Leveling frameworks before traction is a joke to me.
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.
How does this even exist at a company with essentially no revenue? This should be at most 1 person in "staff+ engineers, eng leadership"
Dashboards are all the rage as a way to get teams aligned around "critical numbers" (the metrics that matter).
But, if your dashboards start telling a story of impossibility, your best people are going to leave earlier rather than hang on.
A definite downside to the dashboard cult.
Of course, this is somewhat tautological: if they weren't burning money, they'd just be a company. Startup phase complete.
My company posts daily new user signups in #general on Slack. That's not quite revenue, but you could almost extrapolate
> Fast offered $200-240K/year in base salaries with full remote work
> Sign-on bonuses were common and large. Those who asked for almost always received sign-on bonuses of $20-50K as a one-off payment
> Equity issued was lavish and presented as potentially life-changing
> A good part of people are echoing how working at Fast was an amazing experience. People liked the culture, and how employee happiness was a priority.
What's not to like here ? Working for huge amount of money, in a company whose culture puts employees happiness first, and provides an amazing working experience.
Management did "all the right things" : remote ? check ! competitive salaries ? check ! amazing experience working there ? check ! employees-first culture ? check !. Why would you even need to look elsewhere.
And when it all crashed and burned, the feeling is :
> There are people who are frustrated and disappointed with company leadership, and how the bust came out of nowhere.
Trick is that it did not come out of nowhere, people just chose to look away. It's easier to blame management (which is definitely at fault as well !) than to say "I was paid way too much compared to the actual value I was providing". When you are paid $200k / year, you should easily be able to justify that your work generates more than several thousands of USD alone, if you are unable to do that, you need to have a conversation with your mirror as well - or just accept the fact that you are benefitting from a system, which may crash and burn if too many people are in this situation, or keep on living if you are an exception.
Revenue per Employee used to be a real metric that people used. Of course, P/E ratios used to be sane as well.
I think as a serious counter to that, look at the offers that a FAANG will give you - similar base salary, similar sign-on bonuses. Generally WLB is fine.
The real differentiator - they're offering you equity which is liquid right now.
If one is risk averse, one wouldn't touch Fast with a ten foot pole.
- FAANG aren't/weren't remote
- The appeal for working at a startup vs an established company, and the sense of freedom associated with that
- Some guys that would love the idea behind FAANS...but would not like the management/process in place there (OKR, reviews, career ladder)
- Some guys that would love to work for FAANG... but didn't pass the interview (either failed or didn't try)
> "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 the panic button again?
I'm just barely young enough to have missed it. Friends who quit school early were in on it.
I don't know if this was the case at Fast but in a lot of cases back in the 1990s a lot of the engineers knew everything was screwed up.. and they just didn't care, the money was good while it lasted.
The experience almost always helped people get ahead, no one ever gets punished for doing good work at a company that fails due to bad management and investor decisions.
One key difference is pets.com is public and got money from common people.
Fast got money from highly sophisticated VCs. They all made calculated bet.
No VCs would tell you their deals have 100% success.
Employees that join are highly educated. They also know that it is a startup with high failure chance. Much higher than FAANG. Every educated person knows this.
And it is normal to be disappointed when a bet doesn't work out.
Per the CPI, for every $1 in 2000, you need $1.68 today. 1.68^1/22 - 1 is about 2.39%/year inflation.
https://data.bls.gov/cgi-bin/cpicalc.pl?cost1=1&year1=200001...
Deleted Comment
This thread [1] touches on what some of that stuff probably was. Sounds like the CEO was a charismatic scammer.
[1]: https://nitter.net/jack_raines/status/1511737489190494208
(Just kidding).
It really amazes me sometimes the strategies of these heavily funded companies. Why pile on so much burn so quickly?