CTOs noticed it. When product pipeline is empty, because engineers finished all the outstanding tasks, the engineers are awarded with more work: "The new software engineer is a product leader. Someone thinking about what the product is, not just how it works", or, in other words, engineers are going to be tasked with putting more content "the what" into the product pipeline.

▲

bryanrasmussen 9 hours ago | parent | next [-]

It has been my experience that nobody wants to hear the software engineer's opinion as to what will improve the product however.

▲

bsenftner 9 hours ago | parent | next [-]

Nobody wants to hear anyone's opinion but their own, we have a poverty of effective communications.

Nobody wants to communicate because it is pointless to communicate: what you say will be misunderstood, it will be repeated incorrectly and attributed to you, people will play games with your messaging and with you for trying to communicate.

The management bully game activates, and they all participate in keeping the engineer down.

This is normal at every engineering organization, it is lord of the flies.

And this is how we educate people, This situation is created. All because we refuse to recognize that learning how to debate controversy and learning how to manage disagreement is completely unrecognized as a valued skill.

So we avoid controversy and any disagreement is an opportunity to bully and force one's way. Which is completely avoidable, with basic effective communications training. Debate to understand, disagree to learn.

	▲	mathgeek 8 hours ago \| parent [-]
		I’ve worked at such organizations, you’re not wrong about them. They are not all that way. Many are, but the issue is the people not knowing how to or being comfortable with “disagree and commit” and other communication strategies.

▲

cik 9 hours ago | parent | prev | next [-]

This sounds like dysfunction. As engineers, we're not necessarily any more correct than anyone else. But we do have a seat at the table, and good organizations at least listen.

	▲	bryanrasmussen 6 hours ago \| parent [-]
		OK actually thinking about it I have worked at one organization where they did listen, other than startups of course, but even in those the people who had power to implement things tended to consider the ideas of non-programmers more important, which maybe they were. Not sure how it is doing now about listening to programmers because it was sold off by the parent company and then became really successful and grew a lot, so it is essentially a different company. I have a feeling it is less likely to listen to things now though.

▲

gib444 9 hours ago | parent | prev [-]

Yup. This was a very useful precursor to the AI era: telling engineers they're worthless and they are there just to implement the specifications and ideas drawn up by more important people. Shutting them out of the earlier discussions and only informing of the project way down the road

Now they're just trying to reduce us to idiots shovelling coal (specs) into the furnace (LLMs)

▲

olsondv 9 hours ago | parent | prev | next [-]

Has that not been what a senior SWE is? You’re making it sound like engineers need to be asked to implement features rather than contribute to design. At my company, if you are not coming up with new features or applications, your days are numbered.

	▲	helge9210 9 hours ago \| parent [-]
		Depends on the organization and on the SWEs. I do share your understanding, which is making me unfit for organizations, where the authority over "what" is firmly held by POs and the whole vertical on top of them.

▲

cucumber3732842 9 hours ago | parent | prev [-]

Your average mid to senior SWE is too far from the actual use of the product to actually do that well though.

There are some smaller businesses and selectively structured ones where that's not the case but for the most part organizations keep engineers from interacting with the customers enough to really know what the customers need and want.

There are some cases where a savvy engineer can say "well if I unify X then it'll be trivial to make Y self service and that'll make redundant an entire category of support tickets" or "we've been getting a lot of requests for X, maybe Y should be extensible so that those can be trivially accommodated" but by and large engineering teams are not positioned to have the knowledge to identify these things. And this is mostly an intentional organizational architecture decision.