I have been in a lot of meetings where business-types suggest all sorts of ideas. I used to get really frustrated and would take the easy way out, i.e. think to myself that these guys are clueless, why am I even in this business, and just go in a really shitty place mentally.
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.
This is great advice that took me quite a bit of time to learn as well.
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 far as I can tell everything requested can (theoretically) be done.
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.
I thought similar things, but your answer is also a parody of engineers.
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.
They will probably not believe you if you tell them a thousand times. Sometimes you have to give people what they ask for so they will realize it's not what they want.
Lines also, by definition, have no beginning or end. They're defined by a simple equation like y = mx + b. Good luck drawing one of those with any ink.
Lines, by definition, are also infinitely thin and extend infinitely far. By definition, they cannot exist in our world of atoms. :)
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.
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?"
Just to add to your response, I think absurd questions are totally OK. It's a fact of a life that non-experts will need to talk to experts, and when that inevitably happens it's best if (a) the non-experts aren't scared of asking potentially absurd questions and (b) the experts can translate their thinking into non-expert language. Both (a) and (b) are necessary for great communication.
Generally speaking, I have no problem with absurd questions. Ask away. But if you're sitting on the other side of the table just waiting to hear what you want to hear, ignoring all else, and continuing to ask the same questions, then you're not doing your part on the "great communication" thing. That's my take on what the video is trying to get across. Too bad cnet editorialized the title, and incorrectly so, IMO.
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?"
Geometry? But you can have 7 mutually perpendicular lines, even in a [7-dimensional] Euclidean space ... the ink thing is slightly misleading too, a yellowy-green will appear red under red-light. So that's doable. Just the transparency, oh and a choice of projection for the display in 2 or 3 dimensions of the lines ... ;0)
You're getting downvoted because it's pretty rude to say it out loud...
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 think it depends on how you read mikestew's comment.
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.
Your (a) and (b) do not nearly cover the scope of possibilities here. They don't even address the (more realistic) situation suggested video: You don't have to be an idiot to have a less-than-complete understanding of the technical underpinnings of a project on which you're making decisions and to make suggestions that are impossible and, potentially, quite stupid from the point of view of someone versed in the tech.
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.
Junior sales will say yes to whatever the client says they want; Junior engineer will try to implement whatever the client says they want, say no if it's impossible.
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.
That really depends on your definition of "good" in this context. I've worked in more than one place where a "good" salesperson is one that brings in the most revenue, damn the torpedoes, feature creep, impossible requirements, etc.
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.
When the type of sales person you mentioned gets promoted and valued, it's a failure of management, and will eventually lead to failure of the business (it can take a long time for the damages to surface, however).
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.
This was posted yesterday under a different URL and I penalized it. This time, I'm going to bury it as a dupe.
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.)
It's a common problem among external facing engineers. A source of great stress also. I think it is critical for engineers to discuss this topic and re-shape our view of working with the external world. We don't operate on an island and we cannot keep going for long with a condescending view of the business types without developing issues. Figuring out a mutually beneficial / acceptable operating procedure is key. The default is too negative and helps no one. With some skill, we can leverage our position, really solve big problems, and have a better working relationship. Just my 2 cents coming from b2b where my projects have 100% external impact (i.e. if we fuck up, they will have egg all over their faces - brings out the control freak in the business types).
Sure. That's why it should be discussed in the context of, say, a thoughtful article, rather than a baity video. If you'd care to post such an article, or an Ask HN, that would be much better.
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.
Thanks for offering an alternative, Dan. Not sure if it's worth the hassle. I do appreciate your effort.
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.
OP here - sorry for the dupe, I searched but didn't see it yesterday. Mostly I thought it was a funny video that the community would enjoy - hope it didn't offend!
The moment the client's request is determined to be impossible, the only problem can be communication and the engineer's assumptions must be challenged. Instead of feeling that he is an "expert," he should try to understand what the client actually wants. Instead of asking questions to point out how the client's request is wrong, he could have asked questions about how to clarify the problem -- "what purpose do the red lines serve?" "why did you choose green ink?" etc.
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.
> "what purpose do the red lines serve?" "why did you choose green ink?" etc.
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.
Good engineers should employ empathy, as long as good clients provide insight into their problem. When a client provides their vision of a finished solution, engineers become stubborn. Great engineers or clients will put much more effort into closing that gap.
Not necessarily idiots. Just those who don't know what they don't know. Knowing what you don't know (and therefore not overstepping one's bounds when making judgements) is an important thing.
I think the point is not so much about the fact that they do not have a firm understanding of the field, but that they are just blatantly ignoring the viewpoint of the Expert, who is supposed to be the authority with regards to feasibility.
I’m pretty sure most of the other comments are pointing to what I‘m going to say too, but I have to put this out of my mind.
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.
This is really, really idealistic. Most people do not have the flexibility to just up and quit, and most people in this situation do not have the influence to "destroy" a salesperson without getting fired or at least censured.
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.
I had a version of this happen to me at my first job a few months out of school. I was supposed to write code to read IMU data from a flying sensor. The sensor was giving me a stream of pitch, roll, and yaw numbers, and I had to use this information to convert sensor measurements into absolute coordinates in lat, lon, and altitude. As is so often the case, there was no documentation on the data format coming from the IMU unit. I had no idea whether the numbers were in radians, degrees, gradians, or some other weird format. I also didn't know what order the pitch, roll, and yaw transformations should be applied in.
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.
On the other side of the coin, I am not really an engineer and have worked mostly in project management or marketing, working with engineers. And I have to say, this type of thought is why everyone tended to avoid dealing with engineers as much as possible.
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.
As an engineer i tire of engineer worship. Any engineer not too full off themselves should finish the video with too conclusions perhaps unintuitive to much of the HN mass:
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.
This reminds me of trying to explain how left handed scissors function.
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.
7 parallel lines can be achieved by creating an 8-dimensional Riemann space (R8) and then drawing in it. The bill for the particle accelerator to do so is on the order of $1,250B. We'll just assume that you're OK with this and add that to the project budget -- invisible Red and Blue ink, easy. Phosphor dyed UV ink. No problem. It will perfectly meet your specification.
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.
This seems like self-serving drivel. Engineers are not Gods and non-engineers are not single-digit-IQ morons.
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.
While a little of this clip suggest idiocy - The per... per... dick... dick...
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.
Nearly all stories are deliberately unrealistic in some way. I believe the point is not to make non-engineers look like idiots but to get across to a non-technical audience why this sort of meeting is frustrating.
The reason this illustration works is because it uses concepts that everybody understands and can relate to. If a sketch showed end users asking for features that are simply not logical, but because of reasons that end users can't really understand, then only engineers can understand them, defeating the usefulness of the video in illustrating the frustration that an expert can experience.
Videos like this make me feel so much better because:
(a) I know that I'm not alone in my frustrations
(b) I realize that things could be much worse, and I should consider myself lucky they're not.
This may appear spammy, but I found Kepner Trego training[1] to really help prevent this kind of stuff from happening. The strategy is more effective when everybody in the room has had the training, which limits its usefulness with external clients, but I'll still recommend it anyway.
Granted, the video was funny because it rang true.
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.
Yea, that's fair. They could want something impossible, or they could want something possible but are describing it so imprecisely that what they end up asking for is impossible. They may not be able to tell the difference between the possible and the impossible, the tech guy can help there.
As a writer, I get to watch engineers humble themselves in advice forums when they need to write something important. It reminds me that even the mortal deities of our little civilization have shortcomings.
I think that as a metaphor, this video somewhat describes what it's like to work with somebody who is far beneath your expertise level in the same field. The obvious bikeshedding aside ("It's just 7 lines, anyone can draw that Anderson, you're an EXPERT"), working with people who haven't had the same exposure or experience to problems within your domain before might make you feel the same way Anderson's character did when he tried to explain why the task was not (in the most direct sense) possible.
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?
I was thinking god this video is boring, talking about colors and lines, how is relevant to tech, then the monstrosity of it all hits me, this is what I've been doing many many times.
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.