I've also worked in consulting and appreciate the explicit requirements, but I find the formality much less efficient than the process you describe earlier. It ends up being very "waterfall" and exactly the approach the Agile Manifesto attempts to counter.
Perhaps you prefer a more waterfall, hierarchical development process, or the companies (big ones) or industries (highly regulated) that necessitate it?
A week-10 day sprint on _one feature_? They haven't drunk the scrum kool-aid yet. Just wait until they do - then every feature will be a "story", and no individual story will be allowed to be assigned more than 8 "story points" (which for some reason means "one day"). If you think a "story" will take more than 8 "story points", you'll be asked to break it down into "subtasks" of no more than 8 "story points" each (you'll be asked to do this accurately in a few minutes in a standup meeting). Trust me, if you tell a higher-up non-programmer that there's anything wrong with the development model, they'll hear "we need to move to the 'scrum' everything-is-mandated-to-take-less-than-a-day development model".
We're not all a bunch of mini CEOs.
Maybe he worked at poorly managed companies, who knows. The fact that he was asked to participate in meetings instead of only being assigned purely code-related tasks isn’t very compelling evidence of a company being a “joke”.
The author's complaint was that he only gets to spend 12-25% of his time on these tasks on a good day.
I dont think that relatively speaking companies that dont do this are horribly run since it seems to be the norm but I can see why somebody who isnt used to it would rant.
In general larger companies do everything inefficiently. It's to be expected. Small companies wouldnt exist otherwise.
When you read about organizations which were highly effective there is usually a common theme of management by objective and giving people ownership. “The HP Way” and this speech by Rickhover are two such examples: https://govleaders.org/rickover.htm
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.
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.
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.
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?
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.
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.
It’s easy to understand why. The 15 minutes spent bickering over the color of a button will be far more likely to leave an impression and remembered vs the 90 mins spent on ordinary, necessary and useful discussions in the same meeting.
I'm sure it varies for people (which is why you're downplaying it), but for at least some of us, it is simply the truth, the reality we have to face every day we go to work.
"Everything we've looked at so far is a technical problem. Compared to organizational problems, technical problems are straightforward. Distributed systems are considered hard because real systems might drop something like 0.1% of messages, corrupt an even smaller percentage of messages, and see latencies in the microsecond to millisecond range. When I talk to higher-ups and compare what they think they're saying to what my coworkers think they're saying, I find that the rate of lost messages is well over 50%, every message gets corrupted, and latency can be months or years"
Dan goes on to say: "When people imagine how long it should take to build something, they're often imagining a team that works perfectly and spends 100% of its time coding. But that's impossible to scale up. The question isn't whether or not there will inefficiencies, but how much inefficiency. A company that could eliminate organizational inefficiency would be a larger innovation than any tech startup, ever."
Communication scales extremely poorly compared to code and large organizations require a very different skillset than small companies. 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.
There are also good and bad big and small companies. A well run big company is still going to have a large amount of communication overhead vs a small company.