To question or not to question, that is the…
Right, here's my question… oh no no, not another one! Let's re-word it. Sometimes asking a question is a good thing. “There is no such thing as a silly question” and “The only silly question is the one you didn't ask”, right?
Yet, sometimes, it could be a bad thing.
For instance, you could be involved in a more or less official discussion, the kind that involves a group of people, who aren't always in the same place at the same time (not even in the same country). This situation could mean that any question asked — say, by email, — requires someone to read it, understand it (at least try to — no guarantees, eh?), check something, investigate an option or two, verify with the other stakeholders (if only to protect one's bottom from being accused of making a wrong decision, even if the decision is a trivial one — I've seen this time and again in corporate environments), and then putting together a response for you. Sometimes the response will even contain an answer, if you're lucky. All of those actions requiring time.
In such situation, asking a question can simply mean initiating a delay. Yes, you can fire a question and forget about it for some time, but is it really good for you, even if you do enjoy that sweet period of “the ball is not in my court”-ness?
So here's a thought for all of us. Before asking a question, check with yourself — do you really need to ask it? If you do — please ask, be my guest. It could a question of life and death, after all. But perhaps it is then wise to strive for such an understanding of the customer's problem, and level of trust with them, so that eventually you'll be able to pause, think, and answer the simpler ones yourself.
If the customer doesn't like your answer and it matters — they'll tell you*.
* — in another news, I've started a 5 week Stanford course on Human-Computer Interaction, and so far it has a great emphasis on producing prototypes as early as possible. This also means that sometimes it is best to pose your question in the shape of “here's what we designed, but it is very quick, easy and cheap to change it at this stage if needed”. Then the customer telling you “we don't like this UI” won't be such a disaster as on much later development stages. But this is a whole topic unto itself.
Yet, sometimes, it could be a bad thing.
For instance, you could be involved in a more or less official discussion, the kind that involves a group of people, who aren't always in the same place at the same time (not even in the same country). This situation could mean that any question asked — say, by email, — requires someone to read it, understand it (at least try to — no guarantees, eh?), check something, investigate an option or two, verify with the other stakeholders (if only to protect one's bottom from being accused of making a wrong decision, even if the decision is a trivial one — I've seen this time and again in corporate environments), and then putting together a response for you. Sometimes the response will even contain an answer, if you're lucky. All of those actions requiring time.
In such situation, asking a question can simply mean initiating a delay. Yes, you can fire a question and forget about it for some time, but is it really good for you, even if you do enjoy that sweet period of “the ball is not in my court”-ness?
 |
| They have a big shiny countdown timer on those shows. For a reason. Photo by mjtmail |
So here's a thought for all of us. Before asking a question, check with yourself — do you really need to ask it? If you do — please ask, be my guest. It could a question of life and death, after all. But perhaps it is then wise to strive for such an understanding of the customer's problem, and level of trust with them, so that eventually you'll be able to pause, think, and answer the simpler ones yourself.
If the customer doesn't like your answer and it matters — they'll tell you*.
* — in another news, I've started a 5 week Stanford course on Human-Computer Interaction, and so far it has a great emphasis on producing prototypes as early as possible. This also means that sometimes it is best to pose your question in the shape of “here's what we designed, but it is very quick, easy and cheap to change it at this stage if needed”. Then the customer telling you “we don't like this UI” won't be such a disaster as on much later development stages. But this is a whole topic unto itself.
Comments
Post a Comment