mji

A decade ago, it was a real flex in San Francisco to say you worked at Meta, Google, Apple, Tesla ... That’s not what it feels like anymore.

Sure but that's just because there are now different companies (AI labs) on this list instead

At very large software companies, programming ability, technical expertise, and raw resources are not the limiting factors. Coordination is.

If coordination is your limiting factor I'd argue that it shouldn't be, and you're not investing enough in removing it as a factor. Companies can use various tools to do this, for example:

* Defining directly responsible individuals / single-threaded leaders so that every choice doesn't involve massive coordination

* Putting people who work together in the office sitting next to each other most days of the week

* Or, for remote work, having a strong culture of async communication that is visible to the broader group by default, for example with Slack

Until recently?

Now it's 20x at the AI labs instead of 5x at FAANG.

Maybe OP learned these things precisely because he saw the consequences of them not being done

Even if we suppose all those things are true (not a given), I would not expect these layoffs to meaningfully change them.

Because their hiring process will just hire more employees who will take advantage of the system

I think CEO types simply believe (rightly or wrongly) that a large number of people are taking advantage of WFH to barely work.

'generating new code' is a small part of the job

I think this attitude has been taken too far to the point that people (especially senior+ engineers) end up spending massive amounts of time debating and aligning things that can just be done in far less time (especially with AI, but even without it). And these big companies need to change that if they want to get their productivity back. From the article:

One engineer said that building a feature for the website used to take a few weeks; now it must frequently be done within a few days. He said this is possible only by using A.I. to help automate the coding and by cutting down on meetings with colleagues to solicit feedback and explore alternative ideas."

you say some filler to get someone incapable of understanding what it is that you're doing off your back for 24 more hours has consistently been one of the most useless and unpleasant parts of the job

This sucks for the 50% or so who are like you, but there's another 50% who won't really get much done otherwise, either because they don't know what to do and aren't self-motivated or capable enough to figure it out (common) or because they're actively cheating you and barely working (less common)

it's very hard to tell when an individual has solved a problem that otherwise would have taken 5 people to solve... so you'll likely find that it's much easier for big tech to reward people for managing large teams or leading large teams to execute on a project rather than for solving such problems themselves

As usual for anything from Charity, this is a great article!

I do find it interesting that she repeatedly call out things from Brian Chesky's talk as obvious, which are things that anyone who has worked in a large tech company know can be anything but obvious (or more charitably, obvious, but large organizations fail to execute on them anyways).

For example, efficient org structures, having as few employees as possible, managers being subject matter experts about their team's work, not just "hiring great people and getting out of their way", etc. All of these are problems that I suspect anyone who has worked at a large tech company is familiar with.

i.e. a mid-L6 today is about as good as someone just promoted to L5 in 2010, an L8 promotee today is about a mid-L6 from 2010, a new L4 today is the equivalent of an intern back then

This seems extremely surprising. I can believe that the 2010-engineers were more technically capable, but there was also a lot less non-technical complexity involved in getting things done in 2010 than there is today.

In my experience it is the same at Google but not at all at Microsoft.

I think the specifics of each company’s performance review system have a lot to do with it. At google the level definitions are so prescriptive that it is like a checklist to get good ratings and promotions, and doesn’t leave much room for people to do good work in ways that are unique to them. At Microsoft you do not receive a formal rating, and the level definitions are very vague and mostly come down to just doing well at whatever your team needs at least at lower levels.

We seem to be looking at the same text and drawing wildly different conclusions from it.

When the blog post says "the actual product decisions and working code were reviewed much less. Only the other PMs on my team reviewed my specs" referring to Microsoft, to me that lines up with you saying "I find product changes are reviewed by a dozen people at least and take months to finalize." referring to Google. The distinction the author is drawing is that Microsoft doesn't review day-to-day engineering work like this, because fundamental product decisions are made at a higher level, while smaller design decisions might be made by individual PMs or engineers and make it into the product without ever being reviewed.

When the author says "The founders had ideas of their top priorities and worked with the relevant teams on those, but the list of the top company OKRs was a subset of all the OKRs, not a roll-up. Some people were not working on anything the company cared about strategically!" referring to Google, that sounds very aligned with you saying "There's company-wide and division-wide OKRs that get major events to publicize them, with large Q&As and all. It's easy to learn what the priorities are and why. But, usually you just pay attention to what your local group is working on."

Having worked at both, 20% time is the only part of the article that is somewhat off-base.

In particular the following string of paragraphs match exactly what I’ve seen at both:

With all that up-front planning, the actual product decisions and working code were reviewed much less. Only the other PMs on my team reviewed my specs, and only me and the tester (also new grads usually) reviewed the working changes before they were added to the branch. For what it’s worth, I think this is why the quality of the details on Microsoft products is often lacking—a random PM made a decision and no one bothered to push back on it.

Contrast that with Google.

At Google, I never saw a strategy document. I went to every Friday all-hands, but I didn’t hear the leaders talk about a broad vision of what we needed to build. The people above me didn’t set direction and ask me to follow it.

Instead, leaders encouraged teams to generate their own ideas. The founders had ideas of their top priorities and worked with the relevant teams on those, but the list of the top company OKRs was a subset of all the OKRs, not a roll-up. Some people were not working on anything the company cared about strategically!

Why does there have to be some conspiracy or hidden agenda? Uncontrolled Covid spread would result in an extremely large number of deaths and overwhelm the healthcare system.

That doesn’t mean that zero-Covid is sustainable forever as time goes on, as lockdowns and other frustrations take more and more of a toll. New Zealand and Singapore already had to give up on it. Even putting protests aside, this wave could easily be the one that can no longer be controlled.

An interesting project, but one that seems to suffer from a (presumably unintended and unknown) conservative bias itself, as evidenced by opening the page and seeing conservative opinion outlets like Breitbart and Drudge displayed literally next to reputable sources like the New York Times and Politico