> 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

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

Obviously doing this makes sense when possible, but in cases where you see it, it's usually due to a fair amount of work to have made this possible.

To give a simple example, I work on a class of problems that require a VP level approval for new instances of $thing. I've gotten this down to a pretty straightforward process where I can work with folks who are proposing a new instance, get things working, and then the VP usually is happy to stamp the work we've already done. Though in some cases they aren't, and they have (good, probing) questions or changes they'd like us to make. But that's only possible because I have a longstanding relationship with the set of folks who ultimately approve this kind of thing, I have worked with them on a process that they like, and I have the experience to shepherd things effectively, and their trust and buy-in. And I'd argue that my case is pretty simple, because while there are a handful of responsible people that I could go to, there's rarely any individual concerned.

Consider a different, relatively common case, of a client and a server that are owned by different teams. The client wants a feature in the server, and perhaps is willing to do some development and loan headcount to implement the feature. Who is the single responsible party here?

It should probably be either the manager of the client server team or the mutual manager of both if the teams are fairly close in the wider org, but then you have multiple indirect layers between the people doing the work (client team members) and the accountable person (server team manager), and that's the state you get to after you've done a bunch of coordination work and gotten everyone to agree to that division of labor and accountability.

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.

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

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?

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

If they admit its true but the solution still stands, would you feel any better?

> '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.

> and by cutting down on meetings with colleagues to solicit feedback and explore alternative ideas.

At least something good comes out of this.

What used to take a week now can be done in just 5 days.

> 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).

The ability to deliver a 30 second summary in a daily standup has very little to do with real productivity.

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.

Incompetent workers migrating to the US is a big issue.

Why is incapability to make progress at work tasks not a valid reason for job dismissal in Germany? Unless I am misunderstanding something

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.

It only makes sense to fire someone who needs to be nudged into getting their job done if you can find a replacement at a similar cost who doesn’t.

1+1 is often less than 1.

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.

Just if there were a way to filter people at hiring and perhaps some way to choose to not employ them after doing so...

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

Forget about being rewarded for being a problem solver in a big corp. Respected: yes. Rewarded: no.

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.