How do you tell a non-technical person that they can’t understand?
blog.asmartbear.com
blog.asmartbear.com
This is unbelievably presumptuous, narcissistic and smacks of technological elitism. You don't know whether or not the client can understand -- all you know is you're unwilling to explain it to him.
If you don't want to get along with clients, if you're willing to take the risk of alienating them, take this article's advice and tell your customers, "You can't do that, and you also can't understand why -- trust me."
If you do want to get along with your clients as well as grow your business, try this instead: "Well, our system can't do that at the moment, but I appreciate your making this suggestion for future improvements."
Maybe it's a polite lie -- so what? You've empowered the client, made him feel as though you care about his needs. You've avoided opening an emotional exit door the client my well choose to walk through.
> "It’s not that the customer is “stupid,” nor that given enough time, training, and explanation, couldn’t eventually understand it all fully. But sometimes the customer just has to trust the vendor."
If the vendor cant explain a problem / solution, i would have a lot of trouble trusting that they have a true grasp of the actual problem.
>In every period of history, there seem to have been labels that got applied to statements to shoot them down before anyone had a chance to ask if they were true or not. "Blasphemy", "sacrilege", and "heresy" were such labels for a good part of western history, as in more recent times "indecent", "improper", and "unamerican" have been. (From what you can't say).
Mayhaps you can apply those labels, but you skipped the crucial part -- is it true?
> Mayhaps you can apply those labels, but you skipped the crucial part -- is it true?
As to "presumptuous", the author assumes a priori that the client can't understand an issue, not doesn't understand it but might comprehend an offered explanation. That's how presumption is defined -- an assumption in advance of any effort to gather facts.
As to "narcissistic", well, yes, absolutely. The author places himself and his peers in an elite, entitled group, qualified to gauge the limited understanding of lesser beings and pass judgment on them, rather than try to explain something that might help his clients and his business.
As to "elitism", yes again -- the author sees himself and his associates as belonging to an anointed, superior technological priesthood, able to say to the unwashed masses "trust me" with a straight face.
Any questions?
Is the original statement true?
You don't. You explain by analogy.
If you can't come up with a good analogy, it's probably for one of two reasons: Perhaps you don't really understand it all that well yourself, in which case you should find somebody who understands it better to do the explaining. Or perhaps you just have a hard time coming up with analogies in general, in which case you should find someone with better communication skills to do the explaining.
Of course, sometimes your software is just mired in the legacies of bad decisions past, and it really is useless to explain (all you're doing is trying to communicate what "spaghetti code" means), because nobody is going to come out more enlightened on either side.
Also, sometimes tech people are pretty ignorant too - I had to explain what a hash table was to my project manager once.
You win if your listener calls BS. I win if they don't.
You're probably not explaining anywhere near as much as you think. You're just making soothing noises until they are no longer willing to pursue the matter. You might as well be honest about that fact with both yourself and the client, as suggested in the blog post.
That is obviously true. But it's also obviously nowhere close to being an appropriate (or even smart) way to conduct one's business relationships.
A good analogy is asking about the business relationship between a parishioner and a priest. Its the wrong tinted glasses to look at the relationship. That doesn't mean it has to be a bad relationship, and no value judgement of inferiority. Its just evaluating the relationship via inappropriate criteria.
These people act dumber than they are, so they can extract more information with which to evaluate your character and disposition.
Its possible some of the confusion is state based vs action based. If you define business relationship by state, then absolutely anything that happens in a cube farm while wearing a tie is a business relationship, from a free market to blackmail to slavery to blind faith. If you define business relationship by action as a theoretical ideal of how roughly equal participants in a competitive market in a rule of law system treat each other, you get a completely different analysis.
Mapping understanding from what someone does understand, to something they don't understand, is a problem in topology. Many times, if there is enough time to go through it, you can find that path for most people.
Where it breaks down is when you are dealing with people who have never learned to think critically or who are unable to reason about things they haven't personally experienced.
I appreciate the WPEngine guys who have been helping my sister with her Blog, she is smart, but not technical. Generally it just means that having her understand what is supported directly by the software and what isn't is more time consuming but ultimately possible.
If the someone has enough raw mental horsepower and an infinite supply of spare time... Let me teach you everything I know about electrical engineering, it'll only take 10 to 20 years of your time assuming you're smart enough to keep up.
Also note that its quite possible to get stuck unable to explain something to someone smarter than you, if you have an inherent talent and or huge experience that results in talent far beyond what your horsepower "should" produce. So both sides the student and teacher have sort of a "must be this smart to enter" carnival ride requirement.
Pretty much anything I can think of, as long as you're willing to spend five to ten minutes on explaining it, can be discussed with a person without the same background. That isn't to say at the end they could or should be expected to be able to build a bridge safely, but at least the can understand why it's costing them so much.
It would appear the main point of the discussion was how to deal with my definition rather than your definition...
In cases where people are lacking fundamental concepts, the only path to understanding is an inordinate investment in education, adding that concept to their repertoire. It can be done but it is not a small hurdle.
I will also note that more often than not the purpose of analogies is to convince the audience that they understand a technical subject matter even when they do not. It is a mechanism for creating agreement rather than understanding in many cases.
One of the comments nails it best: unless you are breaking the laws of physics, you can make software do pretty much anything... the real question is whether that is a net benefit.
"They want to use our software or customize things in ways that are technically impossible"
What the hell does that even mean? Perhaps the reason the tech can't communicate to the non-techy is that he can't communicate, period. Does it mean they're using the software for something it wasn't intended to be used for? Are they looking for a feature that isn't coded? Are they looking for support for something you aren't interested in supporting?
Not much is 'technically impossible' when it comes to businesses and software these days. What there are in abundance however are a lot of misguided applications.
Lack of communications ability could be an issue. Oh you didn't REALLY mean everyone's computer in the world you just meant in this office. Oh you mean the top adwords link on google not search results. Well...
"They want to use our software or customize things in ways that are technically impossible"
Try doing IP multicast on the public Internet.
What, you can't, because the ISPs have disabled it?
Next time try not talking out of your ass.
It's not like you _have_ to use IP multicast to solve certain classes of broadcasting problems, it's just more helpful.
Then why did NATO get their own dedicated lines to multicast on? Why don't they run their 100,000 simultaneous user systems without multicast and save that expense?
But OK, we'll pretend you're right about that one. What if someone asks for a job shop scheduler for predictably giving optimal schedules for 300 machines interactively? NP completeness is no problem, right?
Or what if someone asks for an in software modulator for the entire radio spectrum? The non-existence of the necessary hardware is again no problem, right?
Or how about when users asks for just plain contradictory requirements huh? Never happened to you? Because these ones are not just physically impossible but also logically impossible.
The fact is that some things are constrained by engineering. It is also a fact that some non-technical types in positions of authority push back when told "no" because of technical constraints, and ask "Why not?". Attempting to give them a reason is a trap, because they are asking the question as an opening negotiating ploy.
Because these idiots in their ignorance think an engineering constraint is a negotiable item.
I feel very sorry for the engineer in the original post because it sounds like he's stuck in such a rut.
And it's simply infuriating to hear somebody respond to that plight with the nonsense that "in IT anything is possible".
Engineer: "What phone do you use to call him back on?"
Customer; "The one on my desk."
Customer has a desk phone attached to a Northern Telecom PBX switch that was installed by a VAR (now out of business) but is still maintained by the property owner using a Win95 based laptop.
Generally the phrase "technically impossible" relates to a situation where a customer is asking for a capability which, to implement, requires either that they change their process, or co-operation by a third party. Often times the 'third parties' here are old school, highly invested in walling off their garden types, like AT&T. Often, telling the customer they have to change their processes to achieve what they want is a 'non-starter.' It can be a very frustrating experience.
Most old stuff like that had a CDR call detail record serial port intended to feed a line printer. The simplest way might be run a serial connection to the CDR.
It may very well come down to the simplest way to do it is install another phone on the guy's desk. Forward his old extension to his new phone and new phone line. If your PBX vendor isn't willing to discuss simply forwarding a number then you've got serious vendor issues... thats not asking for much...
"Bugs" are just differences between expected and actual behavior. There is no definitive "right" or "wrong". There is only a matter of correct interpretation.
What you are essentially asking for is for me to eliminate the need for not only your program, but the user using it. That's far from technically impossible; whole industries are built on that idea.
Good god this is bad advice, especially in the US which is nowhere near the top in world rankings for quantitative medical performance like longevity or infant mortality.
The first thing you do is get multiple opinions. Without any further info, you have a 25% chance that you are relying on some clown who was in the bottom 25% of his class. I swear many of those guys are just throwing around treatments to collect $$.
Please tell me this is a joke.
How did you think the USA manages to have simultaneously the most expensive and least efficacious health care in the first world?
I really can't do a good job, any job, of explaining magnetic force in terms of something else you're more familiar with, because I don't understand it in terms of anything else that you're more familiar with.
Transcript: http://lesswrong.com/lw/99c/transcript_richard_feynman_on_wh... Video: http://www.youtube.com/watch?v=wMFPe-DwULM
If you can't simplify or analogize enough to explain something technical, you don't understand it well enough yourself.
Sometimes I'll tell people "It's kind of abstract and will take a while to explain. Do you still care?"
"Will I be able to do X?"
"No, because that's technically impossible." or
"No, our product doesn't support that feature yet." or
"Well, you could, but it's not a documented feature, and you risk losing everything you did during next upgrade." or
"Yes, but it will take several more months of development and associated cost."
Generally, the asker will be satisfied at this point, because now they understand enough of the problem to make an informed decision.
If you can't find a solution, change the problem.
I have had great success in re-working the requirement when something seemingly impossible has been proposed by a user. IMHO, this is because what makes something impossible is usually an additional (and often negotiable) requirement.
Sure there are still times when this won't work either, but it should help reduce that number.
Otherwise, they're still just going to have to trust the doctor.
> ...how do I basically tell [the customer] “You can’t understand this. You have to trust me” without sounding like a prick?
The post concludes with "you have to tell the customer to trust you".