Sure but that's just because there are now different companies (AI labs) on this list instead
1,983 karma · joined July 26, 2015
Sure but that's just because there are now different companies (AI labs) on this list instead
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
Now it's 20x at the AI labs instead of 5x at FAANG.
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."
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)
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.
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.
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.
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."
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!
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.