(Editor’s note: This is a sponsored article, which means it’s independently written by our editorial team but financially supported by another organisation, in this case, OSCON. If you would like to learn more about sponsored posts on tech.eu, read this and contact us if you’re interested in partnering with us.)
Embracing and learning from failure are popular concepts in tech but it can be difficult to get your approach right. Startups may be terrified of failing while others are never sure how to rebound. At this month’s OSCON in Amsterdam, Leslie Hawthorn, former director of developer relations at Elastic, will be discussing the fears around failing and how to get back on the road to innovation and success.
Also read: Arthur Tolsma shares lessons learned after his first startup failed and consider joining us in Brussels next week for the Failing Forward conference.
tech.eu: Firstly, what was your role at Elastic?
Leslie Hawthorn: While I was at Elastic I was their director of developer relations. I was responsible for the company’s overall outreach strategy to the developer community so this is everything from understanding how to make sure that our offerings, technical documentation etc. were what they needed to be to help increase adoption. Making sure we were giving the right talks at the right conferences to reach out to our audience, spanning the gamut between technical evangelism through to developer marketing.
Your talk at OSCON is called Fear of failing fast: How to avoid sabotaging your success. Can you tell us a little bit about the talk?
The purpose of the talk it to discuss the gaps between some widely held wisdoms in the technology space right now, which is the most important thing you can do in our business is to come up with a minimum viable product, market test it as quickly as possible, fail fast and use whatever feedback we gain to iterate to create better products, better processes. It’s great wisdom. Unfortunately the human element in software and technological development is always going to be more difficult than the actual technical bits. So what we find is that while these are great mantras, actually implementing them is extremely hard because of human nature and because most people’s past experience in the workplace is being punished for failure even while they’re exhorted that failure is completely and totally fine to do.
This talk examines some of the ways in which our communications systems break down around failure and how to make sure your team and organisation are structured to effectively deal with failure and have it not be problematic because if an organisation is not prepared to deal with failure then they’re not prepared to effectively innovate. In general I’m hoping to take the message not only from a team and organisational perspective and also bring it around to the personal level but the goal is to help folks that are leaders in large enterprises to let go and increase their ability to innovative and get over some of those fears of failure.
The concept of embracing failure feels like it’s more widely accepted in the US compared to Europe. Is that a fair assessment?
I think that is a fair assessment. I admit that I’m a bit biased in my views as an American expat living in Amsterdam, I’m here for the past two years now and I’ve been doing business in Europe throughout the latter half of my career. I think there is a much stronger emphasis on the failing fast, specifically with Eric Ries pitching this heavily in his book The Lean Startup and the lean start-up methodology around minimum viable products.
I think I’m starting to see it much more among my European colleagues, very specifically among folks that are practitioners of the DevOps movement. It was actually pioneered by a gentleman in Belgium who put on the first ever DevOps days event about five years ago. He basically asserted that in order for developers and operations professionals to work together successfully, we needed to be able to embrace these principles of failing fast and break down the silos between our teams and have more effective communication. I had actually conceived the concept for this talk while hanging out with some folks in the Amsterdam DevOps community, which is an incredibly active and vibrant community. I think there were 115 people at their last meet-up last month.
What kind of strategies should a startup adopt to effectively overcome failure?
I don’t want to give too much away because I want people to come to see the talk. A lot of it has to do with self-awareness and personal assessment. All organisational changes start with the individual, so understanding ways in which we can, each as individuals, understand our own motivations around success and failure and what our constraints are. A lot of people are afraid of failing because of questions around ego and sense of self. Some people are deeply afraid of failure because of questions of economics.
to be able to parse through where your concern is coming from and then be able to use that to extrapolate to effectively work with other people and create empathy with your team and wider organisation through that self-awareness. The first step in creating an empathetic dialogue within your organisation starts with self-knowledge, self-awareness, and self-assessment.
With all this talk of embracing failure or failing fast, is it ever possible to embrace it too much or go too far?
Absolutely. I think there’s a ton of risk involved in wholeheartedly embracing failure and you can embrace failure too much. I think it’s very easy to talk about embracing failure and failing fast and pivoting when you’re going through the first couple of phases of product iteration that you have to be really conscientious about making sure those failures are actually effectively allowing you to iterate and do so quickly.
Another example is Quirky. I just read a great article assessing why Quirky failed as a startup and declared bankruptcy and the lessons learned for all entrepreneurs. It was largely about learning how you can effectively do a hardware startup.
Their entire model was based on fail fast, figure out what product people would like to bring to market and then call it into being, which was wonderful. On the flipside, because they were trying so hard to make many different products and they were completely unconcerned if a particular product failed to reap sales, once it had gone through its alpha. That whole process of taking in feedback and continuously improving the product wasn’t actually in place, instead what was embraced was the idea of going ahead, piloting something, if it wasn’t an immediate success, then going on and making something different that consumers clearly had a desire for because they were willing to invest in its creation. This ultimately led to the company not effectively being able to market all of their products because there was no one particular niche that they were trying to fill and they also weren’t focused on any one particular product, taking in all the information that could make all their very good alpha into a near-perfect beta market offering.
It’s one thing to embrace failing and failing fast but that’s only if you’re going through the process of taking in that feedback and actually applying it, opposed to going well, that wasn’t quite right, let’s do the next thing and hope that it sticks.
I think a lot of folks mistake the value of pivoting, when in reality an effective pivot is taking the first few iterations of something and then refining it so it makes it not quite what you originally envisioned but it’s close enough or an effective enough change that you’re still keeping your core competency. Something like Glitch to Slack is a perfect example of this. The core competency there was to create a great communication tool and that was the phoenix that rose from the ashes of an online multi-player game that just never took off.
From your own experiences, what types of startups embrace failure better?
That’s a really good question. I think to some degree software fails better than hardware because software by its nature, it’s intangible, it’s easier to create. Also the supply chain for software distribution is so much easier than hardware since there’s no physical object, which is not to say that all technical spaces can’t benefit from the methodology of failing. I think it just creates stronger teams because some people are able to remove some of their ego from the equation, which helps them be better collaborators, more open to sharing, more open to defending ideas rather than being defensive about their ideas. In general because of the dynamics of software and particularly being able to deliver SaaS products, it’s just going to be easier to refine a product in the software realm than in the hardware realm.
Have you attended OSCON before and what have your experiences been like?
I’ve been attending O’Reilly’s OSCON series for almost a decade or so. This is an amazing opportunity to meet some of the brightest stars in the technical sphere and to be able to have quality time, having in-depth discussions, and that’s one thing that O’Reilly’s event series has always been able to bring its audience.
It’s an opportunity to talk to folks, who you will read their but not get the chance to interact with them in person. This is a great opportunity and one the reasons I’m excited to see OSCON come to my new hometown.
tech.eu: The European edition of the open source conference OSCON will be taking place in Amsterdam between October 26 and 28, bringing together some of the biggest players and budding startups from the open source community.
Click here for more information on registering for OSCON.
Featured image credit: Sergey Nivens / Shutterstock
Would you like to write the first comment?
Login to post comments