I'm part of the technical leadership at a company who is transitioning from small to medium-sized company. This article is disparaging virtually all of the initiatives we're trying to actually implement.It is impossible to verify with as little context as you have given whether this is a good or a bad thing. But it clearly has a lot of bad in it.
In the case of an "enterprise software project", the sales process is driven by feature lists. The result is described very well by https://www.mail-archive.com/kragen-tol@canonical.org/msg001.... As frustrating as it may be for developers, a "feature factory" is in fact a rational outcome for the business.
If, however, you are trying to deliver real value to real existing customers who have real use cases, it is very, very important that you find ways to measure outcomes. The measurements might be internal to your clients, they can be soft, but they have to be measured. If you do not have such measurements, and there isn't transparency around them, then it is guaranteed that people aren't getting useful feedback upon which they can do better.
It's actually really hard to transition from anarchy into a more process-oriented where each person has a role to play so that Devs are no longer responsible for literally everything because everyone is used to Devs doing everything. PMs used to verbally communicate vague ideas of what the customer was looking for and it was up to us to interpret and decompose and deliver on dates agreed upon without our input.
I'm sorry, but this paragraph sounds like a pile of red flags wrapped up in a self-serving excuse. As an experienced software developer with decades of experience who has worked at companies like eBay and Google, being told this by management would make me question whether it is time to find a new job before this one goes downhill.
Yes, you want PMs to have a good sense of what is actually needed and to be an interface. No, you don't want devs involved in every choice. But I have never seen a PM who is as good as a good dev at looking at a customer need and figuring out whether there is a minor tweak to what already exists that can satisfy that need without building a new feature. And a system built as a collection of features that the devs have no context on is guaranteed to go wrong.
If you shut the dev side of your organization out of those conversations, I can guarantee bad results. No matter what excuses you give for your decisions.
There is a reason that the points in this article exist at all - because the alternative is actually worse!
This is dead wrong.
An example of an alternative that is appropriate for a lot of web companies (for example Google, Amazon and Booking) is an A/B test culture. Release features as A/B tests with transparent metrics. Share the metrics with everyone who is part of the decision INCLUDING devs. Proceed with general rollout of the features that actually produce positive results and rollback of the ones that don't.
When every feature has to be justified by actual customer impacts that have a concrete measurement attached, you get a much better product and more involved devs. The flip side is that when you start a project you have no idea whether you add millions per year to the bottom line or whether your feature will be a flop.
The challenge is that PMs and devs have to be willing to accept that sometimes they were wrong and that's OK. But the alternative is significantly worse, which is to have PMs and devs who are often wrong, refuse to accept it, and therefore fail to improve!