I'd like to ask these CEOs, for people which are taking advantage of the system, why are they not let go? Could it be that management often have no clue how much value each employee brings to the team? Is RTO being mandated to avoid facing that uncomfortable truth?
> '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."
How is the shorter deadline better for the worker? Ultimately, that devolves to a race to the bottom with people choosing between overworking or being laid off. Surely AWS is profitable enough by now, that all those employees could get their work hours reduced, receive a raise, and have both the organization and the product keep existing just fine.
I could argue that a company that would do that could be in a long run out-competed by a company that would do layoffs and push their employees for higher productivity by utilizing AI.
> 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)
> 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)
Idk I barely ever work with people who are like this, and if people become like this, it's usually obvious to everyone that it's happened and they get a talking to in the office then get shown the door
I assume you are in a country with fire-at-will policies. In Germany you have a job security, you can't just fire people without a reason. The difficulty is actually proving their incompetence or unwillingness to work. Thus in my experience (working a self-employed contractor in Germany) this group is far larger than 50%. Also one of my reasons why no good software comes out of germany (and this includes SAP, as long as you show me a single end-user that is happy with working with SAP software).
Yes I work in the US but my company has extreme time wasting practices designed to have engineers explain every thing they do and why it's worth it. I never found this helpful and find it causes more problems than it solves.
You have to prove it is the employees fault by intentionally not completing the task. Incompetence or incapability is not the employees fault, because well, you hired them and judged their ability - probably due to their education (it is a little more complex than that of course). As a concrete example, if you have a CS degree from the 80s and job as a COBOL programer and your employer decides to assign you to a new team doing react+js, the employee is still formally qualified. You couldn't fire him for incompetence, just because a 22 year old bootcamp graduate delivers 10x the results.
Those people should not have been hired, or should have been let go at 6 months when that became obvious. The real solution to this problem doesn't fit with most management methodology though.
The mediocre unmotivated person is dragging down the other, killing their motivation. You'd be better off without them even if you couldn't replace them.
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.
I'm referring solely to technical skills. I think it is actually harder to be an L6 today because of the sheer number of (both political and technical) constraints you face, but L6s and even L5s in 2010 would do large-scale system design of a sort that basically doesn't exist anywhere within the company 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.
Every time I think about leaving Microsoft for a higher paying FAANG job, I think about our teams general chill work schedule and lax time off. Really hard to give that stuff up, even for tons of money.
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!
Again, I can only speak for Cloud. I find product changes are reviewed by a dozen people at least and take months to finalize. It can be slow, but usually we're sure why we're making the decisions, and where risks lie. A large weight is given to customers asking for features, so they're in the loop.
It's absurd that there's no Google strategy documents. 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. At a smaller level, every feature has a business rationale backed by customers requesting them or hard dollar figures.
I really don't know what's going on here. Do people think Google runs the same way as it did in its early years? It's a fairly mature company with a good track record of revenue growth, especially for such a massive company. These things don't happen haphazardly.
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."
reply