As IT professionals our job is to understand our clients (whether internal or external) and use our skills to help them get their outcome (whether by delivering a software system or solving a technical problem). We all spend our days asking questions in an attempt to understand how we can help and yet clients or users often feel that they've been misunderstood. Most often this is expressed when the outcome isn't reached because we delivered the wrong thing. "That's not exactly what I meant", they say. And we then set about finding out what they did mean and trying to deliver that, whilst trying to keep to deadlines and budgets (which, of course, we can't).
You would think that, given the importance of eliciting clear and accurate requirements, we would invest in equipping IT professionals with the skills needed to do this. And yet, for the most part, we don't.
For example, how often have you been in a conversation (or witnessed one) where client Alice says to developer Bob "I need an X"? And Bob (having previously delivered "X" so many times during his career) says "sure! I can do that". And when it's done, Alice says "thinking about it more, I need more of a Y".
What would happen if IT professionals - whether developers, quality assurance engineers, business analysts, project managers, consultants, architects, support engineers or anyone else whose business is to understand their client's business - had a way to quickly and consistently get that understanding?
The good news is that there are just two questions that, if consistently applied, can make a significant difference.
These two questions are from the world of "Clean Language" which is a communications methodology that is often used by Coaches and Therapists but can also be very useful for IT professionals. At its purest, Clean Language doesn't allow the coach to use anything more than a core set of "clean questions" and the response of the client, using their words. The coach must not use other questions or their inject their own language. You'd think it would be restrictive, but from my experience it's a very powerful approach that gets results fast.
So what would happen if the conversation went more like this?
Alice: "I need an X"
Bob: "What kind of X?" or "What kind of X is that X?"
Alice: "Well, it's more of a Y"
Bob: "What kind of Y is that Y?"
Alice: "It's a Y that has A, B and C."
Bob: "What kind of A is that A" ?
Alice: [describes something about A]
Bob: "And is there anything else about A?"
Alice: [describes something else about A]
Bob: "And is there anything else about A?"
Alice "no"
Bob: "And what kind of B is that B?"
[Bob continues to ask about B and C using these questions]
Bob: "And is there anything else about A"
Alice: "no, I think that covers it".
If the conversation went like this, it's highly likely that Bob would have a much better understanding of what Alice wants. But, crucially, Alice would have a better understanding of what she wants before Bob begins to deliver a solution. This is one of the key aspects of IT software or service delivery that is often forgotten.
Our role is not just to understand our clients. It's also to help them understand themselves.
If our clients don't fully understand what they want, how on earth are we able to help them get it?
By giving them an opportunity to explore their outcome (the thing they want to have happen as a result of talking to you) in their language we can help them understand their outcome even more deeply. And as they do so, we benefit from that deeper understanding. As we help, so we are helped.
Of course, most of us already use some form of these questions, but we probably don't do it regularly and consistently and we probably change the language as we do so.
For example, Bob might ask "what do you mean by X?". And Alice, perceiving this question to be slightly confrontational, might not respond well.
Or Bob might say "oh, you mean a Z!", mapping Alice's language into his own world. And Alice then has to decide whether that's true despite not knowing anything about "Z" and therefore having to make a hazardous guess.
Or Bob might assume that he knows what Alice means by "X" and move on to the next question. He might be embarrassed at asking Alice about what she means by "X" because surely everyone knows what an "X" is and therefore Alice might think Bob is stupid or wasn't paying attention. In moving on too early, Bob misses an opportunity to understand "X" even better.
Let me give a real-world example, but not from the world of IT.
I was coaching a client who was stressed because they wanted to buy a house, and couldn't afford to do so without changing jobs (which they didn't want to do) or getting a second job (which would have created ongoing stress, not to mention physical exhaustion). At that point it would have been natural to suppose that the problem was going to be solved by helping the client to make more money in a way that was OK for them, learn how to cope with the stress of a second job or help them accept that their goal was unachievable with current resources.
But it turns out that wasn't the problem at all.
Fortunately, I had the presence of mind to ask "What kind of house is that house?".
And the client brightened up and replied "Well, it's more like a home. A place where I can put up my pictures and paint the walls the colours I like."
Sensing there was more, I asked "And is there anything else about that house?"
After quite a long period of silence, the client answered "well, I just realised that I don't need to buy a house. I just need to rent a place where I am allowed to make it my home", and broke into a huge grin.
It would have been very easy for me to take the first answer at face value and carry on trying to help the client find ways to buy the house. But it would have been the wrong solution.
Daring to ask these two simple questions - "what kind of X is that X?" and "and is there anything else about X?" - gave my client the space to understand their own outcome more clearly and find their own solution.
These questions can be used in any kind of relationship where Person B is trying to understand Person A (which is pretty much any relationship, whether professional or personal).
You might be concerned that this process would be time consuming or frustrating for the client. Parrot-like, even. But if you adopt the right attitude - helpful curiosity - and stick to the client's language (not translating it into your language) your client will probably have a rare but valuable experience not only of having been properly listened to, but also having been given a space in which they can understand and refine their outcome. And that's priceless, because there's every chance that you just saved yourself significant time, frustration and budget by reducing waste.
So next time you think you've just understood what someone has just said to you, why not pause, take a breath, become curious and ask "what kind of X is that X?". And when they've answered you, continue to ask "and is there anything else about X?" until they say "no".
I hope this is useful. If you'd like to find out more about Clean Language and how you can use it in your professional or personal life then get in touch.
