What are some specific (behavioral) examples of "lacking professional mentality"?
+ A general disregard for the talents and value of other groups. (Funniest example: 'ice cream day' at work and these devs cam to sit by us just as we were sitting down and a dev sneers: "Ugh, marketing". We just laughed.) Eng. talent is more classically academic, and yes, marketing is full of fluff, but good marketing, operations, finance is really hard. Basically an intellectual condescension that bleeds into a lot of things.
+ Failing to internalize that ultimately, they work for a business. Sometimes that means doing a lot of things an Eng would never do, like bolt-ons or weird add-ons to address specific customer needs. Cringing around metrics or optimizations that are ROI oriented and maybe not perfectly suited to their vision of what a 'good product' should be. This one can be a real problem in terms of attitude ... because they can get rally angry and stuffy. It's almost an existential debate over who really 'owns' the product in a sense - the business, or the people 'making it'? It really bothers me sometimes the cynical take that many Engineers have in this area - because the presumption is that 'they know better' or 'it's their thing' but really it's not at all. Basically, their view of 'raison d'etre' is often upside down. It depends on the organization.
+ Engs without management experience have a disrespect for how hard management actually is ... more so than in other groups. Marketing specialists are generally not like that.
+ Getting caught up in ideological wars about architecture, or 'bike shedding' - we're all guilty of this, but it's funny how ridiculous and perverse this is when you step outside of it. We're 'building something' not making some kind of 'functional art'. As techies we all love 'new toys' so this one is more understandable.
+ On the business side, if I ask staffers to get something figured out, to give me a quick analysis, to make some slides for the Veep, if they are good, they'll nail it down and move forward. On the dev side, if they even move to it, I get a lot of academic prose as though they don't know the language of business.
It's almost as though it's a little existential: so many on the business side play on 'sports teams' etc. are are very extroverted and team oriented, confident, and natural communicators. Often devs are not. So there's almost a natural cultural clash as well.
You don't have to strongly convince or persuade team players. They don't have tidbits of antagonism, or 'special needs'. They show up early, bang stuff out, realize that the world is somewhat political, that nothing is perfect, that we have to bend for customers, we do 'what needs to be done'.
Edit: hugely generalizing here. Everyone and every team is different.
Re-reading it I make it seems like devs are this terrible bunch! Not at all, most of this is subtle, it's nuanced, it's not like we have gross dereliction, just some different patterns of culture and behaviour.
How can the devs understand the business decisions and learn to make less academic slides if they are not exposed to the business?
I worked at a medium sized business where devs had lunch with sales/product/marketing and was treated as more than just coders. That has helped me a lot when it comes to the business side of work.
If you have problems with the developers in your company, it may be that the real problem is with the company culture.
Devs are unique in their peculiar aspect disdain for 'management and business'.
And unfortunately it's very rare that devs get such exposure but we agree it'd be great if they could.
I don't know what comes first.
But the places where engineers get on well with management are the ones where their opinions matter. Otherwise resentment comes in.
Granted technical folk are a special breed but being technical myself and having moved over to the business side of things, it's still equally important to think about motivation for devs.
To maintain engagement, I bring my technical guys with me to meetings where they can add value. And I always press about the value of meetings and what we're trying to get out of it.
Yeah, and this is exactly the kind of person that gets laid off first. You have to be a little bit of an asshole to survive. Have an "edge", even if it works against the company, so you are perceived as a "badass".
But I also think that there are some significant problems in what you've said.
You describe what looks like a siloed structure, where sales/marketing people are deciding on what to build, and then throwing it over the fence to the developers to just "get on with". Where are the fast iterations, looping frequently back to the customer, and involving the whole team in the process? Does a developer never have a good idea with regards to features? I think that if you want robots who do what exactly they're told, then you're going to end up with... a development staff of robots.
Meetings. Endless meetings. Agile, if done on a weekly cycle, gives you no fewer than seven mandatory meetings. I don't disagree that it's important to communicate, but the prevailing culture across the industry is absolutely towards superfluous meetings which involve too many people. And I think that's a big problem. Yes, developers need to understand that perhaps not all of a meeting will be relevant to them, but if they're not relevant to the meeting, then really they shouldn't be in it.
"Failing to internalize that ultimately, they work for a business." - I think that the above point on solied structures is relevant here, but I think that there is more also. It depends on the type of business, and I think that you're referring to B2B. But I have personally seen in the B2C case, with millions of users, the sales and marketing side - sometimes from different divisions - preference their own career objectives over the user's experience. "We sold this for a million dollars" "But there's spyware on the partner side sometimes" "Tough. Build the integration". So while I think that you're right when it comes to building a special-case for a particular customer who genuinely needs that special case, I think that there are also other cases here where it's not that simple.
A more minor point but when you say "as though they don't know the language of business", I think you're right, they don't know the language of business!
I find your sports team / jocks vs nerds analogy interesting, perhaps mostly to inform on your general perspective. Personally I would prefer a team of smart developers who care deeply about the product that they build, working hand-in-hand with the product team, designers, sales, and customer in short iterations where rather than deciding precisely what will be built up-front, the solution is instead found organically with valuable contributions from everyone.
But you're dead right on the 'new toys'. That practice is unforgivable.