We’ve all come to a crossroads on a project.

We choose one path over another, somehow. We ship, or not. We report the bug, or not. We change, or not. We hire, or not. Various factors may lead us to choose one path over another. Sometimes we choose a path based on what we seek: success for the project, value for the stakeholders, revenue for the company. Other times we choose the lesser of two evils. Instead of running toward a goal, we run away from fear, pain, guilt, or unpleasantness.

Over the years, I’ve noticed a pattern. When I choose a course out of fear, I almost always choose wrong.

• I was wrong when I accepted shipping unready software for fear of losing a big customer over a missed deadline. We lost the customer anyway because the software was so bad.
• I was wrong when I recommended changing a feature out of fear that an obscure corner case bug could become a serious quality issue in the field. My sky-is-falling ravings wasted a lot of time and cost me credibility over an issue that was, in hindsight, incredibly minor.
• I was wrong when I held off on escalating quality issues to the executives fear of how everyone, my manager included, would react. Bad news never gets better with age.
• I was wrong when I hired an otherwise unimpressive QA candidate too quickly for fear that another company would snatch him up. I wish another company had hired him out from under me, preferably a competitor. He was the worst employee I ever hired.

In each of these cases, I allowed fear to be my guide. Afraid of the consequences of one path, I chose another…and the result was worse than the thing I originally feared.

This is not to say that I think it’s always right to hold off on shipping software, let corner case bugs go, or shout “UNSTABLE” from the rooftops at the first sign of unreliability. The lesson I learned is not that one path is always right and the other is always wrong. No, the lesson I learned is that it is better to move toward a positive outcome than attempt to avoid pain.

Consider cases in which I didn’t allow fear to guide me.

• When building a schedule for a project, I insisted we include time for developer testing. I was a QA manager at the time. One developer commented, “I didn’t know we could add time for that!” He’d been too afraid to ask for time to do testing he knew needed to be done. Together, we gained executive approval for a schedule that included various activities related to defect prevention and early defect detection. The result was an on time release that met its goals.
• When asked to set aside automating tests long enough to help out with manual testing a release that was behind and buggy, I counter-offered. “Automation is important for us,” I argued. “It will enable us to test faster and more reliably. Let’s see how automation can help with this late and buggy release.” Automation paid off on that release. It was one of those rare cases when I was able to automate more tests in the limited amount of time available than I could possibly have executed manually.
• On two occasions when I found job candidates that rocked their interviews, I cut through the hiring red tape and got them signed offer letters fast. I wanted those candidates on my team ASAP; I got them; and I was right about both of them. They rocked their jobs the same way they rocked their interviews.

Once again, the lessons here are not always extend the schedule, always automate, or always hire fast. The lesson is a little more subtle: choose a path that takes you in the direction you want to go. Don’t choose a path simply because it takes you away from the swamp you want to avoid.

So if fear is a lousy compass, what’s better? What can we aim for that will increase the odds of success? Consider:

Stakeholder value. I look for options that increase value for our stakeholders. Shipping unready software is extremely unlikely to increase value, even if executives think it will increase revenue. However, sometimes I find I must consider what’s good about a system and not just what’s wrong with it. Stakeholders may well find value in software that gives them unique capabilities, even if that software has bugs. Aim for value, whatever that looks like on a given project.

More information. I speak the truth as I see it, even if the truth is unpleasant. I try to do so in a way that enables people to hear it, and sometimes that means being diplomatic. But having seen how sanitized test results can support wishful group-think, I’ve learned that providing a complete and honest accounting all the way up the management food chain is far preferable to telling stakeholders what they want to hear.

More choices. Jerry Weinberg says that one choice is a trap, two choices is a dilemma, and only when you have three or more options do you really have a choice. If I can achieve nothing else, I want to increase the options available to me. One of the new options is likely to be better than the old ones. And if not, at least we explored more possibilities.