Doubt builds trust.
I don’t trust people who always say yes. “Yes, I can finish that today.” “Yes, I tested it and it works and I didn’t find any bugs.” “Yes, I captured what you said in these notes.” “Yes, I assert I have accomplished all the things I listed on my resume.”
If a person consistently lived up to their word, I would be inclined to trust them. But as soon as they weren’t able to finish a task on time, or bugs were found after they tested it, or notes were lacking crucial details, my trust would wane.
I trust the person who expresses doubt. “I’m going to look into this complexity today, and I believe I’m on track to finish in this sprint if I don’t have to rely on another team.” “I’ve tested it on this environment with this kind of data, but it’s possible that a different data set will uncover something else.” “Here’s what I wrote down, is there anything you said that I missed?” Those are people I can trust.
Doubt builds trust.
This is not revolutionary, even within software testing. Michael Bolton taught me that safety language helps accurately communicate risks. It shifts the burden of “Is it done?” or “Does it work?” to the person asking the question. Fiona Charles has explored how to grow our tolerance for uncertainty. She suggests using uncertainty as a place to begin a conversation. Paul Holland taught me to tell a story not just about the status of the product, but about how I tested and how deep the testing was. I come back to these ideas when I’m not sure the questions my team is asking about my testing are the right ones.
Lately, I’ve been interviewing candidates to join various teams around Medidata. I get resumes full of buzzwords. Each skill is listed with equal confidence and importance. But not all candidates I meet live up to how they appear on paper. Some can’t provide a specific example, or aren’t sure how to explore a product when we’re pair testing. (Frequent listeners of the Judge John Hodgman podcast will know that specificity is the soul of narrative.)
I’ve watched candidates confidently proclaim, “No, nothing will happen when I click there” about a website they haven’t touched before. This erodes my trust in their curiosity and their ability to accurately report a bug.
I can’t recommend hiring someone who when I say “Huh, I’d expect something to happen when you click there; let’s try it,” isn’t curious enough about what would happen to click there. I don’t expect someone new to a website to know how it works. I only expect them to distinguish between what they’ve explored and what they haven’t. I want them to be able to articulate the circumstances they’ve just experienced, realize that their memory or perception might be fallible, and be clear about what they haven’t yet been able to establish.
It is terrifying to be asked a question in an interview and respond “I’m not sure,” “I have to think about that some more,” or “I haven’t encountered that situation before.” I’ve said all of these things in interviews. It’s possible that I’ve lost out on jobs to other candidates who exaggerated their abilities. But the jobs I’ve been offered have been from places that value uncertainty and understand the current state of my skills. Colleagues know they can come to me for real answers because I will tell them when I don’t know.