Trust is a Cornerstone to Delivering Business Value

In my last post about Metrics I introduced the notion of trust as it relates to Business Value by stating:

"Failing to trust 'the Business' does NOT add Business Value"

I'd like to generalize that statement further to say "A lack of trust that individuals or groups involved in the project are primarily focused on helping the business succeed undermines business value".

Now, I can only imagine the reaction many testers are having while reading this. For instance "If I trust the developer when they say 'This is fine, you don't need to test it', we'll have major bugs make it to production." And anyone thinking that would be absolutely right -- because that is not the *kind* of trust I'm talking about.

When I say trust, I don't mean "Trust others to tell you how to do your job" or "Trust others to do what you believe is correct/best" or even "Trust others to be successful in accomplishing what they have been assigned to accomplish on time, on mission, on quality, and on budget"

When I say trust, I mean "Trust others to approach their role with integrity" and "Trust that others are doing the best they can to make the decisions or take the actions appropriate to their role and responsibilities based on the information they have" and "Trust that if you haven't been assigned to do or to be the decision maker about something, that task or decision is better handled by someone else -- whether or not *you* have the information necessary to make sense out of why.



I also don't mean "blind trust". Not everyone is trustworthy and not every environment fosters trust. It is reasonable that people expect trust to be earned, but also that opportunities to earn trust will be granted and in the absence of data benefit of the doubt will be given.

I'm not saying that explanations should never be requested, that decisions should never be questioned, or that procedures should never be challenged. I am saying that there is a difference between curiously requesting supporting information, logic and/or reasons when something isn't making sense as compared to continuously demanding it as if you are the CEO, President and sole investor.

I am saying that if there is no trust that people are approaching their jobs with integrity, Business Value will be constantly thwarted by whining, explaining, posturing, challenging, stonewalling, dismissiveness, defensiveness, bullying, "turf wars",  and on, and on, and on.

This may (or may not) sound easy, but it is extra challenging in technical projects due to the additional challenge that many of the people involved in the project are not natively inclined to trust people. Consider the following:

• Many people chose a career path in technology, at least in part, because they prefer or are more comfortable, dealing with technology than people.
• Developer types tend to "trust" technology more than they trust people; e.g.
• "Works on my machine"
• "The test is broken, not my code"
• "It functions as designed"
• "No, you can't have administrator access to the machine to configure monitoring for your tests. You might mess something up. And I don't have time to do it for you. Besides, the problem can't be in [my component], so I don't know why you are bothering me." (*note* The problem was in "his component", and it took us 6 days and executive intervention to get monitoring configured sufficiently to convince the developer. It took under an hour for the developer to fix, test, get approval to merge into the release candidate from 11 managers, update the build, documentation, and deployment script AND deploy the fix to the "Staging" environment)
• Tester types tend to "trust"... well... I could say "results" or "data" or "tests", but honestly, many tester types don't "trust" much of anything; e.g.
• "In God We Trust; everything else we test"
• "You can't ship until I say so"
• "I entered that as a defect because it's a defect, not an enhancement. What is the point in testing at all if [they are] just going to change defects to enhancements so [they] can ignore them? We should be in charge of the defect tracking system to keep [those managers] from messing up our product..." (*note* shortened version of an actual "epic whine"  I recently witnessed during a recent test group status meeting. I later learned the *reason* it was changed was because the Project Manager knew that the executives were more likely to grant her request to keep her "best developer" from being reassigned was with "critical enhancement and feature requests" -- because the executives believed "defect fixes were easy and new development was difficult")
• Executive types tend to "trust" finance reports; e.g.
• "We have to ship before [date] or we won't make our quarterly projections"
• "This testing thing is expensive, stop *telling* me that it is important and show me... with an ROI analysis"
• "I don't want you spending time on that defect. It may make the employees angry, but it keeps most of them from leaving early on Friday -- which means I get more work out of them that I don't have to pay for [because they are all salary, not hourly] while they wait for traffic to die down" (*note* something a VP of a Fortune 500 company once said to me... paraphrased slightly for length and profanity. The "defect" was that the time entry system could only handle about 10 folks at a time & would only accept time entry by employees from machines on-site & only between noon on Friday & Midnight Sunday)

My point in sharing those examples is not to insult or pick on anyone, the point is to use situations I believe you can relate to as illustrations of a particular trust-related challenge on technology projects.


Testers, Developers, Managers and Executives will not always agree. Disagreement is a lousy reason not to trust. So is a decision "not going your way" when it's not your job to be responsible and accountable for the decision.

Being lied to is a fair reason to not trust. Finding out that someone knowingly faked or withheld information, stole, or blackmailed are also fair reasons not to trust. As is being falsely (and vigorously) accused. Those are trust issues that generally need to be resolved individually (whether face to face, via the official corporate process, with lawyers, or by getting a new job) and are in no way unique to technology projects.

Ok, lemme guess.  You're thinking "Fine, so I get that trust is a good thing to a certain degree, but a cornerstone to delivering business value? I'm not convinced." Allow me to illustrate with some scenarios:

• As a manager or executive, if I asked you to provide me with a metric that you felt was, shall we say, of questionable ethics, and you failed to, in a professional manner, share that feeling with me and/or provided that metric without providing me with the appropriate context and/or supporting information to make proper use of that metric (where "proper use" could include educating *my* superiors about why that metric doesn't mean what they think it does), that would lead to a (significant) reduction in trust. It would also lead to a significant reduction in trust if you simply refused to provide said metric.

• Arguing with a manager about "defect or enhancement" (and then going behind her back to escalate, or whining until someone else takes up the sword on your behalf) because you don't *like* or don't understand, or haven't even asked about the decision is not focusing on Business Value. It demonstrates that you don't trust the manager to do their job, and leads the manager to feel they can't trust you. It also leads to one (or both) of you to end up looking the fool when "the rest of the story eventually emerges". 

In those scenarios, I see a lot of lost Business Value that would not be lost if an appropriate trust culture was in place. (I also see a lot of unnecessary stress, conflict, and tension. Personally, I don't mind conflict when there is a reasonable hope the situation will result in a "win-win" -- or at least a "win-not lose" -- but that is not how trust-based stress, conflict, and/or tension tends to end)

Do yourself, your team, and your business a favor. Find a way to establish a culture of role- and responsibility-based trust, take appropriate professional action against the liars, blackmailers and cheats, or start looking for a job where you can be part of a trust culture. That may sound harsh, but I don't mean it that way.

Think about it. If everyone except the liars, blackmailers, and cheats refused to work on teams or in companies that weren't based on (or at least actively building toward) a culture of trust, how long do you honestly think it would take before the "trust teams" were the majority and the "evil backstabber" teams were not only the minority, but failing to deliver (or failing to deliver acceptable products) frequently enough that the "evil backstabbers" end up driving themselves right out of our sphere of concern?

Ok, you're right, one little post from some "niche performance tester celebrity's blog" is highly unlikely to lead to that degree of mass action. But wouldn't it be cool if it did?
 
--
This is one of a series of posts related to various aspects of delivering Business Value throughout the entire product lifecycle for products that are, contain, and/or utilize software. Many posts specifically relate to software testing. To date, other posts in this series include:

• A Context-Driven Approach to Delivering Business Value
• Business Value of Testing: Find Bugs ≠ Mission
• Business Value of (Software Test) Metrics

--
Scott Barber
Chief Technologist, PerfTestPlus, Inc.
Director, Computer Measurement Group
About.me

Co-Author, Performance Testing Guidance for Web Applications
Author, Web Load Testing for Dummies
Contributing Author, Beautiful Testing, and How To Reduce the Cost of Testing

"If you can see it in your mind...
     you will find it in your life."