By Randall W. RiceCredibility can be destroyed in a moment or can be eroded over time. As messengers and leaders for software quality, we put ourselves in a position where our own actions can take away from our message. Something as minor as a misspelling in a presentation can cause others in the organization to say things like, "They flag every mistake we make, but they can't even proofread their own writing."
Everyone makes mistakes, but how can we as testers avoid losing our credibility? Let's start by looking at some credibility killers.
Of course, the idea is that you will avoid doing these things so you won't destroy your credibility. Consider these the pitfalls to avoid.
One of my favorite television shows is called "Faking It." The premise is that a person is selected to perform the work of someone in another field so expertly that not even a panel of other experts in the field can tell the person is a novice. The person is trained and mentored by a team of experts over a period of about thirty days before the "test" arrives - often a competition of some sort. Many times, the candidate pulls off the fake, but sometimes they don't.
Interestingly, this sounds like the way many testers and test managers start in testing: We were doing something else until someone needed a tester or test team leader. To prepare, we had a crash course of learning what testing is all about (often "on-the-job" training), and then we had to do this job in front of people who can be highly critical.
This means that many of us live on a learning curve, some at steeper levels than others, but we're all learning. I hope this gives you comfort. It's all right not to know everything!
One of the worst things you can do is fake it when you really don't know something. Unfortunately, this is one of the first things people resort to when they are placed "on the spot." It's so much better just to pause a second and admit that you don't know the answer. Even experts don't have complete knowledge, but they know where to find the answer. Einstein was quoted as saying, "Never memorize anything you can look up."
That's workable with facts, but what about the broader issue of understanding? It's possible to have the facts memorized, but if you don't know why they are important, then you are missing the context of the information, which is everything.
Facts can be learned in a matter of hours. Understanding may take months or years - it depends on the complexity of the issue.
The rule here is to speak of what you know and don't go further. If you choose to venture into talking (or writing) about that which you do not truly know (and believe me, I know about this one), then you are, my friend, on thin ice.
If you are relying on other sources for your information, double check them and then think critically about other perspectives on that information. Does the source have a reason to falsify or embellish the information? How old is the information? How reliable is the source? Can the information be validated or verified?
Congruency means that you act in a way that is in accordance to what you say. For a tester, this means that if you talk about the importance of quality, you apply it to your own work. In other words, as the old saying goes, you "walk the talk."
When you fail to act congruently, people start to question your true beliefs. Plus, it gives the appearance of hypocrisy, which is real credibility killer. People say things like, "Why should we listen to her? She had three typos in her presentation last week?"
To prevent incongruent behavior, you have to apply the same standard to yourself that you apply to others. This requires that you stop and reflect on a regular basis about your own performance.
You can have reviews or walkthroughs of your own test plans, cases and scripts, and have a proofreader for all of your work products. In a team setting, you may choose to proofread each other's writing. You can measure what you do and study what the measurements indicate. For example, if you give a "learn at lunch" session, have a short evaluation form to ask if the information was helpful and the presentation one that added to the understanding of the topic.
I'll never forget the QA conference that temporarily did away with session evaluations. The message sent to the attendees and the speakers was two-fold: 1) we don't care about what you think and 2) we don't practice what we preach – as one of my colleagues, Bill Hufschmidt, puts it "Quality without measurement is just cheerleading."
Credibility is based on trust. If I don't find you credible, I can't trust what you're telling me.
Another quick credibility killer is to violate trust. This can happen in a multitude of ways: being inconsistent, going behind someone's back, lying, cheating, falsifying information and so forth – name your poison.
Rebuilding lost trust is very delicate and takes time. I can't tell you how long it takes to rebuild trust, but one of the best ways I've known to view it is like a bank account that you make deposits to over time. When you are deeply withdrawn, it takes a lot of work to dig out of the deficit unless you win the lottery or receive a major inheritance. When you still have a positive balance in the "trust account" you can slip up occasionally and still be in an overall good standing. Too many slip-ups, though, and you've lost trust.
This may seem like an odd thing, but the lack of a caring attitude can also hurt your credibility. This especially holds true for leaders. As I quoted in the first article, "People don't care how much you know unless they know how much you care."
Caring goes back to trust and relationships. It's hard to show a caring attitude is you don't know what is important to people. It's also hard to be caring if people don't trust your motives. The caring has to be genuine.
Caring can be seen in many ways, not just interpersonal. For example, people need to see that you are genuinely concerned about the outcome of the project.
This is related to the lack of a caring attitude, but deserves a category all its own. People don't like those who are arrogant, but the problem is that arrogant people are often the last to know they're that way.
Arrogance is often rooted in knowledge ("I know more than you.") or past successes ("I've done more than you." Or "I've done this well in the past and you haven't."). Even though the messages aren't often said in these ways, this is the message that comes across.
Arrogance builds a wall that makes others not want to communicate across. People also tune out those who have an arrogant attitude.
On this one, listen to what you say and how you say it. It's one thing to be confident but another thing to be arrogant. The arrogant person usually disregards others' views. The confident person knows they can do the job, but also seeks collaboration. Let you confidence show, but not to the point of thinking you know it all. You don't. Nobody does.
All you have to do is exaggerate a few times and your credibility takes a big hit. If you are a known exaggerator, people assume you've overstated the case every time, so in their minds, they reduce the significance of your information.
If you are an exaggerator and say that the application has a catastrophic defect, the receiver of your report may think "Well, it's probably something we can work around."
Once again, take time to listen to yourself to see if you are prone to exaggerate. If so, practice critical thinking to question your own messages. Also, it's helpful to verify the information you plan to convey with someone you consider to be objective.
Also, understand that you don't need to make situations larger than they really are. In my observation, people exaggerate to get attention or fast action. The long-term price you pay for exaggerating outweighs any short-term gains.
Some people don't lie or exaggerate, they simply omit information. It's impossible to completely include all information about a topic, but what I'm referring to here is the intentional hiding of meaningful information.
This is a credibility killer. Once people know you have hidden information, they will question future information.
If you've hidden information in the past and lost credibility due to it, you have to work to assure people the information is complete. One way to do this is by having independent verification, such as reviews and secondary sources. For example, if you are a test team leader, you might assign the tester that found a defect could be the one that reports it in a management meeting. Or, if you are a tester, you could get a fellow tester to collaborate the completeness of your information.
Like all the rest of the above credibility killers, this one also takes time to restore.
Blame is a very negative thing. Nobody likes to be blamed for something and few people readily accept blame.
Shifting blame to someone else is a sure credibility killer, especially in a team setting. However, blame shifting can also cause bad feelings on a project and hurt your credibility in the organization.
Most people expect accountability in the workplace. Whether or not accountability is realized is another thing.
If you have been guilty in the past of shifting blame, taking responsibility can turn things around quickly by showing others you are accountable. It's hard to take the heat for a mistake, but people will respect you for it.
We've seen a variety of ways you can lose credibility as a tester or test team leader. It only takes a short time to lose credibility, but may take a very long time to rebuild it.
Credibility rests on trust. If people can't trust you, they won't find you credible. People may or may not like you, but that's a different matter.
Many times people commit credibility killers as a short-term relief, but sometimes these actions become a long-term pattern of behavior. To reverse the situation and rebuild your credibility, take time to reflect about the above credibility killers and ask yourself if you are guilty of any of them. In the next article, Rebuilding Your Credibility as a Tester, we'll explore some ways to restore lost credibility.
If you have any thoughts on other "credibility killers" write me from the contact page. I would love to hear your feedback.
All materials on this site copyright 1996 - 2009, Rice Consulting Services, Inc.
Consulting Services, Inc.
P.O. Box 892003
Oklahoma City, OK 73189