> 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
> '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!
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
Sure but that's just because there are now different companies (AI labs) on this list instead