> “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.
> 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.
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.
As a technology company scales up, making great software becomes one of a hundred things the company needs to do right in order to survive and grow. Doesn’t mean it isn’t absolutely essential, but so is having a strong GTM machine, finance competency, operational rigor, HR, and a long list of other essential functions.
It’s only the tech industry where the voice and ego of small companies hold outsized share of voice and love to claim the contrary.
Equating process to risk aversion is a mistake I hadn't seen before. It's true that moving slow makes it less likely to make something worse per unit time, but it also makes it less likely that anything will get better. It means that you don't try many things, and can't get important things done quickly.
You can ensure quality by making features opt-in, having a beta program available to risk tolerant users, adding QA resources, having representative users in captivity (employed at the company).
There is no law that says that you must move slow or do less in order to be low risk, you can also do a lot, move fast, and only let the best out.
I liked this post. I may have some minor qualms (e.g. while I think execs should be proxies for the customer, they have many other competing motivations that can push customer needs way down), but I especially liked the closing section:
> Understanding before criticizing
> Large software companies have real problems. Some are structural. Some are cultural. Many are self-inflicted. But many of the behaviors people complain about are not pathologies – they are consequences.
> If you want to criticize how large organizations operate, it helps to first understand why they operate that way. Without that understanding, the criticism may feel sharp, but it will not be useful.
I see that kind of "criticizing before understanding" all the time on HN, and while that's probably just inherent to an open forum, commenters who do that should realize it makes them come across as "less than insightful", to put it generously. Like I see tons of comments often about how managers only get to their position through obsequious political plots. And sure, that may exist in some orgs. But you can always tell when folks have never even considered the competing forces that act on managers (i.e not just the folks they directly manage, but requirements coming from higher ups, and peer teams, and somehow being responsible for a ton when you actually have few direct levers to push) and solely view things through the lens of someone being managed.
Someone who says there are too many meetings is probably actually saying they are having bad meetings. If they got value from those meetings, they wouldn't be complaining. So there is likely still a problem to address.
Also, as a somewhat trivial side note, an instinctive reaction to not getting the clarity you need from a meeting is to ask for another meeting. So even if the optimal level of meetings is annoyingly high, bad meetings will probably push the level of (bad) meetings even higher. So you'll still actually have "too many" meetings.
Coordination is almost free in a ten-person startup. It is still relatively easy in a forty-person company.
I find coordination difficult even for two / three persons for any given topic where there the tree of dependencies (of sub tasks or others topics related to it) isn’t trivial and there are unknowns to research. Unless those persons are doing the same thing and are constantly communicating, which is very expensive
One nitpicky detail is that the executives may be a rep for the customer/consumer, but are also very much reps for the shareholders and that’s a pretty big distinction
I prefer Parkinson's take on the matter. Parkinson's law has a lot more to do with why companies grow so large. Why WhatsApp can can't write meaningful software with fewer than 10 people
The thing this (very good) post doesn't mention is that big companies select for blub languages because that's where the most low-cost labor is, in that you can hire multiple Java developers for the cost of one Haskell developer, even if Haskell might be objectively a better choice for the project.
I don't think this is a charitable interpretation. As a business, you need to be able to backfill positions or hire more when the need arises. If you use a language that's very commonly used, it's a lot easier to hire. There isn't anything sinister to that, it's simply reasonable.
There was a post, I think on the Uber engineering blog, that stuck with me. It essentially boiled down to: it's easier to change the tech stack than the hiring pool, and talked about deliberately setting something up that was technically less optimal but easier to hire for
Corollary: it's perhaps easier to throw money at fancier hardware to improve performance than the alternatives
> “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.
> 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.
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.
As a technology company scales up, making great software becomes one of a hundred things the company needs to do right in order to survive and grow. Doesn’t mean it isn’t absolutely essential, but so is having a strong GTM machine, finance competency, operational rigor, HR, and a long list of other essential functions.
It’s only the tech industry where the voice and ego of small companies hold outsized share of voice and love to claim the contrary.
Equating process to risk aversion is a mistake I hadn't seen before. It's true that moving slow makes it less likely to make something worse per unit time, but it also makes it less likely that anything will get better. It means that you don't try many things, and can't get important things done quickly.
You can ensure quality by making features opt-in, having a beta program available to risk tolerant users, adding QA resources, having representative users in captivity (employed at the company).
There is no law that says that you must move slow or do less in order to be low risk, you can also do a lot, move fast, and only let the best out.
I liked this post. I may have some minor qualms (e.g. while I think execs should be proxies for the customer, they have many other competing motivations that can push customer needs way down), but I especially liked the closing section:
> Understanding before criticizing
> Large software companies have real problems. Some are structural. Some are cultural. Many are self-inflicted. But many of the behaviors people complain about are not pathologies – they are consequences.
> If you want to criticize how large organizations operate, it helps to first understand why they operate that way. Without that understanding, the criticism may feel sharp, but it will not be useful.
I see that kind of "criticizing before understanding" all the time on HN, and while that's probably just inherent to an open forum, commenters who do that should realize it makes them come across as "less than insightful", to put it generously. Like I see tons of comments often about how managers only get to their position through obsequious political plots. And sure, that may exist in some orgs. But you can always tell when folks have never even considered the competing forces that act on managers (i.e not just the folks they directly manage, but requirements coming from higher ups, and peer teams, and somehow being responsible for a ton when you actually have few direct levers to push) and solely view things through the lens of someone being managed.
Someone who says there are too many meetings is probably actually saying they are having bad meetings. If they got value from those meetings, they wouldn't be complaining. So there is likely still a problem to address.
Also, as a somewhat trivial side note, an instinctive reaction to not getting the clarity you need from a meeting is to ask for another meeting. So even if the optimal level of meetings is annoyingly high, bad meetings will probably push the level of (bad) meetings even higher. So you'll still actually have "too many" meetings.
One nitpicky detail is that the executives may be a rep for the customer/consumer, but are also very much reps for the shareholders and that’s a pretty big distinction
I prefer Parkinson's take on the matter. Parkinson's law has a lot more to do with why companies grow so large. Why WhatsApp can can't write meaningful software with fewer than 10 people
I did not expect to see big-company apologia on Hacker News.
https://en.wikipedia.org/wiki/Apologia
The thing this (very good) post doesn't mention is that big companies select for blub languages because that's where the most low-cost labor is, in that you can hire multiple Java developers for the cost of one Haskell developer, even if Haskell might be objectively a better choice for the project.
I don't think this is a charitable interpretation. As a business, you need to be able to backfill positions or hire more when the need arises. If you use a language that's very commonly used, it's a lot easier to hire. There isn't anything sinister to that, it's simply reasonable.
There was a post, I think on the Uber engineering blog, that stuck with me. It essentially boiled down to: it's easier to change the tech stack than the hiring pool, and talked about deliberately setting something up that was technically less optimal but easier to hire for
Corollary: it's perhaps easier to throw money at fancier hardware to improve performance than the alternatives