Hacker News Reader

Comment by sikhnerd | Hacker News Reader

I think the best way I've found to combat these types of meetings and cut through the talk is simply to ask "Why"

Find out pretty quickly (generally) what they are actually wanting and nobody needs to print things in transparent ink... (usually)

View on HN

"Why", or "what do you want to do" are two of the most useful questions in my arsenal. Often a client (or user you're trying to assist) is 2-3 steps past their initial requirement when they ask for some technical solution. Backtracking to the base problem often suggests a far more useful and viable approach.

The video sketch shown here isn't so much an illustration of what it's like to be the only technical person in a meeting as it is one of what happens when you put technical and nontechnical types together with no way of establishing a common language and understanding. The project leads and/or engineer are incompetent.

I agree completely. And here is the crazy part, if you smile, and appear friendly without looking weak, people will be more willing to follow you down your line of questions to the beginning, to their own base problem. So things like the body language you use when you enter the room may be the difference between learning the real problem or not, and thus delivering a great product or not.

Myself, I generally have to make conscious decisions to do all these things.

This is true for any meeting where a specialist is outnumbered and the other folks have already made up their mind.

You can't avoid the initial state problem.

What you can do is recognize and either 1) correct it or 2) realize you're working with incompetents (e.g., everyone in the video sketch, engineer included).

I'm starting to see a lot of similarities between managers/executives and beginners asking questions in programming IRC channels...

Agreed. Many times when you are approached with nonsensical requirements it is wise to try to figure out what problem the asker is trying to solve. This is doubly true when you receive technical requirements from non-technical people.

Don't just ask why. Ask why until you know you've found the root cause.

http://en.wikipedia.org/wiki/5_Whys

Searching for "the" root cause (as opposed to more than one) is its own fallacy though.

The Ishikawa diagram (http://en.wikipedia.org/wiki/Ishikawa_diagram) is a way of assuming and charting out multiple causes.

So the root cause of the problem "why can't we play outside?" is because "god is dead and we're alone".

https://www.youtube.com/watch?v=8idwyuVJ4ug

Also clarify at the beginning of the meeting (or preferably before), who owns this meeting and what is the agenda or decision to be made.

Reply on news.ycombinator.com