Live data from Hacker News

What software engineers can learn from the rapid collapse of Fast

newsletter.pragmaticengineer.com

181–190 of 482 posts

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

#181
post #136

Is there anything actually new to learn here? Yes all equity is hypothetical. Yes there is no guaranteed road to an IPO. Yes you are taking a risk. People who take jobs at these kinds of companies for the upside do (or at least should) know this.

Don't work for a con artist with a long rap sheet.

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

#182
post #77

Not having a big company signed is not inherently bad. Going after small business can be a valid strategy (i.e. Salesforce) but it sounds like there wasn't healthy growth or the right relationships to support this path.

Consider this: > ... engineering directly raising concerns to the CEO, and suggesting to focus on larger customers, fewer customizations , and bring in more revenue. Sales, however, wanted the opposite: close many deals and hit their targets of signups. In the end, sales got their way, ... If the product is customized for nearly every customer, they've degenerated to a de facto consulting shop.

> degenerated to a de facto consulting shop.

Which is fine, as long it's priced right. Palantir is a consulting shop.

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

#183

Earlier quoted context omitted.

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)

You are 100% right — for late stage startups where you would normally see 500 people. At the Fast stage, the only viable promotion path is ship work that impacts the business or close deals that bring in revenue. The promotion levels game is something you play in larger organizations to engineer a rat race for people because it turns out they really like that. But no, a startup does not benefit from hierarchy quite t…

they were a company of nearly 500 people. they had 150 engineers. At that stage people who don't have levels will feel like they have no direction.

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

#184

Earlier quoted context omitted.

Author here. I was wrong on this information and updated the article - got a correction since. L6 and above employees would receive this: staff+ engineers, eng leadership, sales etc. There are companies where this information does go out to all employees in the spirit of radical transparency. Skyscanner is an example where every day, every employee gets the full revenue breakdown. These numbers are also shown on moni…

Lol. L6. Look no further folks. This guy Dominic was clearly LARPing a startup. Leveling frameworks before traction is a joke to me.

I completely disagree. They were 450 people with 150 engineers. If I had to guess I would bet the engineers clamored for leveling and it came from bottoms up requests and a need to be fair with compensation when hiring.

Now to be clear they shouldn't have been that big (clearly), but leveling people was not the problem.

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

#185

Earlier quoted context omitted.

You are 100% right — for late stage startups where you would normally see 500 people. At the Fast stage, the only viable promotion path is ship work that impacts the business or close deals that bring in revenue. The promotion levels game is something you play in larger organizations to engineer a rat race for people because it turns out they really like that. But no, a startup does not benefit from hierarchy quite t…

they were a company of nearly 500 people. they had 150 engineers. At that stage people who don't have levels will feel like they have no direction.

This is just such a big company mentality.

Yes, you need like Engineer and Senior Engineer and then when you have some rock stars who actually move the business forward they are your principles and/or future directors.

To try to build this all up ahead of time, show me where it's ever worked? When Google was that size they were playing with having no managers at all.

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

#186

Earlier quoted context omitted.

The TailScale folks caught a bunch of flak for their "do things that don't scale" approach to databases. But, honestly, most startups would be better off following that approach than what Fast did. Sounds like the engineers were just entertaining themselves with shiny toys rather than solving the problems they actually had.

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…

Even before using more servers, one should consider using (one) bigger server (and another as backup).

Massive servers are laughably cheap these days. E.g. 16 cores, 128GB RAM is €112 from Hetzner.

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

#187
post #61

Earlier quoted context omitted.

Yes, but also no. 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...

For the purposes of engineering salaries, CPI is not an accurate representation of the change in what $100M can buy.

I can't imagine PPI is too far removed.

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

#188

Earlier quoted context omitted.

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

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!

They seems to be the narrative I'm seeing for most of matters hiring. they're hiring very, very very aggressively

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

#189
post #147

The key informations are here : > 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…

> What's not to like here ?

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.

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

#190
post #80

Earlier quoted context omitted.

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

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.

>> I find it absolutely crazy that companies do this.

It has changed a bit, but a large part of it is due to HR policies around salary bands. You can have one person do 10x or 5x and another do 1/3x but their salaries are often max .5 factor apart. Ive been in situations where i'd rather reward (perhaps with a vest period) one person with 3x the salary and just skip all the inter-person communications bs, but HR makes it hard.

We were able to do this at hedge funds, and i'm sure small startups can do this, but as companies grow, HR will generally not allow this.

Post reply on HN