> They are my peers and partners who are equally as "major players" as anyone else.

I love this. The best teams I've been a part of are those that had a mutual respect for everyone else's work. I was an engineer on those teams, and thank god for the product manager, tech lead, design work, ux researchers, etc. Things work so much better when there's a real culture of "we're all in this together, and we all have important roles to play".

My reply was worded to mirror "...I've come to the conclusion that software managers are not needed." which is obviously nonsense.

"Developers aren't some special creatures with one dimensional fixed mindset. They can do whatever that needs to be done."

Yes, but it is ok to generalize in a broad discussion like this one. Otherwise we can have no meaningful conversation. In general managers do not understand developers. And in general developers do not understand management. Those that are good have been exposed to both sides.

I never diminish anyone but it is naive to think that everyone contributes equally.

> which is obviously nonsense.

I think I've observed enough of this sentiment over the years, from some very smart and successful people, to come to the conclusion that, if it is nonsense, it is non-obvious.

> I never diminish anyone

Perhaps you never _intend_ to diminish anyone, but to some, your statements may reasonably appear to be diminishing some cohort.

I definitely agree that (in general) devs and mgmt do not understand one another.

I think this is bc one practices abstraction while the other practices persuasion.

I see these two forces as equal and opposite. A yin and yang kind of thing.

It appears that the best orgs have these two things in balance.

How are abstraction and persuasion "equal and opposite"? They seem to be completely orthogonal activities.

My idea is that the skills required to build things are at odds with the traits/skills required to persuade.

My cherry picked list:

Building: honesty, introversion, reason Selling: charisma, extroversion, empathy

but in the end, you decide who gets promoted or not, you decide who has to put the "extra effort" to satisfy whoever you work for. So of course everyone is a major player, it's your best interest.

but you're also the one who gets the time to see the big picture and hopefully realize that, yes, the development side of a project, while the most fundamental, is also just one of the part. The other being : handling customer expectations, making sure the budget use can be explained, making sure people stay happy even when confronted to "absurd" customer's request, making sure to understand the project ecosystem to make sure you get the right customer contact person in front of your team, making sure the one dev with a broken back gets a proper chair, making sure good project are rewarded, you make sure HR's department craziness don't alienate your devs, you-f*g-name-it (been there, done that, got the tshirt : I've been in dev, business consulting and management :-))

>the development side of a project, while the most fundamental

There's an entire world of industries in which software is a 'nice-to-have' enabler of various levels of business logic, not the product itself.

The assumption that development is the fundamental key to all projects is, I'd imagine, the 'delusion' referenced earlier.

Yeah, I work in an industry where software enables things, so it is central. But even in my industry (business apps), we could just go on with pen and paper like before. So programs are not "absolutely fundamental" but in the 21th century, well, they are :-)

But I can admit it's not like that everywhere, sure. But I've yet to see industries where people pay programmers to work on IT project which are not fundamental in a way or another or in the process of becoming fundamental. The point is when programs get deployed, they usually transform (and hopefully improve) a situation. Once the transformation is accomplished, the program becomes fundamental...

You understand, that company goal is not to "build a good product", even less to "write a good code", it's to increase a company value (in the sense that "good code" is orthogonal to the goal)? It might be unfortunate for developers, but quite often (almost always from what I've seen) developers' role _is_ minor here. Not in derogatory sense, just money don't come from writing code, they come from sales. Also no, not everybody can be a good manager, and not everybody can be a good developer, as those two roles require different mindsets and different training, so very few people can effectively do either (and not at the same time). So a good developer normally can't do "whatever needs to be done". You don't want a developer to do your surgery, do you?