Questions are a powerful testing tool and, like any tool, can be used in
different ways in different scenarios with different motivations and
different results. A significant part of my role is generating questions
and I will generally have a lot of them. I will rarely ask them all,
though, and I've put a lot of time and effort into learning to be
comfortable with that.
A couple of examples: I was in a meeting this week where the technical conversation was too deep for me to give a perspective from a position of knowledge. I could have disengaged, but I didn't. Instead, I asked occasional questions, not wanting to derail the discussion or disrupt the flow.
Some were detail questions, to help grow my understanding. Some were scoping questions, to help understand motivations. The one that really landed, however, was about the focus of the meeting. Although I couldn't contribute at a low level, I understood enough to suspect that we were not discussing the key problem that I perceived. So I asked, it turned out I was right, and the direction of the meeting changed.
On a couple of other occasions in the week I was showing an in-progress SFDIPOT analysis (from the Heuristic Test Strategy Model) to members of my team. I was using the mnemonic as a frame for my theoretical exploration of a system that we're being asked to build. There are few constraints at this point and so there are many unknowns, many open possibilities, and many permutations of them.
This means many questions.
One colleague challenged the value of the exercise, wanting to understand what the outcome would be, another wanted to know how we would get answers to all of the questions and why I was asking questions about, to their mind, "later" concerns.
I tried to explain that in this work I'm thinking through the space in which we're working. Questions might be placeholders for further thought, a guillotine that can rule in or out some set of possible solutions, speculation about a potential problem, noting an ambiguity, or numerous other things. The analysis is a way to grow understanding, identify unknowns, and try to find the extent of the relevant context.
For those who take the view that projects proceed linearly through a series of orthogonal choices this can look messy, inefficient, or even pointless. In my experience, it's extremely rare to find projects where you can make a choice today confident that no downstream factors should be considered. Systems thinking for the win, especially when you don't have the system yet.
An outcome might be that a stakeholder needs to be asked specific questions immediately. But, to be honest, it's likely that some of the questions will never be raised to anyone at any time. The key is that, as much as we can, the right questions should be asked in the right forum to the right person at the right time. I find that thinking around the topic, preserving the uncertainty, helps me to do that
Image: cropped from https://flic.kr/p/BxTxp
Comments
Post a Comment