> I don't think the article is saying engineers need to have a meeting for each of these.
I think you've missed the point of my comment.
As I said, the core principles of the article are not wrong. It's the framing of the article that causes problems.
When engineers and other ICs read this article, they tend to assume that these planning sessions, feedback loops, retrospectives, and other mechanisms aren't happening because they don't personally see them. That's why I pointed out that most engineers wouldn't be happy if they were pulled into every single planning, retrospective, and feedback meeting that the product managers are doing. I'm not saying they're bad, I'm just saying it's bad to assume you work in a terrible feature factory if you don't see every item on this checklist.
This goes both ways, of course. It would be silly for product managers to read an article entitled "12 Signs You're Working In A Code Factory" and then start second-guessing all of their engineers' decisions or assuming the engineers aren't implementing proper process behind the scenes. That type of article would generate outrage on HN, but engineers second-guessing product management is always well-received in an engineer-centric forum.
>> When engineers and other ICs read this article, they tend to assume that these ... mechanisms aren't happening because they don't personally see them
I think you're missing the second point of the article here. Per the article point 1 "Or, if measurement happens, it is done in isolation by the product management team and selectively shared. You have no idea if your work worked"
So the article is also highlighting failure to share as a failure mode. Every good company I worked at, I [the lead engineer] had equal ownership as my product owner. The respected my opinion, learned not to doubt my warnings, trusted my intuitions, and made adjustments based on my recommendations.
That balance of shared ownership is a defining indicator that it's not a feature-factory, whereas a "I call the shots as product" mentality is more feature-factory.
Is it possible you [rightly] worry about this article because you are what it's talking about?
Organizations where individual contributors are respected find ways to communicate what's discussed in those meetings. I wouldn't want to be a manager in an organization where engineers can assume those meetings aren't taking place.
I think you've missed the point of my comment.
As I said, the core principles of the article are not wrong. It's the framing of the article that causes problems.
When engineers and other ICs read this article, they tend to assume that these planning sessions, feedback loops, retrospectives, and other mechanisms aren't happening because they don't personally see them. That's why I pointed out that most engineers wouldn't be happy if they were pulled into every single planning, retrospective, and feedback meeting that the product managers are doing. I'm not saying they're bad, I'm just saying it's bad to assume you work in a terrible feature factory if you don't see every item on this checklist.
This goes both ways, of course. It would be silly for product managers to read an article entitled "12 Signs You're Working In A Code Factory" and then start second-guessing all of their engineers' decisions or assuming the engineers aren't implementing proper process behind the scenes. That type of article would generate outrage on HN, but engineers second-guessing product management is always well-received in an engineer-centric forum.