This blog was the inspiration for my talk at the recent Test Leadership Congress. I would highly recommend the conference!
Recently, I had my 18-month review. During the review meeting, one particular conversation I had particularly stood out to me: (Note – this isn’t a direct quote, but I’m pretty sure it captures the gist of the conversation)
Manager: “You’re now reasonably good at critically thinking
when it comes to questioning a product, but I’m not confident that you’re as
good when it comes to critically thinking about people’s assertions.”
Kwesi: “What do you mean?”
Manager: “For example, suppose you were in a design meeting
for a product, and an experienced developer said ‘the product should behave
like X in situation Y’, or ‘it’s really important that you spend lots of time
testing Z’. I think there’s a risk that you’d think about it for a few seconds,
and then respond ‘yes, you’re completely right’, rather than giving it more
Kwesi: ***Thinks for a few seconds***
Kwesi: “Yes, you’re completely right!”
Admittedly, I have thought about it more carefully since my
review, and I think the above conversation is accurate. I’m entirely capable of
critically thinking about things. I spend most of my days at work interacting
with our products, critically thinking about what I observe, and thereby exposing
problems with the products. If I read a functional specification, I’m capable
of generating many test ideas based on critically thinking about what I read. However,
if I’m in a conversation with someone and they express opinion X, I find myself
nodding along in enthusiastic agreement, even if I think they’re wrong.
So why do I behave so differently depending on the
Throughout my life, I’ve always been very conflict avoidant. In fact, the only people I’ve ever
had heated arguments with are members of my immediate family. I suspect there’s
one key reason for this: I simply don’t “get” anger/irritation. It’s not that I
don’t understand that these are pretty common emotions (see http://www.mindyouranger.com/anger/anger-statistics/
to get a sense of just how prevalent they are in day to day life). It’s more
that they’re emotions that I basically never feel myself. I would say that I
feel “irritated” an average of less than once per week. Anger is even rarer for
me – if I try and think about the last time I felt “angry”, I’d need to go back
about 7 months!
As a consequence, I equate irritation with “this is the
worst thing that will happen to me this week”, and anger with “this is the
worst thing that will happen to me in the next few months”. Unsurprisingly
then, when I see other people being “angry” or “irritated”, my immediate
reaction is one of fear and worry. And it’s this fear of people being “angry”
or “irritated” with me that leads me to be so conflict avoidant.
How does this relate to work? Imagine you’re a tester in a
design meeting, and the lead developer says “the product should do X”. With
your critical thinking hat on, you think “actually, the product should do Y, as
well as X”. How do you communicate this to the developer? Clearly the developer
has invested time and effort into this design, and challenging their design
might anger or irritate them. Based on the previous two paragraphs, I hope you
can see why the prospect of challenging their design terrifies me.
Fear of not knowing things
A digression about the education system. In my experience, a
key value that schools and university teach is the following: “revealing that
you don’t know something is bad”. For example, how many school/university
courses did you attend that were like this: 1) Teacher tells you “correct”
theory/facts about thing; 2) Student is rewarded with good grade if they learn
theory/facts, and regurgitate them in the appropriate fashion; 3) Student is
given bad grade if they don’t do step 2. (I have thoughts about how this system
could be improved, but that’s for another time).
With the benefit of experience and hindsight, I can see that
I derived various terrible values from my education, but “fear of not knowing
things” has to be amongst the most pernicious, deleterious lessons that I
learnt. Here are four ways that it’s affected me personally since starting at
work (I’m hoping that at least one of these ways will resonate with you):
- When I was asked a question by a colleague that
I didn’t know the answer to, rather than say “I don’t know, here’s somebody
else you can ask”, I would come up with the best plausible answer that I could,
in the hope that they’d be satisfied with the answer. This was true even if my
response was skilfully disguised bullshit. Also, if it’s a question that I felt
that I was supposed to know the answer to, I’d be significantly more likely to
- When I was trying to do a task, and things
weren’t working as expected, rather than just ask somebody, I would spend as
much effort as possible trying to diagnose the issue, and only ask somebody as
a last resort.
- Generally feeling shit about my competency as a
professional when I don’t know how to do tasks that I’ve been set, or answer
questions that I’m asked. This was particularly acute during my first year or
so at the company, having spent the previous 21 years generally knowing how to
answer questions set by teachers, or at the very least, knowing how to make
progress towards getting the correct answer.
- A fear of taking on tasks that are outside my
experience or comfort zone, because I’ll regress to not knowing how to do
things, and that’s bad.
To be clear, the above 4 things are not to be emulated! If I
could go back in time and talk to myself on my first day of work, I’d scream at
myself not to do these things!
So, let’s go back to the example of being a tester in a
design meeting, and the lead developer saying “the product should do X”. You
happen to know that it’s crucial that the product has quality Y, and you have a
worry that if the product does X, it might threaten quality Y. However, you
have no idea of the technical details required to rigorously demonstrate your
hunch. How do you communicate this to
the developer? In particular, what do I say, given that I don’t understand
exactly what’s going on, and I don’t have a concrete suggestion for what to
change? Moreover, it’s likely that the lead developer knows more than I do, so
is the problem my understanding or their design? I hope I’ve explained why the
“fear of not knowing things” might make me reluctant to speak up in a similar
So, here are two problems preventing me from doing my job as
well as I could. So what should I do?
So, what is Humble Inquiry?
Coincidentally, at about the same time I had my review, I’d
just ordered a book called “Humble Inquiry: the gentle art of asking instead of
A couple of concepts struck me as important: firstly, the
definition of “here-and-now humility” – when person X is dependent on person Y
to impart some knowledge or do a thing so that person X can achieve one of
their goals. This actually applies to all roles in an organisation, especially
managers, but this also applies to testers. As an example, in order to have a
product that behaves in a way that is desirable to customers, a tester is
dependent on the developer writing some code in order to do this. Moreover, the
tester almost certainly doesn’t know exactly what code would achieve the
Secondly, the book talked about a specific type of inquiry
derived from an “attitude of interest and curiosity”. I interpreted this as the
sort of questioning that isn’t leading, rhetorical, embarrassing, or a
statement described as a question, but rather questioning with no other motive
than interest in the answer.
To give you a (short) example from the book:
My house was on a street that feeds directly onto the main
highway into Boston. I was in my front garden when a woman drove up and asked
me whether I could direct her to Massachusetts Avenue. This would have meant
turning around and going back across several streets. I asked her, “Where are
you trying to get?” (Humble Inquiry). She replied that she was trying to get to
downtown Boston. She was already on the direct road to Boston, so I told her to
just keep going on the road she was on. To this day I wonder what would have
happened to her if I had told her how to get to Massachusetts Ave.
What I Learned
- Don’t jump in telling answers until you know
what the other person really needs to know.
- Don’t assume that the person with the question
has asked the right question.
(If you want an example that is more specific to testing,
read this short anecdote by Richard Feynman: http://tools.jiscinfonet.ac.uk/downloads/lsd/feynman.pdf)
As I was reading this book, a light bulb went off – I don’t
need to confront people or know things in order to critically evaluate their
assertions! All I need to do is humbly enquire! For example, I’ve been to
design meetings where they’re discussing things, and I have almost no idea
what’s going on. But I do know what the aim of the product is. Beforehand, my
fear of conflicting people and not understanding what’s going on meant that I’d
say basically nothing. Now, simply asking questions like “what does this
product do”, or “what happens in this case” or “what happens if this particular
feature fails” is a way for me to provide value whilst avoiding the two
problems mentioned before.
In the past, my manager had spoken about a tester they’d
managed: the tester would talk to a developer, and ask questions such as “if
this component failed, what would happen?” and the developer would think about
it, realise there’s a bug, and fix it before even coding it. I’ve always
thought that was excellent testing, but I’d mistakenly assumed it was because
that tester happened to be a product expert and was really good at spotting
issues in products. But until very recently, I’d misunderstood – this tester
was simply good at humbly inquiring!
So testers – no longer do you need to fear that you can’t
contribute at story, whiteboard, design meeting or functional specification
review! Attend those meetings, “humbly inquire”, and let your curiosity and
interest guide them into thinking about interesting questions! And if you want
to get better at humble inquiry, I’d start by reading the book, and practicing
the techniques it describes.