[malandrew]

I don't know how this makes any sense. Engineering is the only way to automate things to allow a business to scale sublinearly. Why layoff high performing engineers when you can reassign them to problems where the goal is to automate things enough to reduce costs to below the cost of keeping them around. Any high performer should be able to create enough value within 6 months to pay the salary for the hole year. If anything, you buy your company the optionality to further layoff non-engineers that you can't yet layoff until their job is automated.

Now this may not be possible at smaller companies but at a company the size of AirBnB or Lyft certainly has enough problems that could still be better automated to help reduce costs further.

[gamblor956]

If there isn't sufficient work available, there isn't sufficient work.

For a highly-paid employee, you sometimes just can't create sufficient other work for them to do if you eliminate the work they were originally doing and other people are already doing the work they could putatively have been assigned to.

And quite honestly, a person's understanding of non-engineering functions would have to be extremely limited to think that more than a fraction of them could be automated away. Software has been the "it" industry for decades now. Jobs that haven't been automated by now are hard for software/robotics to take over.

[malandrew]

At both AirBnB and Lyft, I promise you there is sufficient work. I've had AirBnB employees ask me about joining the company to work on a large money saving problem I've got experience with that I'm certain they still have because it wouldn't be possible to have implemented since the last time I was asked.

[jmchuster]

There are definitely similar such needs at basically every company, but allocation of resources is not perfectly efficient (and often far from it).

[stormbeard]

Lyft is still hiring generalist SWEs after laying off 12% of the engineering staff.

[icedchai]

I've seen highly paid engineers put on projects that had high visibility but had, in my estimation, zero percent chance of actually being deployed due the risk involved. These were often rewrites of huge subsystems to use some "new" technology, when they would've been better off spending their time simply optimizing existing code. I was right in all of these cases. The projects went no where. PRs sat un-merged for years. This was during good times though, so the people did stick around.