The article is describing a broken process that is often installed as organizations scale.
If this matches what you’re currently installing, I suggest reconsidering your plans.
Medium organizations do need more process than small ones, but not all processes are good.
In particular, if you have a growing product, and the plan is to ship a ton of features without internal (to engineering) coordination, and without improving, or even maintaining the core product, then you’re probably doing more damage than good, and neither the developers nor the customers will thank you for it in the long run.
It would be important context to know if this is an agency or a product owner company.
There is a whole spectrum of client-agency relationships, and some of them are more like a feature factory than others, and there's nothing wrong with that.
Some companies want to hire a development team to work as if they were in house developers. Some clients just want to ask for Feature X and have Feature X delivered. They keep most of the discussions about business value, metrics and forward planning internally.
It doesn't have to mean that you have a business with bad processes, it could just mean you have the latter client relationship and a fairly mature process of delivery that doesn't require constant turmoil, refactoring and retrospectives.
That's often the case. If your agency is part of that discussion then you can provide enormous value to the client from your experience, and hopefully PMs are pulling the developer input up into discussions with clients as well. But then that is your relationship changing, and you can start to address many of the concerns in the article anyway.
I guess my point is just that there are certain relationships where it's just not your decision whether or not feature X is a good fit. I wouldn't want people reading this article thinking their company is broken, when it's just a different type of engagement.
Sometimes the CEO wants a popup on the homepage, and every single person in the chain between the CEO of the client company and the Developer at the agency agrees that it's a bad idea, but you still have to implement it.
That depends on who the clients are, and why did they hire you. If you're just a subcontractor in an org run by smart people, it may very well be that they're asking for X, actually need X and expect to get X - they just outsourced the boring work to you.
Why would you think that? The project manager has communicated well with the client and the requirements getting passed along are correct and full. The developers are specialists in their platform, so implementing the feature is no problem.
From experience, it's actually a really nice environment to work in. Everyone is good at their job and you don't have to deal with the clients directly.
Because AFAIK the best programmers also tend to be perhaps over-invested in their work, so that just "doing feature X" won't cut it for them ?
Or am wrong ?
Depends. In many b2b custom software contexts, the client does really know exactly what they need (e.g. when you’re implementing integration between two products they are already experts of).
If this matches what you’re currently installing, I suggest reconsidering your plans.
Medium organizations do need more process than small ones, but not all processes are good.
In particular, if you have a growing product, and the plan is to ship a ton of features without internal (to engineering) coordination, and without improving, or even maintaining the core product, then you’re probably doing more damage than good, and neither the developers nor the customers will thank you for it in the long run.