> If they're not on the same page, they make each other look worse
This is right, engineers need to understand the problems that their end users have and of those problems those that severely affect sales should be considered carefully...
however what seems to happen more often is sales or management end up dictating the solution to a problem... but software solutions are software engineers jobs.
This happens to me so commonly but thankfully I do not work in a company with a rigid hierarchy, which means rather than being forced to blindly follow a request I go and find out the context that this request originated from, understand the problem and then propose a suitable solution - everyone is _always_ happier. But this requires autonomy and respect from all members, something that rigid hierarchies appear to sometimes oppress (but then I've only ever been a lucky observer of such institutions so maybe i'm wrong).
That sounds very annoying, and I infer that some people have it even worse. What efforts do you see upper management making to bring the two sides together? I notice that as I get to know someone better, I can understand our differences by understanding the ways in which we process information differently. Of course there will be exceptions, but sales people and engineers (beyond their tasks/goals being different) have different strengths and weaknesses as people and processors; sometimes the differences aren't better or worse - just different. Day-to-day, how often do sales people and engineers problem solve together?
> I notice that as I get to know someone better, I can understand our differences by understanding the ways in which we process information differently. Of course there will be exceptions, but sales people and engineers (beyond their tasks/goals being different) have different strengths and weaknesses as people and processors...]
In my small experience I actually find the "role" to be the overriding factor in determining how an individual processes information, because their "problem" defines their perspective.
> how often do sales people and engineers problem solve together?
I'm breaking definitions here a bit because in the context I am drawing upon sales are not a generic salesman, but someone who has a deep understanding of the fairly niche and complex activity the customers are doing, actually they are scientists, but not coders, so I suppose that is quite unlike the ordinary salesman to be fair ... but In this context I find that first recognising our quite different perspectives and then trying to make each other understand our different perspective allows us to extract the relevant understanding from each other to converge on a reasonable solution (or not, sometimes once you both understand the problem better from both ends you realise it's actually something else entirely, or that attempting a solution would be a fools errand).
I find this extra step invaluable because I have more empathy with the real problem using their expert knowledge of the customer and activity, and they have empathy with the potential technical challenges at hand, and as a result are more willing to accept alternatives in the knowledge of the real technical cost. I can't say how applicable it would be to collaborating with a more generic sales department though.
It doesn't really matter who instigates that mixing of perspectives, but I find as a coder I have a tendency to zoom in and out of contexts more to better understand a problem... it's not much of a step to keep zooming out / panning until you can start digging into the perspectives of your peers.
> If they're not on the same page, they make each other look worse
This is right, engineers need to understand the problems that their end users have and of those problems those that severely affect sales should be considered carefully...
however what seems to happen more often is sales or management end up dictating the solution to a problem... but software solutions are software engineers jobs.
This happens to me so commonly but thankfully I do not work in a company with a rigid hierarchy, which means rather than being forced to blindly follow a request I go and find out the context that this request originated from, understand the problem and then propose a suitable solution - everyone is _always_ happier. But this requires autonomy and respect from all members, something that rigid hierarchies appear to sometimes oppress (but then I've only ever been a lucky observer of such institutions so maybe i'm wrong).