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

261–270 of 482 posts

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

#261

Post by danielmarkbruce »

lowkey_ wrote: post #228
hibikir wrote: post #215

Earlier quoted context omitted.

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…

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

If you can get them, that's awesome. Which company?

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

#262

Post by digianarchist »

l2silver wrote: post #229

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

>And if they had landed one of those big clients, they would be kicking ass.

I think there lies the problem. You need to work up to acquiring those customers.

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

#263

Post by danielmarkbruce »

throwthere wrote: post #259
danielmarkbruce wrote: post #255

Earlier quoted context omitted.

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.

I don't work at salesforce, but I can almost guarantee people who work there will tell you they are miles from getting everything right. Every company is pretty messy internally.

As for theranos and wework - i don't mean those kinds of things. I mean standard non-fraud startups. The always positive culture is there, and at least for folks who take some pride in being rational, it is quite demoralizing.

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

#264

Post by tehlike »

yen223 wrote: post #253
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.

How many engineers reading this comment know (or even care) how much revenue their company is making?

Good engineers look into the core metrics that matter to their company.

I am in ads. I know quite a lot about the revenue, split, seasonality, etc. It's something i optimize, so it's something i must know.

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

#265

Post by frankchn »

meetups323 wrote: post #153
naiwenwt wrote: post #145

Earlier quoted context omitted.

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.

Differentiator is what other companies will pay. If GAM all offer X, F offers 3X, and GAM refuse to budge on their X... either F knows some deep dark secrets about your capabilities which no one else can appreciate, or they're bleeding talent.

It is usually not quite that drastic. More often it is like GAM offer X, F offers 1.2X.

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

#266

Post by throwawaythekey »

pyb wrote: post #218
maybetoofast wrote: post #207

Earlier quoted context omitted.

I joined Fast towards the end of last year. I didn't get as much exposure to the rest of the company as parent comment, but I'll say I saw a weird air of complacency and assumed success. I first ignored my instincts that something was wrong, but as I saw more of how the company operated, I became convinced that the single largest problem the company had was the culture. On the surface, I agree with the parent comment…

Good point, I am always surprise when well funded startups hire former big-tech engineers, rather than experienced startup engineers.

I interviewed at Fast last year as an experienced startup engineer. I was given the "describe a production incident you were involved in" question.

I detailed a case where a recent deploy I had done had resulted in elevated error rates for some of our clients and how I had solved it with a quick follow up push to prod. The interviewer asked why it wasn't caught in staging and I mentioned that it could have been but as a small company we have to make velocity vs bug tradeoffs and in general it feels like we are currently at a sweet spot. The interviewer was unwilling to explore that space at all, or the concept that different companies might want to land in different places.

Later I was given feedback that I did exceptionally well in the technical interviews but the company didn't want any cowboys on their team. All of that is probably just a long way of confirming the other anecdotes in this thread that from the outside fast seemed somewhere between delivery hostile and overly cautious.

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

#267

Post by rongenre »

recuter wrote: post #159
jakey_bakey wrote: post #114

Earlier quoted context omitted.

I find it absolutely crazy that companies do this. My company's strategy is get one extremely solid person across all our verticals (Android / iOS / Backend / Infra) to minimise communication overhead and maximise iteration speed (since we throw out half the code we write anyway). I would be very hard pressed to hire more than 2-3 people in each role even if we were offered 10s of millions.

Headcount perversely increases the valuation sometimes. Hence, big head positions.

Headcount absolutely does.

In the 90's there was a joke that they'd take the engineering headcount and multiply it by 10M (or something), subtract a multiple of management and there's your valuation.

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

#268

Post by mwcampbell »

recuter wrote: post #159
jakey_bakey wrote: post #114

Earlier quoted context omitted.

I find it absolutely crazy that companies do this. My company's strategy is get one extremely solid person across all our verticals (Android / iOS / Backend / Infra) to minimise communication overhead and maximise iteration speed (since we throw out half the code we write anyway). I would be very hard pressed to hire more than 2-3 people in each role even if we were offered 10s of millions.

Headcount perversely increases the valuation sometimes. Hence, big head positions.

This seems so backward to me. Since technology is all about achieving more with less work, shouldn't headcount always count against the valuation?

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

#269

Post by DevKoala »

danielmarkbruce wrote: post #256
pyb wrote: post #218

Earlier quoted context omitted.

Good point, I am always surprise when well funded startups hire former big-tech engineers, rather than experienced startup engineers.

There is a pretty good reason. If the experienced engineer worked at a startup that went anywhere, they have a lot of money and aren't coming to work for you. So the choice in many cases is big tech engineer or failed startup engineer. It's not clear which is better, it is clear (ish) which seems better.

This is not true at all. A lot of people In BigTech companies boast of passing a tough interview as their biggest accomplishment and beyond that haven’t really done much.

Meanwhile, good startup engineers are used to learning new technologies quick, can work across the full stack, can own all aspects of their app/feature, work without much direction, never mind a formal spec, and generally are used to solve problems over shipping code.

Often, the key drawback with startup engineers who are available after working at one or two startups, is that they pick bad companies and do not really understand the business end of the equation. However they are still excellent problem solvers.

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

#270

Post by belval »

maybetoofast wrote: post #207
emgeee wrote: post #196

I was an engineer at Fast for over a year and wanted to clarify a few points-- - engineers did have access to data and could write their own queries to check revenue (but few people did until the article came out). - the strategy leadership decided on was to go after massive enterprise sellers which would, in theory, result in step-change functions in revenue. Many people knew about the low numbers but were willing t…

I joined Fast towards the end of last year. I didn't get as much exposure to the rest of the company as parent comment, but I'll say I saw a weird air of complacency and assumed success. I first ignored my instincts that something was wrong, but as I saw more of how the company operated, I became convinced that the single largest problem the company had was the culture. On the surface, I agree with the parent comment…

This 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.

Post reply on HN