Fear of failure? Embrace it by failing fast. | Opensource.com

This is the third in a series exploring the things I have learned from the open source way during my journey with Red Hat.

One of the key tenets of the open source way is “release early, release often.” This means rather than keeping an idea or project "secret" until it is perfect, you go ahead and share it or make it available to others. You get it out there, let people play around with it, test it, expose its weaknesses, you allow peer review.

Linus Torvalds, the creator of Linux, has a famous quote, “Given enough eyeballs, all bugs are shallow.” In the open source world, it is taken for granted that you want to open your work to the world quickly for the very simple reason that if you do, you make it possible for others to help you make it better faster (and you find the bugs).

Some people refer to the concept of releasing early and releasing often as “failing fast.” You expose your weaknesses quickly so you can fix them equally quickly.

The concept of release early and often works pretty well… except maybe if you are like me and have a fear of failure. For someone who has high expectations of myself, failing fast doesn’t sound too appealing.

As I’ve mentioned in previous posts, before coming to Red Hat I was a transactional lawyer, and my job was to limit risk for my clients. That worked well for me because, like a lot of my friends, I was not particularly interested in taking risks.

Then one day at Red Hat, I hit a turning point and learned to embrace the idea of taking risks by releasing early and often. This turning point came with the help of our Chairman Matthew Szulik, a great mentor to me.

Matthew and I were talking about a project and whether I could "do it". Matthew said: “DeLisa, it is like you are in a race, and you are winning but you don't know it, so you keep pushing harder.”

With that insightful comment, I began to embrace the idea of taking a risk and sharing my ideas before they were fully baked. I began to "fail" in small, manageable ways. This didn't seem so bad and, in fact, it started seeming more like learning and continuous improvement, avoiding the failure word altogether.

What’s more, failing fast proved to be very appealing for another reason. Failing fast usually means failing small rather than failing big. If you are constantly putting your ideas out there, getting input, improving them, in most cases you may be able to avoid the kind of failure you really fear—big, catastrophic, monumental, embarrassing failure. You know, the kind of failure that gives you nightmares.

Over the years, I’ve watched as many open source software projects have taken this concept of releasing early and releasing often and used it to build better software faster. And I've seen our corporate groups use this idea when we are rolling out new programs and policies, with far more success than other approaches. And personally, I’ve used it to turn my fear of failure into power, to turn a weakness into a strength.

Do you fear failure? Perhaps by learning to fail in small ways all of the time, you too might be able to avoid the big failure you really fear.

4 Comments

According to wikiquote.org, it gives credit to Linus Torvalds saying "Given enough eyeballs, all bugs are shallow." but it also credits/refrences:
* Raymond, Eric S. The Cathedral and the Bazaar: Release Early, Release Often.
* Also known as Linus's Law

But I think the spirit of referencing the quote is much more important than who said it. It's about the power of participation and tapping into people's passion.

I like to think that in this sense, part of the open source way is defaulting to open and finding a good reason, a really good reason, to not be open. In most cases, you'll achieve better results by being open and transparent as early in the process as possible.

I think the phrase "failing fast," though pithy, brings some negative connotations with it. It's not "failure" to discover discrepancies, uncover opportunities, adapt features to changing demands.

In the realm of flying, an aircraft is considered to be "in trim" when the smaller control surfaces (trim tabs) are adjusted to compensate for cross winds, in order for the pilot's inputs to result in the expected directional changes. These are purely at the whim of the current wind and pressure conditions, and a change in direction, altitude, even speed, can require new trim corrections to be made. Similar concepts govern sailing: sails, balance, and rudder surfaces are frequently adjusted to compensate for the seas. In both situations, a very dynamic environment is responsible for the aviator/sailor to make changes. In neither of these situations is the aviator/sailor said to be "doing it wrong."

I think this applies elsewhere nearly universally. (I'm sure new parents will agree: no matter how many books you read, our own children respond uniquely to our efforts.) What you learned yesterday may not apply today. The world we live in changes constantly. Software users have changing needs, and expectations, and a developer must balance those dynamic needs against stability of the product. All bugs may be "shallow" under the scrutiny of nearly unlimited eyeballs, but the number of proposed fixes are varied as well ... and those expectations change frequently, depending on the defect or enhancement.

In my view, adapting frequently to these myriad demands and expectations shouldn't be viewed as "failures," but as course corrections, without judgment. A change may be good for some, disastrous for others; the solution may be to roll back to the previous state, or innovate further. Rolling back isn't failure, and innovation isn't necessarily successful. Both are adapting to needs that perhaps weren't previously apparent, or conditions that changed rapidly. "Rolling with the punches" is part of working in an open, dynamic environment, and as you said, can be a great strength.

Thanks for the sharing,very insightful comment. I think course corrections, without judgment is a great way of phrasing what happens when things are working.

Vote up!

0

Vote down!

0

DeLisa Alexander | DeLisa is Executive Vice President and Chief People Officer at Red Hat. Under her leadership, this team focuses on acquiring, developing, and retaining talent and enhancing the Red Hat culture and brand. In her nine years with the company, DeLisa has also worked in the Office of General Counsel, where she wrote Red Hat's first subscription agreement and closed the first deals with its OEMs. Today in leading the company's global human resources and

Main menu

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat.

Opensource.com aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. Red Hat and the Shadowman logo are trademarks of Red Hat, Inc., registered in the United States and other countries.