[aleph_minus_one]

> “There are too many meetings” At very large software companies, programming ability, technical expertise, and raw resources are not the limiting factors. Coordination is.

In my opinion there exist much more efficient ways for coordination: for example, write down some really good documentation and explanations that are then read by the other stakeholders, so that these, at the end, also have a very deep knowledge about the topic.

Nearly all employees have studied at a university, so the people are very used to writing texts (papers, seminar papers, lecture notes, thesis, ...).

In my experience the reason for too many meetings is rather that many managers love meetings.

--

> “There is too much process and bureaucracy” [...] At a very large software company, the software matters. It may be relied on by millions of people. It may underpin businesses, infrastructure, or daily life. It may not be particularly glamorous software but it has to work. It has to keep working. Failure is not charming, and recovery is not always cheap. [...] Process exists to manage risk, correctness, and scale. Calling it “too much process” without acknowledging the stakes involved is like criticizing a bridge for having too many safety checks because you once built a treehouse with a hammer and some nails.

This is one reason. Other common reasons for so much process and bureaucracy are

- Many managers love processes, because they can "hide" their failures behind processes, and introducing new processes and bureaucracy lets the manager pretend that he is doing something to solve the problems that plague the department.

- Many processes and bureaucracy are simply demanded by the legislature when you work in some heavily regulated industry. These legal demands often don't make sense.

[andrewflnr]

> Nearly all employees have studied at a university, so the people are very used to writing texts (papers, seminar papers, lecture notes, thesis, ...).

I wish. Most people I've known in universities seem to read and write the absolute minimum to get by.

But I tend to agree that writing is preferable to meetings in most cases. I want to try out a policy that all meetings of more than two people must produce a written artifact, or clarifying edits to an existing document, that explains whatever ambiguity required a meeting to clear up. But you also need people to read. People don't read.

[nunez]

Insanely easy to game

[andrewflnr]

What, the writing requirement? Yeah, you couldn't expect it to be airtight, more a nudge in the right direction.

[AnimalMuppet]

Meetings:

People who can write clear, unambiguous, accurate technical documentation are relatively rare.

And a meeting is in fact sometimes the best way of coordination. We have a question. We have five different people with relevant input into the question. Even if all five can write well (and will do so in a timely manner), we still need to reach a consensus on what the right answer is, and to make sure that everyone's issues are heard, and that they feel that they have been heard. A meeting often does that better than shooting emails back and forth among the five people.

Processes:

Processes are often added because something went wrong (often expensively wrong), and a process was created to make sure that it won't go wrong again. But what they miss is that the process also has a cost - a dollar cost, and a time cost.

Worse, there's a limit to how many processes most people can remember. You can create a process, that's the 47th process that your people have to remember, and when they don't keep it because they don't remember it, you can blame them. So here I kind of agree with you.

> Many processes and bureaucracy are simply demanded by the legislature when you work in some heavily regulated industry. These legal demands often don't make sense.

Maybe they don't. Ignore legal requirements at your own peril, though - they can have some pretty nasty teeth.

[Etheryte]

Just because written communication works well for you doesn't mean that it works for others nor that it's the best way to communicate about everything. There's a place and time for both. For example with documentation, it's nice to have accurate and well thought out docs so you can search and read through it, but oftentimes it's faster if your teammate just tells you what bit you need. Meetings are the same way. We've all been in meetings that could've been an email, but that doesn't mean every meeting can be an email.

[EagnaIonat]

> write down some really good documentation and explanations that are then read by the other stakeholders, so that these, at the end, also have a very deep knowledge about the topic.

I wish. The reality at the moment is someone gets an LLM to do it and the other person uses an LLM to read it.

[trollbridge]

Somehow large open source projects have figured this out.