3 ms·

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

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)

mbillie1 13y ago
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.
cpeterso 13y ago
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.
dredmorbius 13y ago
"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.
- carrotleads 13y ago
  This is true for any meeting where a specialist is outnumbered and the other folks have already made up their mind.
  - dredmorbius 13y ago
    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).
- sopooneo 13y ago
  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.
- meowface 13y ago
  I'm starting to see a lot of similarities between managers/executives and beginners asking questions in programming IRC channels...
McGlockenshire 13y ago
Don't just ask why. Ask why until you know you've found the root cause. http://en.wikipedia.org/wiki/5_Whys http://en.wikipedia.org/wiki/5_Whys
- skrebbel 13y ago
  Searching for "the" root cause (as opposed to more than one) is its own fallacy though.
  - brenschluss 13y ago
    The Ishikawa diagram (http://en.wikipedia.org/wiki/Ishikawa_diagram http://en.wikipedia.org/wiki/Ishikawa_diagram) is a way of assuming and charting out multiple causes.
- zboswell 13y ago
  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 https://www.youtube.com/watch?v=8idwyuVJ4ug

mbillie1 13y ago

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.

cpeterso 13y ago

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.

dredmorbius 13y ago

"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.

carrotleads 13y ago
This is true for any meeting where a specialist is outnumbered and the other folks have already made up their mind.
- dredmorbius 13y ago
  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).
sopooneo 13y ago
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.
meowface 13y ago
I'm starting to see a lot of similarities between managers/executives and beginners asking questions in programming IRC channels...

McGlockenshire 13y ago

Don't just ask why. Ask why until you know you've found the root cause. http://en.wikipedia.org/wiki/5_Whys http://en.wikipedia.org/wiki/5_Whys

skrebbel 13y ago
Searching for "the" root cause (as opposed to more than one) is its own fallacy though.
- brenschluss 13y ago
  The Ishikawa diagram (http://en.wikipedia.org/wiki/Ishikawa_diagram http://en.wikipedia.org/wiki/Ishikawa_diagram) is a way of assuming and charting out multiple causes.
zboswell 13y ago
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 https://www.youtube.com/watch?v=8idwyuVJ4ug