Eric Ries has a great post today: Fear is the mind-killer.  Speed is the best weapon that startups have and Eric describes how fear can slow down the develop process by putting the focus on avoiding embarrassment rather than quickly building great product. 

Eric is ex IMVU where they employed a continuous development process (at least at the start) – deploying direct to production with every commit without extensive testing (more details here).  This is pretty radical at a time when most startups are enjoying the benefits of agile software development when compared with traditional waterfall methodologies, and the challenge they faced at IMVU was getting developers comfortable with the risks associated with deploying direct to production – most notably the fear that they might take the whole site down.  To get over this they asked all new developers to deploy something direct to production on their first day – a kind of shock therapy if you like – and sometimes the site did go down as a result, but overall development moved much more quickly than if they had avoided this risk.

This story captures how fear can slow down development at two levels.  Firstly at a corporate level the fear of embarrassment can result in safeguards being put in place that slowdown product development.  This is often described as having an emphasis on quality and a desire to protect the brand, both of which are laudable ambitions but need to be traded off explicitly against speed of progress, something that doesn’t often happen as fear is an emotion that is frequently denied.

Secondly fear of failure (e.g. taking the site down) can paralyse workers in all fields, and developers are no exception.  If the consequence of introducing a bug is unknown, and could include getting the sack, then it should come as no surprise that some people will be over-cautious and hence move slowly.  As Eric says mitigating the consequences of failure and forcing people to engage in the feared activity more often (e.g. releasing something to production on day one) will help a lot here.

Fear of failure is, of course, not limited to developers and these thoughts apply right across organisations.  The most effective individuals in startups are those who experiment heavily and when they fail make sure they do so quickly and inexpensively.  That way they put themselves in the position to be lucky.  The same is true with startups which usually need to try many different options before they hit on the winning product feature/marketing campaign/market niche/business model etc.etc.

Operating like this requires a confidence that comes naturally to some people and needs to be fostered in others.  Those of us that are involved in the management/direction of startups will do well to seek out people to embrace this modus operandi and to encourage the development of environments that allow others to fear less and move more quickly.

Life in a startup can often seem like living in a pressure cooker and the pressure to deliver short term results can often take the focus away from the bigger picture of building value over 3-5 years – which is enough time to absorb some mistakes.  Twitter is a great case study here – they persisted with a flaky site for a long time and put the emphasis instead on growing usage.

  • MatthewWarneford

    Nic, I think you touched on something interesting:

    ^^ Fear of failure is, of course, not limited to developers and these thoughts apply right across organisations. The most effective individuals in startups are those who experiment heavily and when they fail make sure they do so quickly and inexpensively. ^^

    You're absolutely right about the need for speedy experimentation (and failure) across the *whole* organization. Only its seems that, all too often a businesses processes are structured to manage the greatest perceived risk… missing first customer ship! Will the product be ready in time for the big marketing push!?!

    Look at all the different development methodologies… and the whole ecosystem of project management software, books, conferences, etc thats built to address the challenges of shipping bug free software on time. Even agile methodologies are about reducing the risk of being late.

    This focus on first customer ship is understandable because its measurable. Until the product ships, about the only thing thats measured is the development progress. After all, there is no product to sell or marketing activity. So everyone zooms in on the product development process.

    As a result, the developers and the managers optimize around the fear of missing first customer ship by sticking to 'best practice', padding estimates, and all those activities that slow teams down.

    Whereas, the real risk is whether anyone really wants the product. The biggest mistake a start up can make is spending six months building something no-one wants. No matter how bug free, how many months of crunch time the team endured, or how perfect the code might be.

    So, going back to your comment, the whole company need to be focused on solving the product market fit problem as quickly as possible. Sales can't sell something people don't want. So the whole company needs to figure out what people will spend money on as quickly as possible.

    What the IMVU team seemed to do so well was understand that product market fit is all that matters. And the only want to know what people want is to build and test – and the quicker they get the feedback the more tests they get to run.

    Its a tight feedback loop involving the whole organization.

    So what I think its interesting that there is far more literature dedicated to the problem of development methodology, and managing the schedule risks of software development, than the product market fit risk of software development.

    The one book I encourage everyone to read at my company is the Four Steps to the Epiphany (Steve Blank). Its my most dog eared book… and the only book I've found that addresses how to build a Customer Development Process. Steve describes a process for the whole business to focus on learning who the initial customers will be and what market they're in. Check out his blog, hes only recently started but very good.

    One last though about the article. Its not always about fear of failure. Sometimes its just being bad at part of the process.

    For several years we worked to a typical agile sprint of 1 month. Every month we pushed a release to staging. And every month something went wrong and the deployment process took 2 days.

    To make things worse, we were always behind schedule at the end of the month so we rushed to get features in. Cramming features and a 2 day release process ate up a lot of QA time. As a consequence every release was buggy, and the first week of the next sprint was spent fixing bugs from the last month!

    The problem with bug fixing is that the longer it takes to find the bug the more expensive it is to fix. If I find a bug within an hour of writing the code I can fix it within 5 minutes. If I find a bug 3 weeks later its going to take me a couple of hours to track down.

    We figured that we would get better at deploying, better at estimating, and these problems would go away. Which in theory is true. The problem with month long sprints is we only deployed once a month… thats 12 practices a year.

    So, we took the view that we're not going to get better at deploying if we only do it 12 times a year!

    Now we have a rule, anything we're bad at, we do it more often!

    Sounds like a bad idea at first… but now we deploy several times a week, find bugs quickly, and save lots of time.

    So its not that we were afraid, its that we didn't so the hard things often enough!

    Matt

  • Pingback: Finance Geek » Twitter shows how to manage a crisis()

  • Pingback: Finance Geek » The Customer Development Model()

  • I recently launched into my own gig. My wife said that in week one she thought I was in denial, in week two she thought I was lying to her… but now she sees that I am not gripped by fear (something that might have happened to me in past times of facing the unknown). If it feels right, the trick is to ignore the fear and not invite it inside. Fear is out there lurking.. but you are right that it will slow you down!

  • That's great to hear Thom. Good luck with it.

  • I recently launched into my own gig. My wife said that in week one she thought I was in denial, in week two she thought I was lying to her… but now she sees that I am not gripped by fear (something that might have happened to me in past times of facing the unknown). If it feels right, the trick is to ignore the fear and not invite it inside. Fear is out there lurking.. but you are right that it will slow you down!

  • That's great to hear Thom. Good luck with it.