If you’ve read Call it Courage, then you know the story of Mafatu, the boy who was afraid.

Mafatu grows up in Polynesia, surrounded by the ocean—but everything about the sea terrifies him, because he remembers his mother drowning when he was young. Determined to conquer his fear or die trying, Mafatu sets out alone in a dugout canoe, into the element that terrifies him most. He ends up stranded on an island that harbors cannibals. In one memorable scene, his faithful companion dog is endangered by a tiger shark; Mafatu jumps in the water and attacks with only a knife. When he kills the shark, he realizes that something fundamental in his heart is now different.

He still feels fear, but it no longer overpowers him.

He is free.

I’ve been blogging about the skills and mindset of effective software architects for quite a while now, but I recently realized that I’ve omitted the fundamental subject of courage.

This is an important gap, because courage counts. The cleverest, most skilled architect or engineer will accomplish very little, at key junctures in a career, without it.

Symptoms of fear

In the past two decades, I’ve heard many people (myself included) make statements like the following:

• “We cannot do <risky change X> because it might destabilize the code.”
• “Stay away from <module Y>. Here be dragons.”
• “I’m not sure <technique Z> is wise. There are too many unknowns.”
• “If I try to sell that idea to <executives/product management/the dev team>, they’ll just roll their eyes and change the subject.”
• “Nobody will buy into the need to pay down technical debt.”

Such statements are really just fear, dressed up in fancy clothing.

I’m not going to claim that these fears are irrational. It could very well be that your change is risky, courting allies is a recipe for frustration, and you’ll fail.

Mafatu’s fear of the sea was rational, too–and it was based on traumatic, real-world experience, not theory. But when the need was great, Mafatu plunged in, met his fears, and mastered them.

Sometimes we need to do that as technical thought leaders.

When to confront our fears

This is particularly important in pivotal moments when the choice is between a “safe” dead end and a risky but maybe game-changing innovation. If we believe that without a change, our codebase or our product or our team is headed for extinction (especially, when it’s “not with a bang, but a whimper”), we have a duty—to ourselves, our employers, and our customers—to jump in the water with our knife and do battle with the shark.

I am not advocating that we recklessly battle about every issue that lights up our radar. But I do think we need to notice when fear is inhibiting necessary change, take a deep breath, and commit. (Too bad they don’t teach that to CS majors. :-)

Case study 1

A while back, a large and mission-critical codebase under my purview was exhibiting frightening stability problems. My boss was beside himself. I was newly hired, and not yet battle-tested at the company or even in the industry where the codebase was focused. After some analysis, I recommended the commissioning of a “tiger team” to surge on a handful of key architectural initiatives.

This must have been scary for my boss. Should he bet his personal reputation, the credibility of the engineering team, and the revenue stream of the company on advice that he couldn’t easily validate? Not only was I an unknown quantity, but I was proposing radical changes to an already shaky codebase; the possibility of making things worse was very real.

I halfway expected to be ignored, but my boss (and a lot of other stakeholders) had guts. He championed the strategy all the way to the CEO. The tiger team was born; in about 7 weeks we made a fundamental improvements to process, build, test framework, and code organization. The next release was a significant improvement.

Score: Fear 0, Courage 1.

Outcome: Big success.

Case study 2

From about 2004 to 2007, I worked to transition backup technologies at Symantec from a tape-centric to a disk-centric model. A big problem for us was the fear of cannibalizing the revenue stream of the traditional product. We ended up dithering long enough that the opportunity to ride a disruptive wave largely passed us by. Cloud and virtualization and SaaS all combined to erode the value prop of traditional backup.

Score: Fear 1, Courage 0.

Outcome: Painful, lingering, and preventable failure. Shame on us. (A coward dies a thousand deaths; a hero only one…)

Case study 3

In 2008, I started a company with several of my MBA buddies. We’d been experimenting with product concepts for months. We wrote a comprehensive business plan, bought the IP of a silicon valley startup that was looking to liquidate, and began to pitch to investors. We believed we had a technology recipe that could alter the social media landscape.

Remember what happened to the stock market in 2008?

Yeah.

That all went down just after I emptied my personal savings to fund our startup, and just before we were hoping for an infusion of investor capital.

I’ll skip a long story and simply say that I’ve paid some tuition in the school of hard knocks.

Score: Fear 0, Courage 1.

Outcome: One of my best failures.

The moral, part 1

If you’re into combinatorial math, you’ll notice that I’ve given you 3 out of 4 possible scenarios: +courage —> success, -courage —> failure, and +courage —> failure.

There’s no 4th story, because -courage —> success is about as rare as frog fur; it only happens by random mutation.

If you want a chance to change the world, you need courage; listen to fear, and it’s not hard to predict the outcome.

The moral, part 2

Most of the failures we fear are not all that catastrophic. I’m still kicking.

The moral, part 3

It’s worth noting that I have no regrets about my “failure” where I took a risk. It didn’t work out. Like Edison, I now know another way not to invent a lightbulb. I’m good with that. As Seth Godin says, even mistakes can pay off in the long run.

On the other hand, I still bore anybody who’ll listen, with my harangues about head-in-the-sand thinking in the backup market.

Challenge

In Shakespeare’s Henry IV, Part I, Falstaff claims that discretion is the better part of valor–or in other words, it pays to be cautious.

This is certainly true. Sometimes. Mafatu was probably wise not to tangle with tiger sharks every day.

However, Falstaff is rationalizing. The audience knows it, and so does he.

I’m going to make a conscious effort to notice when I’m listening to fear more than I should, and I’m going to try to be more courageous when it matters.

Action Item

Find a moment when courage counts, and seize it. Celebrate the success of the commitment, regardless of the outcome.

Related articles

• Practicing Courage (slaw.ca)
• Notes from the Mystery Machine Bus (Steve Yegge, Google +)