> How do you tell a non-technical person that they can’t understand?
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.
>This is unbelievably presumptuous, narcissistic and smacks of technological elitism
>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?
>> This is unbelievably presumptuous, narcissistic and smacks of technological elitism
> 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.
How do you tell a non-technical person that they can’t understand?
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.
Now, try an experiment next you do that. Explain by a completely inapplicable analogy, one that is logically coherent but does not apply to the problem at hand.
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.
All you're really demonstrating by that thought experiment is that when there's a huge knowledge gap, the more knowledgeable person is well-positioned to get away with spewing a whole mess of BS.
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.
You do not have a "business relationship" if there is a huge knowledge gap. If there's no meeting of the minds, no way to evaluate each other, no way to sensibly compete in a free market, you're well along the path of a provider/consumer relationship or pure faith or at best something like feudalism or lifetime sharecropping.
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.
Tread lightly, this attitude is dangerous. There are really customers/managers who are not technical that instead rely on your previous words and commitments to gauge what's possible and what is getting done.
These people act dumber than they are, so they can extract more information with which to evaluate your character and disposition.
Again, that's not a business relationship, that is quite literally exactly how feudalism worked. Your liege lord was not an expert on your plot of lands agronomy prospects or the physical state of your knights, so he had to trust you.
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.
Explaining technical stuff to non-technical people is a skill or a talent like any other. Tim Hunkin, Carl Sagan, and James Burke are all great 'explainers.' It helps they have a wide body of experience across a lot of different fields which gives them a lot of material to draw on.
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.
Not everything is explainable by analogy. Analogy maps an abstract concept from a domain a person is familiar with to a domain with which they are not. However, for a number of technical areas many non-technical individuals completely lack familiarity with the fundamental concepts in any domain, and in some cases have intuitive beliefs that are inconsistent with these concepts. In these cases, no useful analogy can be constructed because nothing analogous exists in that person's understanding of the world.
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.
Agreed. It just takes time to explain how any computer system works (at least at a high level). One of my friends asked me once "what is code?" after I came home from work - I spent two hours talking with him, and at the end he had a rudimentary understanding of how source code, compilers, operating systems, and graphical user interfaces work. He made a reference to compilers months later that showed he remembered and understood.
Also, sometimes tech people are pretty ignorant too - I had to explain what a hash table was to my project manager once.
I agree. And you, on the software side, will often be surprised that you "don't understand" what the user wants or needs in an equivalent way.
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.
This completely. If you cannot explain something to someone else whom has no innate knowledge of the subject, using plain language, then your command of the subject is questionable at best. True command of a subject in my opinion contains within it the ability to relay what you know and make it understood.
"If you cannot explain something to someone else whom has no innate knowledge of the subject, using plain language"
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.
I disagree. I never said anything about teaching everything you know. I can explain to someone why a certain metal in a product is better than a less expensive metal without getting into advanced materials science/crystal theory yet not use hand-wavy 'You wouldn't understand' language or mentality.
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.
I will concede that we both appear to agree that if you define "something" as "something very common and simple" then you win and if we define "something" as "something very complicated" then I win.
It would appear the main point of the discussion was how to deal with my definition rather than your definition...
I would love to know the specifics behind this post, because it seems so very, very, wrong.
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.
"They want to use our software or customize things in ways that are technically impossible"
Maybe there is an unspoken " for the price they are will to pay" component to that statement. I have told customers before that given time, money, and hardware I can do almost anything they want. The real question is are they willing to pay for that time, and hardware to do what they are asking.
There are countless examples of "technically impossible" requests on the daily wtf and clients from hell. A good example is when the client wants you (or your software) to do something that involves access to other companies' infrastructure or to every computer in the world. For example, "make our website the default homepage for everyone." or "remove our competitors' links on Google."
Your examples sound rather easy, relatively speaking, to accomplish technically, but are certainly legally dubious. In fact, it seems most things that are "technically impossible" come down to social issues and not technical issues at all.
Technically and legally / morally acceptable and simple. The financial cost however would be unimaginably spectacular. Simply buy your competitors and shut them down, and create a simple 1e8 price range deal with some well known browser devs to make your page the home page.
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...
Customer: "When I call a customer back I want my blog to mark his comment 'handled' with the date and time."
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.
Old time telco guy here. That's not even technically challenging much less impossible. I can do that for $50K to $75K of hardware worst case. If the trunks are ISDN PRIs just sniff the D channel(s) using a protocol analyzer, all off the shelf stuff, and watch for certain numbers, either his desk DID or an outgoing call to a customer with a currently open blog. Somewhat more old school stuff E/M or groundstart might be cheaper than a ISDN protocol analyzer. Something that old is not using VOIP which is too bad as a sniffer would be pretty cheap for SIP.
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...
My pick is that the customer is a moderate sized radiology department using FileMaker as a RIS, and they have asked the engineer to make it talk to a PACS, booking system, distribution system, CT, MRI, PET, x-ray, US etc (all made by different manufacturers), and the engineer is at his wits end. Maybe I see things through work-tinted-glasses.
"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.
Using IP multicast is a solution to a problem; and I'm pretty sure the parent comment meant that he could solve any problem given enough time, money, and resources.
It's not like you _have_ to use IP multicast to solve certain classes of broadcasting problems, it's just more helpful.
"It's not like you _have_ to use IP multicast to solve certain classes of broadcasting problems"
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".
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 $$.
Agreed. And contrary to what the OP said, it is entirely possible to educate oneself about a specific medical condition, given only some basic knowledge about biology and biochemistry. There are plenty of resources out there. Coming up with possible alternative diagnoses for one's symptoms is a bit harder -- that's really what you're relying on the doctor's expertise for -- but even that can be done.
Well, of course they are. You have an insurance based health system. Every time you go to your doctor they order every possible test so they can claim it, plus their mark up, against your insurance.
How did you think the USA manages to have simultaneously the most expensive and least efficacious health care in the first world?
It's a dangerous habit to call or think of anyone as "a non-technical person". Life is not binary; people do not come in discrete categories; these are merely labels we impose on ourselves and others, and once you stick a label on someone it's hard to see them otherwise. You're bound to the judgement you've made and will tend to block out any information that contradicts it – such as the fact that they can understand things, if clearly communicated.
This reminds me of Richard Feynman answering a question about magnets.
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.
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.
I deny the premise of the OP's doctor analogy. Given a rare liver disease, and the amount of information available on the internet, and access to doctors to ask questions to, a motivated learner could become quite proficient in understanding how the liver works and how it is affected by a specific disease. The patient does not have to become a doctor to do this. A doctor has to learn many, many things to become a doctor. Whereas the liver disease sufferer only has to learn about one thing. It is easily possible for a lay person to learn enough about their condition to have a meaningful "technical" conversation about it with their doctor.
That would only work if the learner is so motivated that they spend months poring over medical and biology textbooks to understand enough background, and then learn how to read scientific papers and interpret studies for statistical significance, to get up to date on the latest research. And of course they also must have the aptitude to do all that, to get to the point where they can start meaningfully questioning the doctor's recommended course of action.
Otherwise, they're still just going to have to trust the doctor.
You don't. You start by explaining from a high level, working your way down to lower levels as requested until the client comes to their own conclusion that they can't understand. This takes longer, but keeps you from being the bad guy.
The best approach that I have found, at least when making websites or creating a CMS, is to really dumb it down. Don't think about how you would like it to be, because it will almost always be too complex. Beyond making software super intuitive, make sure it's extensible enough to adapt to customer needs. Pretty much anything is possible but if your client is consistently asking for stupid things then I think it's time to find a new client.
The key failure of this post is that it uses the wrong analogy. You may want your client to think of you as a doctor, but right now they think of you as a magician.
The premise is predictably arrogant and self-serving. It simply means that YOU lack the intellectual capacity, emotional intelligence, and command of language to produce a coherent explanation for that person. IOW - it's YOUR failure, NOT THEIR'S.
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.