There are a couple versions of the joke floating around, but I’ll use the one I found here:
A man in a hot air balloon realized he was lost. He reduced altitude and spotted a man below. He descended a bit more and shouted,
“Excuse me, can you help me? I promised a friend I would meet him an hour ago, but I don’t know where I am.”
The man below replied, “You are in a hot air balloon hovering approximately 30 feet above the ground. You are between 40 and 41 degrees north latitude and between 59 and 60 degrees west longitude.”
“You must be an engineer,” said the balloonist.
“I am,” replied the man, “How did you know?”
“Well,” answered the balloonist, “everything you told me is technically correct, but I have no idea what to make of your information, and the fact is I am still lost. Frankly, you’ve not been much help so far.”
The man below responded, “You must be a manager.”
“I am,” replied the balloonist, “but how did you know.”
“Well,” said the man, “you don’t know where you are or where you are going. You have risen to where you are due to a large quantity of hot air. You made a promise that you have no idea how to keep, and you expect me to solve your problem. The fact is, you are in exactly the same position you were in before we met, but now, somehow, it’s my fault.”
It’s always good for a chuckle in engineering circles.
A Good Lesson
I first heard this joke in college, and I’ve thought about it a lot over the years (particularly when I’ve found myself working for someone who had no idea what they were doing). Having worked in a support role for the past few years though, I have a slightly different take on it.
Engineers have particular ways of thinking about problems, and as they develop their skills, they learn to communicate with other engineers using an austere parlance. Words are chosen for specificity and with the intent of delivering solely the information that another engineer would need to understand and solve the problem.
Another way to frame this is that engineers tend to speak a meta language that is understood only by other engineers. I don’t necessarily mean with acronyms and esoteric vocabularies (although that is common). I mean there is a tendency to interpret problems and solutions in very narrow ways unfamiliar to non-engineers. You’re speaking the same language, but not.
I know in my own life this has happened and annoyed the crap out of someone. Maybe a friend or family member will ask me why their “Smart TV” is constantly buffering and crashing when streaming Netflix or Hulu. If I’m in “engineer mode,” I’ll interpret the problem narrowly and I might say something about embedded devices often not having the capacity to perform the tasks the system is demanding on it.
Another engineer understands this to mean they should probably get a dedicated streaming unit like a Roku or AppleTV. The layperson doesn’t make the connection. To them, they asked a question about one subject and got an unrelated answer.
That’s because to the user, the root cause of the unit buffering and crashing isn’t really what they care about. They care about sitting down with a loved one to watch a movie without interruption. The interruption is occurring, and they’re mad. The root cause could be quantum tunneling, solar flares or magic beans for all they care. Hearing some jargon about resource contention doesn’t make the problem go away or point to a solution.
Protip: if your support isn’t actionable in some way, it’s worthless. There’s a world of difference between “you’re doing it wrong,” and “try this instead.”
In the joke, the manager suggests the engineer can help by telling him where he is. But what the manager really wants to know is the fastest way to arrive at his destination. Instead the engineer interprets the question literally and narrowly, and responds with a geographic coordinate. This is exactly the miscommunication I’m talking about.
Too often customers and support staff have this kind of “balloonist and engineer” relationship. When a customer asks for support, it’s important to remember that the root cause is never the real issue: it’s where the product falls in the customer’s bigger picture. Quality support addresses the big picture by drawing connections to the subtle details.
A Much Less Funny Version
In practice, whenever I’m working with a customer to resolve a problem, I try and understand what they actually care about before diving into an answer. Often it’s important to share the root cause, but I like to do this in a way that ties it in to the problem they care about. Then I’ll offer something actionable. And I’ll do it all with as much empathy as I can muster.
If I had been the engineer in the joke, it would have looked something like this:
“Excuse me, can you help me? I promised a friend I would meet him an hour ago, but I don’t know where I am.”
“Oh no! That sounds really stressful. We’ll figure this out. Where did you plan to meet him?”
“Yes, thanks, I’m very stressed. I’m supposed to meet him in the tavern in Pigsford.”
“Oh, that helps! So right now you are between 40 and 41 degrees north latitude and between 59 and 60 degrees west longitude. Pigsford is about 20 miles directly south of us. The wind looks to be from the northeast, so it should give you a bit of a boost. Travel with the sun to your right and you’ll hit Pigford in 10 minutes.”
“Thanks!”
At this point it’s not so much a joke as it is a really boring anecdote. But it’s how great support is done.