Friday, March 23, 2012

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:
--
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."

4 comments:

Duncan Nisbet said...

Hi Scott, great post and I agree on the importance of trust in delivering business value.

I had previously looked at trust in the dev team between the Business/PO and us the developers - we had to instil trust in the Business by delivering the features they required and wowing them in demos.

The happier they were with what we were delivering, the more we can ask them to back off on the metrics - we almost used it like a bargaining chip.

We used to use story points to monitor our velocity, but they started using the points as a stick to drive us with. When we met our deadlines & delivered all the stories for the initial release, and the launch was a success we felt we had the trust we needed to ask those "up above" to back off a bit. Fortunately they did - so now we don't report story points out of the team, they're used for internal estimating only.

Our productivity has dropped off, but that's another story..

As for trust with the Programmers - I had never really seen like that, more of a respect thing. I look for the best in people unless they show me otherwise - I would hope the Programmers would always do their best, with the resources & systems available to them & in turn I would do the best by them when helping to test their code.

You mention integrity & I feel this is a very important factor (I hope it's one of my strong points), but I have a question:

What if the Programmer is doing their best, and they have a really nice personality, but their code still sucks?

Their integrity is upheld, but I can't trust them to deliver quality code - I'll always be thinking about how much extra caution I'll need to give when testing their code.

I guess this also goes the other way if the Programmers think I suck at testing!

Scott Barber said...

Thanks Duncan!

You are correct that I did not address skills & abilities in this post. You are also correct that no degree of trust will give someone a skill or ability they don't have.

If someone does not have the skills or abilities to meet needs/expectations, that is something that needs to be addressed by that individual's manager or supervisor.

Yes, sometimes one individual's low quality of work can undermine trust in the whole team, at least until the source of the sub-par "stuff" is identified.

But what this *really* boils down to is a hiring and/or management failure. Managers will sometimes make mistakes just like the rest of us, but they to be accountable for them & do the right thing to fix them. To me, that is a large component of what it means to do one's job with integrity. If managers want to be included in the "circle of trust", *they* need to be the ones to resolve the issue you are describing.

My Dad was once fond of reminding me that "being the best at something doesn't make you any good at it", so I think what I'm saying is a paraphrase of that... "trusting someone to do their best, is not the same as trusting their best to be good enough"

Duncan Nisbet said...

Cheers for the feedback Scott!

Didn't mean to pick holes in your post - it was just something I have observed in my time.

I see what you're saying about the hiring &/or management failure - can those undermining the trust undergo some learning or have a refresher on the company culture? Are they willing to undergo this transformation?

That said, on those self organising teams who do the hiring & training themselves, the buck stops with them to sort the 'problem' out (IMO).

Loving your Dads comment - made me stop & think for a bit!

Scott Barber said...

Duncan - I can't say I have all the answers. I do know that I see lots of incongruence across organizational groups -- and hiring practices are a common one. I know how I'd *like* for it to work, but I also know that I don't have a background in HR to even know if that's *legal* (in the US, anyway).

So, I can't say that I know how to solve that part of the trust challenge. I can say that I'd like to believe that shining the light on it will eventually lead to *someone* figuring out how to solve it.