"one of the biggest mistakes “nontechnical” people make when communicating to great hackers about product is that we try and tell them the solutions before we ever tell them the problem"
This is spot on.
I spend a bunch of my time helping ux, business and dev folk play nice together. This is definitely one of the major problems and something I babble on about to tedious extremes.
It's usually not as simple as a lack of trust though. It's more often things like people not having good ways to communicate the problem (as opposed to possible solutions). Or organisations being set up in such a way that the technical folk aren't in-play at the point where problem discovery is happening. Or the non-technical folk being assessed on "solution providing" not "problem defining".... and so on.
Trust is sometimes an issue - but it's often not the major cause.
(There is also a class of tech folk in some organisations who aren't interested in that level of problem - who want to get "the spec" and focus on the implementation problems that interest them more.... but I don't think this is the kind of tech folk the OP is talking about).
> Or organisations being set up in such a way that the technical folk aren't in-play at the point where problem discovery is happening. Or the non-technical folk being assessed on "solution providing" not "problem defining".... and so on
This is the fundamental problem and is, I think, largely due to the fact that the kinds of problems we are solving do not naturally fall into the neat specialties into which most companies categorize their workers. Specialization promotes serial thinking whereas what's needed is near simultaneous thinking and that requires deep communication (and smart people)
This is spot on.
I spend a bunch of my time helping ux, business and dev folk play nice together. This is definitely one of the major problems and something I babble on about to tedious extremes.
It's usually not as simple as a lack of trust though. It's more often things like people not having good ways to communicate the problem (as opposed to possible solutions). Or organisations being set up in such a way that the technical folk aren't in-play at the point where problem discovery is happening. Or the non-technical folk being assessed on "solution providing" not "problem defining".... and so on.
Trust is sometimes an issue - but it's often not the major cause.
(There is also a class of tech folk in some organisations who aren't interested in that level of problem - who want to get "the spec" and focus on the implementation problems that interest them more.... but I don't think this is the kind of tech folk the OP is talking about).