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