Then something changed. About the tens of sales books I read, a nugget from one of them struck me. The idea was to re-focus / re-frame any conversation to "what are the business objectives we are trying to achieve here?". Instead of having them propose solutions, have them dig deep into the problem and where they are trying to get as a final destination. An easy way to do this is look them in the eye, smile like John Wayne and say "I have seen this many times, it's not a problem, in fact, there are hundreds of ways we can slice this, let me ask you, what are the key business objectives here? How will we be measuring the success and failure of the project from a business point of view?" Then they really go into what their problem is, and where they are trying to go. The idea is to not propose any solutions on the spot (guess what, they don't like to hear your smarty-pants / clever solutions anyway), they would like 1) for you to play therapist in the meeting and hear every last problem, 2) come back to them at a later day and tell them that every one of their problems will be solved and the cost will be low, 3) be prepared to explain how it would work (keep high level and leave the clever bits out, but don't forget to address the impact on other resources like marketing / legal / etc.) and 4) present to them a timeline of execution mixed with approvals needed at each stage.

I have fucked up 100 times, and gotten it right about 3, thats how I know. Hope it helps some wise guy (like I was) out there.

Most of our meetings are held in a room with a whiteboard, and it has become standard to start by writing "GOAL: {{goal}}".

It prevents tangents, encourages us to use the scratching space so we can diagram the high-level components involved, and helps educate the folk who aren't up to speed (technical or business).

One example I like is that the goal of the military is peace, but the tasks to achieve that involve war and equipment. It gets real easy focusing on the tasks to the exclusion of the goal.

The other one is double entry book keeping. No one actually wants to enter information multiple times, or even once for that matter. Heck the goals for most software is to use it as little possible to get the goals met as quickly as possible.

As many commenters noted in the original discussion (https://news.ycombinator.com/item?id=7513182) if you increase the number of dimensions you can increase the number of lines that can be perpendicular to one another. How a person would "draw" in such a space is merely a question of semantics.

You can certainly draw a kitten with a line. Just not a straight line. This definitely complicates the perpendicularity requirement, but I suppose that if every line is identical (they all draw kittens), then it can be done.

Finally, color is just a question of lighting. You can draw red lines with green ink. Just draw the lines in one color setting (where the ink is green) and display the lines to the client with different lighting where the lines are red. The fact that the lines must be drawn with red, green, and transparent ink complicates the lighting setup, but it can be done.

The inflation of the red balloon should be trivial but could be delegated to a less technical member of his staff if necessary.

I certainly don't envy him the task, but Anderson should quit with the excuses and get to it.

The client almost certainly does not want a multidimensional drawing with trick lighting. Just because you _can_ engineer anything doesn't necessarily mean that its the right solution. If the client is asking for something that seems crazy, it's probably because there is a communication or information gap somewhere, not because they want something crazy.

No trouble, since they also have zero width...

When people use the word line to refer to something in the real world, there are often some unstated assumptions baked in. I guess it's important for the consultant and the client to have the same understanding of what those unstated assumptions truly are.

"...geometry."

I've had too many conversations like this, where I pause to think "where do I begin to fill the vast gaps of ignorance such that they will even begin to be properly equipped to understand the absurdity of their question?"

On two occasions [Charles Babbage] had been asked, — "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?"

To which he replied:

"I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."

(I usually remember it as "I cannot rightly comprehend the confusion that would engender such a question"; either gets the point across.)

However, I have been in a room much like that and the part of it that is indigestible are the absurd questions in the form of a demand for action, disregarding the fact that green lines are not red, for example. "So we can do this, right?"

It's a great video.

But honestly, I thought exactly the same thing. I consider myself pretty damn skilled in the areas where I focus, but in all others you could drive a Mack truck through the gaps in my knowledge.

In any kind of fruitful working relationship, I'm expecting to be both on the giving and receiving end of those conversations more than occasionally... otherwise, what's the point of even collaborating?

Either OP is a) working with idiots (in which case, quit yesterday), or b) he's not valuing the skills they're bringing to the table.

If they are ostensibly in the same role as him and should know better, see (a).

I am a physicist and I can relate to his experience. Sometimes friends/family will ask me absurd, ignorant questions and I have to pause to figure out how to answer them. But just because the questions are absurd or ignorant doesn't mean I disrespect the questioner or their other areas of competency. I think it's awesome when people have the curiosity and the confidence to ask questions that risk being ill-posed.

Taken at face value, mikestew's comment seems fine to me. I guess it depends on how much disdain you read into his usage of 'absurd' and 'ignorant'. Perhaps he meant them literally, with no connotation implied. I guess only he knows. And when the OP's intentions are not clear, it's probably not best to respond with a rude remark.

You also don't need to be undervaluing someone's skill set to see their lack of understanding of a project's limitations and requirements as a detriment and impediment to your progress; it is, and acknowledging it as such does not require being a jerk, nor does it necessarily make you a jerk.

If you're saying "man, what an idiot you are" to people who suggest things that aren't possible, feasible, or sensible, then yeah, you probably have some growing up to do (of course, most of us do anyway). But that's not the same as addressing someone else's very real problem before it makes your responsibilities intractable.

No, it was downvoted as a rude personal remark, and rightly so. That's just what downvotes are for.

There are countless appropriate ways to raise any genuine concern.

Sweet irony.

Senior sales will try to figure out the real reason of a client's request, and sell them a solution that solves their real problem; Senior engineer will try to figure out the real reason of a client's request, and propose a solution that solves their real problem.

A sales person and an engineer may start from opposite directions, but really good ones think the same.

Sales and engineering have fundamentally different objectives: Sales needs to generate revenue, engineering needs to create a project that satisfies a specification (ideally). There is very obviously overlap and hopefully interplay there, but I don't agree that people who are good at those largely disparate things necessarily think in any particular way, and certainly not the same way.

In most, if not all industries, reputation of a company matters a lot. That's how you get repeat and referral business, the lifeblood of a mature business.

Because it is designed to elicit controversy (and views) rather than insight, it is not good material for HN.

We can have a discussion about communication between engineers and others. I'd have a lot to say about that myself. But priming everyone for indignation ("surrounded by idiots") is exactly the wrong way to start it.

Pandering to engineers who think they are "surrounded by idiots" is not seeking to get at the truth. It's an appeal to pre-existing opinion, i.e. prejudice. Worse, it's a sneaky way to promote tribalism while pretending to promote the opposite (tolerance). HN stands for the opposite of all these things.

(Side note: when I say "bury", I'm using a technical term from our code. It means applying a rank penalty, but leaving the item open rather than killing it, so anyone who wants to can continue the discussion.)

Edit: None of what I said applies to your comment, though. How about this? Post it as an Ask HN with a good title. I'll put the link in my comment at the top of this page, we can ask rogerbinns and hurtmykneee to migrate their replies over, and have a substantive discussion.

I would like to point out that the baity video is satirized commentary on many enterprise cultures. Though the presentation layer is light, the content is heavy; thus spawning discourse.

Thought that you copyright lovers ought to know this.

I'm always trying to get my internal stakeholders to NOT describe what they think the end result should look like, but to describe WHY they want it, what they want to accomplish, and let me help figure out what the end result should look like to accomplish that.

I'm not saying it's easy.

Our market research and focus groups have shown that these are the best specifications for our product line. They will improve sales and reach a wider audience. The transparency will especially give us a competitive advantage in the emerging 7 line market.

This video, while hilarious, puts the ‘expert’ not in a good light. It is in fact true that the ‘customer’ is talking completely nonsense, but it’s not her fault. Most time you’ll be dealing with something which 1) has been put there or 2) has a focus on something else and you‘re are the only ‘tool’ to accomplish her goal.

The question is: what’s our goal? Engineering for the engineering’s sake? This is a goal that IMHO must be present in every engineer, this makes us mutate from tools to artists (personally I think that if something happens for its own sake, then that’s art) But this must (IMHO) not be the only one. What we really need as a goal is something anthropocentric: make someone else happy (happier).

The real problem here is not in the customer, but in the ‘expert’. If you really want to have that ‘expert hat’ what you really need to do is understand the very person you have in front, and her needs. Only then you can start talking about ‘technologies’.

The problem with this video is that the customer is asking for something to be done, and the ‘expert/sales-men’ team responds with “hows”, this moves the conversation in the wrong direction.

- “We need you [...] to draw 7 perpendicular lines” - “Could you please explain better what was the process that brought you here?”

If the sales-man stops you because this kind of questions is ‘out of scope’ of the meeting, ask him out, and destroy him to the very last piece of him: he must let you do your job (understand the customer’s needs and take them from want-space to real-space), his job is ensuring that from a sales and customer relation point of view you‘re not ruining your own company strategic plans. Is he also the project manager? Then try to make him reason. He doesn’t? Quit. Now.

wooosh. I had to say it. sorry.

It sounds like either you've never been in a situation like this or you should back up a bit and take it in at a higher level; you're missing the forest for the trees. You're assuming the client contact you have even knows "the process that brought [them] here," which they often don't, and that they are going to be interested in discussing it with you, which they often aren't, among other things.

This conversation is also more often, in my experience, one step removed: Rarely have I seen this actually happen with a technical implementation person in the room. More typically it's a salesperson and a project manager, and you just get marching orders after the fact, which may or may not make sense depending on the PM's ability and willingness to make sense of the client's requirements.

Shut up, you fool, it's what the client's asking for. Get them to add a few more lines and then order coffee.

So in a team meeting I asked about the transformation order. Now, pitch, roll, and yaw transformations are not commutative. For the small angles that you're likely to see in typical flight, they're almost commutative, but of course we were trying to do better than "almost". But when I asked about the transformation order, someone answered that it didn't matter. These were actually some technical people who answered, so it wasn't even management talking ignorantly. I politely said that it's a mathematical fact that order does matter when applying pitch, roll, and yaw transformations. The guy responds, "Oh no, the IMU measurements represent a snapshot in time." I responded that in that case, the numbers carry with them an implied transformation order, and that I need to know what it is in order to write my software correctly. "No, I'm pretty sure it doesn't matter," he said. Now I'm getting desperate, so I bust out with the hand demonstrations. "Start here, pitch up 90 degrees, then yaw right 90 degrees. Now compare that to yaw right 90 degrees, then pitch up 90 degrees. See? We started from the same orientation, but we get different results." These guys weren't having any of it. They insisted that it didn't matter, so I dropped the issue. Later I brought it up again at another meeting and a PhD who wasn't in the first meeting says, "Oh, I know what you're talking about." Ahhhh, finally, vindication.

That didn't even help me all that much though, because nobody seemed to have information about the actual ordering. I think in the end I had to reverse engineer it by brute forcing every possible combination of units and orderings until I found one that made the data look right. And oh by the way, the units weren't in degrees, radians, OR gradians. They were in units of semicircles, where 1 = 180 degrees.

There is quite often this mindset of superiority amongst the engineering community and it only serves to isolate them further. Engineers aren't all knowing, and everyone else aren't brainless morons. While engineers might know engineering, the marketers know marketing, the salesman know sales, the financiers know financing and so on. It takes great collaboration among everyone to make a truly great product and to have it really make an impact.

So, please, if you can, avoid this "surrounded by idiots" type of thinking. Everyone is working towards a common goal, and the sooner we realize that we aren't better than anyone else, the sooner we can achieve our goals.

1. I could actually fulfil the letter of the request provided I can use 2 red lines, 2 green lines and 2 transparent lines. Or I could modify the request slightly in various ways to also provide much of the requirements.

2. damn if it was not for the stupid sales people I probably would not have even thought of these solutions.

Non-techs are there to force you to think outside of your own damn box. Too many engineers assume that people talking to them should understand why something wont work, before they take the time to see how it could work differently then even they would have initially thought. Even fewer have the wits to give credit to the collaborative process that brings these less that intuitive solutions to light.

Go find and read the circa 1700 essay https://en.wikipedia.org/wiki/Heinrich_von_Kleist#On_the_Gra...

Give 'em a piece of paper with a straight line down the middle and a pair of right handed scissors, then instruct them to cut accurately along the line using their left hand. Afterwards ask them why they are holding the scissors on the right hand side of their body.

If you want the visualization and detailed description of the solution, we can engage Rand Corp for a nice slick to show you how this will work. It'll be about 1250 pages, and we can add this to the budget for a little over $400M.

--

If there's any lesson to take from this... When confronted by people who don't understand the scope of the problem -- don't communicate the problems OF the problem. Communicate the actual scope of the solution. It will tend to focus the dicscussion rather rapidly.

The tasks set is of course impossible by definition - which is not the case in the real world where most projects are doomed by human factors, lack of trust and will rarely if ever be rescued by one guy standing up and saying "No you are all wrong now listen to me and I will tell you why this cannot happen".

Humans work emotionally and love stories - if we want to succeed and still fulfill out inner Maker then instead of No you can't do it, please try "Instead of red lines why don't we sell pencils to enable our customers to draw their own lines. What's the best ad campaign we can imagine for a pencil case aimed at the blue collar market?"

Everyone else is not an idiot, is probably the best and most useful thing to take away from this.

This video is actually more about the human factors in communication. The "you do know what translucent means" is an example of speech that is VERY absolute and inflammatory. The sales and PM are very agreeable to the client and distrusting of the engineer - very often putting the burden of his "being the expert" against him in the conversation.

TL;DR: It's just a metaphor.

1. http://www.kepner-tregoe.com/pdfs/pubworkbro/psdmbroch06-07....

I've also been in meetings where the expert was wrong.

Still, I suspect it's not just engineers. The same thing can happen to any expert in a subject where things can be true or false. For instance, it could be a legal or financial expert being asked to approve something that's illegal.

Source: Veteran software engineer.

I assume this probably goes both ways. In the eyes of an expert, they'll probably have difficulties or at the very least get frustrated that people are making judgment calls when they're obviously wrong. On the other end, non-experts might actually feel frustrated feeling that the expert doesn't know what they're talking about, when task X is so obviously a possibility and they're just viewing the world inside their own tiny box. From both sides, they lack/forget/have lost the context to see the other sides' perspective. It's not so much that haughty managers and salespeople are too quick to say 'yes' all the time, but rather that what's obvious to you is clearly not 'obvious' or may not even register within their perception of the world. Ultimately, the root cause of the problem here is that there are unspoken assumptions, and neither party is willing to communicate what those are.

Take for example, the assumption that "you're an expert." In reality, you may be the best in your field, or at the very least you might be well-versed in it, but an expert in astrophysics isn't going to fare well in a discussion about civil engineering. In the same way, there are people who make the assumption that there is no distinction between engineers, and that electrical engineers are the same as geomatics engineers are the same as chemical engineers. While the specific field of engineering may be different, small assumptions that go un-communicated like this are how these sorts of problems start.

That said, even communicating these assumptions to others may not solve the problem. In my own experience, I've had problems getting team members up to speed, if only because there's no hard and fast way to do so. As an example, when working on a Javascript project with a partner once, my team member kept complaining that they didn't "get" how to write code in Javascript, despite having gone through the same education (same degree/program) that I did. Certainly I had more experience with the language than they had, but I was confused as to why they would find the language hard. To give some context as to why I couldn't understand why my team member was suffering, we take courses in programming with C++ / MATLAB in our first few years within our degree. Furthermore, I had sent multiple links to courses such as CodeAcademy, and many others, which I had assumed would have given my partner the information necessary to transfer their skills to the constructs of the new language.

Unfortunately, it didn't work out as I had expected. They continued to struggle with Javascript, for reasons beyond my understanding. The intent to learn was there, but for some reason there was no way to explain the language in a commutable way to them. And here's where I noticed the problem of being an "expert" who's "surrounded by idiots": I couldn't get figure out why someone who had the same basic training/purported skills as me couldn't manage something as simple as learning a new programming language. At the end of the day, there was definitely a communication barrier, but the "unspoken assumptions" I spoke of before didn't even help alleviate that once they were revealed. I guess in this case, once I had set that barrier, it wasn't coming undone. The attitude that "this is too hard" or "I can't do this" had already set in, so there was little left I could do about it. Even attempting to help teach after the fact was only met with disdain and harsh attitudes.

If anyone else has some tips for dealing with this sort of behaviour / attitude / whatever in the workplace, I'd love to hear them. Too often am I approached by a colleague who tries to convince me of the impossibility (or possibility, in the case of the video) of some task that is not such. What do you do when you're the expert and you can't get people to work up to the level you're on, and what do you do when you're the non-expert and feel like the level you need to work up to is impossible?