> The author seems like someone who just loves writing code as opposed to wanting to deliver maximum business value (As defined by the company), so it makes sense he dislikes big companies.
I think the point is that very little actual business value is being created. This not necessarily due to "actual business needs" but because of deterioration of culture over time and the inevitable principal-agent induced issue of managerial bloat.
Instead of accepting that increased communication needs will slow down everything to a crawl, how about eliminating needless communication? Thats how Amazon does it, and look where they are now.
It's always a worthy goal to try to improve communication efficiency, but it's also the case that a very common failure mode that programmers at the leaves of org charts do not understand what is driving the value of the business they're working in, and have an inflated sense of the importance of the code they're writing (or that they wish they were writing).
But that goes for everyone, until you can put it into numbers which aren't gamed. That's what is being challenged here. Do the communication methods as they exist today provide value, and to what degree? Do we have actual numbers?
Whenever the "we hate meetings / the current bureaucracy" crowd criticizes the current state of affairs, the opposition tends to seek the high ground and go "well but you just don't understand what drives value". Meanwhile, there is a surprising lack of numbers regarding all this.
Ironically, trying to measure this better would inevitably require more bureaucracy! It's a good point nonetheless.
But I'll also say a positive word for qualitative reasoning based on experience being a good first approximation of things. If something gets pushback from a lot of people who have spent a lot of time trying to coordinate large efforts, then it's worth considering that those people may be right. I don't know anyone who has spent a lot of time in one of these coordinating roles who thinks that the primary issue is too many meetings and not enough code being written.
>If something gets pushback from a lot of people who have spent a lot of time trying to coordinate large efforts, then it's worth considering that those people may be right.
It's one thing to consider it an approximation, it's another thing entirely to consider them "right" which is frequently followed with "so we won't investigate any further". Most of us don't live in situations where such decisions are actually critical. We can afford to criticize and experiment. Instead, this line of reasoning tends to be misused and shush any investigation.
>I don't know anyone who has spent a lot of time in one of these coordinating roles who thinks that the primary issue is too many meetings and not enough code being written.
And you don't think that group, much like others, may be a little self-reinforcing?
It isn't "so we won't investigate any further", it is "we don't think it is the best use of our resources to investigate this" and in my view it also implies "but if you have a good idea for how to investigate it empirically, please feel free to do so".
I don't think "that group" is self-reinforcing at all. Essentially everyone who comes in with no experience comes in thinking "meetings are crap, communication is crap, we just need to write code". Most of those people (but not all!) slowly but surely change their minds as they gain experience. But every one of those people is an opportunity for the thesis to be disproven. Similarly, nearly every new organization is an opportunity to try something new. Google didn't start out with lots of meetings and engineering committees and design review processes. They started out just wanting to write tons of code. They didn't hire management (or "agile") consultants or bring in outside managers as they grew to come tell them how to behave like a big company is supposed to. The people who started out writing all that code and ridiculing bureaucracy are the same people who eventually accrued processes to manage meteoric growth.
I really don't think people are as narrow-minded and closed off to this as you seem to believe. People are hungry for a better way to manage organization growth, it's just a high bar because people have seen lots of these kinds of efforts, and frankly just get kind of bored of chasing "one weird trick to make everyone way more productive" again and again.
> it's also the case that a very common failure mode that programmers at the leaves of org charts do not understand what is driving the value of the business they're working in
If that's common and not being addressed, it must not be important. If it's not important, why mention it? Seems like victim-blaming.
"very little business value" is highly subjective. I'm sure that Amazon also has a lot of activities which generate "very little business value" under whatever measure you define.
I think the point is that very little actual business value is being created. This not necessarily due to "actual business needs" but because of deterioration of culture over time and the inevitable principal-agent induced issue of managerial bloat.
Instead of accepting that increased communication needs will slow down everything to a crawl, how about eliminating needless communication? Thats how Amazon does it, and look where they are now.