Thursday, May 7, 2009

Fear is the mind-killer

Fear is an emotion that slows teams down. It makes us more cautious. It makes us over-invest in prevention. It makes us less willing to trust, to communicate openly, and - most painfully - to take risks. It is the dominant reason I see teams fall back on "best practices" which may not be effective, but are at least reassuring. Unfortunately, these actions generally work to increase the batch size of our work, which magnifies the consequences of failure and therefore leads to more fear. Reducing fear is a heuristic we can use to judge process improvements. Anything that reduces fear is likely to speed up the fundamental feedback loop.

The interesting thing about fear is that to reduce it requires two contradictory impulses. First, we can reduce fear by mitigating the consequences of failure. If we construct areas where experimentation is less costly, we can feel safer and therefore try new things. On the other hand, the second main way to reduce fear is to engage in the feared activity more often. By pushing the envelope, we can challenge our assumptions about consequences and get better at what we fear at the same time. Thus, it is sometimes a good idea to reduce fear by slowing down, and sometimes a good idea to reduce fear by speeding up.

To illustrate this point, I want to excerpt a large part of a recent blog post by Owen Rogers, who organized my recent trip to Vancouver. I spent some time with his company before the conference and discussed ways to get started with continuous deployment, including my experience introducing it at IMVU. He summarized that conversation well, so rather than re-tread that material, I'll quote it here:

One thing that I was surprised to learn was that IMVU started out with continuous deployment. They were deploying to production with every commit before they had an automated build server or extensive automated test coverage in place. Intuitively this seemed completely backwards to me - surely it would be better to start with CI, build up the test coverage until it reached an acceptable level and then work on deploying continuously. In retrospect and with a better understanding of their context, their approach makes perfect sense. Moreover, approaching the problem from the direction that I had intuitively is a recipe for never reaching a point where continuous deployment is feasible.

Initially, IMVU sought to quickly build a product that would prove out the soundness of their ideas and test the validity of their business model. Their initial users were super early adopters who were willing to trade quality for access to new features. Getting features and fixes into hands of users was the greatest priority - a test environment would just get in the way and slow down the validation coming from having code running in production. As the product matured, they were able to ratchet up the quality to prevent regression on features that had been truly embraced by their customers.

Second, leveraging a dynamic scripting language (like PHP) for building web applications made it easy to quickly set up a simple, non-disruptive deployment process. There’s no compilation or packaging steps which would generally be performed by an automated build server - just copy and change the symlink.

Third, they evolved ways to selectively expose functionality to sets of users. As Eric said, “at IMVU, ‘release’ is a marketing term”. New functionality could be living in production for days or weeks before being released to the majority of users. They could test, get feedback and refine a new feature with a subset of users until it was ready for wider consumption. Users were not just an extension of the testing team - they were an extension of the product design team.

Understanding these three factors makes it clear as to why continuous deployment was a starting point for IMVU. In contrast, at most organizations - especially those with mature products - high quality is the starting point. It is assumed that users will not tolerate any decrease in quality. Users should only see new functionality once it is ready, fully implemented and thoroughly tested, lest they get a bad impression of the product that could adversely affect the company’s brand. They would rather build the wrong product well than risk this kind of exposure. In this context, the automated test coverage would need to be so good as to render continuous deployment infeasible for most systems. Starting instead from a position where feedback cycle time is the priority and allowing quality to ratchet up as the product matures provides a more natural lead in to continuous deployment.

The rest of the post, which you can read here, discusses the application of these principles to other contexts. I recommend you take a look.

Returning to the topic at hand, I think this example illustrates the tension required to reduce fear. In order to do continuous deployment at IMVU, we had to handle fear two ways:

  1. Reduce consequences - by emphasizing the small number of customers we had, we were able to convince ourselves that exposing them to a half-baked product was not very risky. Although it was painful, we focused our attention on the even bigger risks we were mitigating: the risk that nobody would use our product, the risk that customers wouldn't pay for virtual goods, and the risk that we'd spend years of our lives building something that didn't matter - again.

  2. Fear early, fear often - by actually doing continuous deployment before we were really "ready" for it, we got used to the real benefits and consequences of acting at that pace. On the negative side, we got a visceral feel for the kinds of changes that could really harm customers, like commits that take the whole site down. But on the plus side, we got to see just how powerful it is to be able to ship changes to the product at any hour of the day, to get rapid feedback on new ideas, and to not have to wait for the next "release train" to put your ideas in action. On the whole, it made it easier for us to decide to invest in preventive maintenance (ie the Cluster Immune System) rather than just slow down and accept a larger batch size.
Making this fear-reduction strategy work required more than just the core team getting used to continuous deployment. We eventually discovered (via five whys) that we also had to get each new employee acculturated to a fearless way of thinking. For people we hired from larger companies especially, this was challenging. To get them over that hurdle, we once again turned to the "reduce consequences" and "face your fears" duality.

When a new engineer started at IMVU, I had a simple rule: they had to ship code to production on their first day. It wasn't an absolute rule; if it had to be the second day, that was OK. But if it slipped to the third day, I started to worry. Generally, we'd let them pick their own bug to fix, or, if necessary, assign them something small. As we got better at this, we realized the smaller the better. Either way, it had to be a real bug and it had to be fixed live, in production. For some, this was an absolutely terrifying experience. "What if I take the site down?!" was a common refrain. I tried to make sure we always gave the same answer: "if you manage to take the site down, that's our fault for making it too easy. Either way, we'll learn something interesting."

Because this was such a big cultural change for most new employees, we didn't leave them to sink or swim on their own. We always assigned them a "code mentor" from the ranks of the more established engineers. The idea was that these two people would operate as a unit, with the mentor's job performance during this period evaluated by the performance of the new person. As we continued to find bugs in production caused by new engineers who weren't properly trained, we'd do root cause analysis, and keep making proportional investments in improving the process. As a result, we had a pretty decent curriculum for each mentor to follow to ensure the new employee got up to speed on the most important topics quickly.

These two practices worked together well. For one, it required us to keep our developer sandbox setup procedure simple and automated. Anyone who had served as a code mentor would instinctively be bothered if someone else made a change to the sandbox environment that required special manual setup. Such changes inevitably waste a lot of time, since we generally build a lot more developer sandboxes than we realize. Most importantly, we immediately thrust our new employees into a mindset of reduced fear. We had them imagine the most risky thing they could possibly do - pushing code to production too soon - and then do it.

Here's the key point. I won't pretend that this worked smoothly every time. Some engineers, especially in the early days, did indeed take the site down on their first day. And that was not a lot of fun. But it still turned out OK. We didn't have that many customers, after all. And continuous deployment meant we could react fast and fix the problem quickly. Most importantly, new employees realized that they weren't going to be fired for making a mistake. We'd immediately involve them in the postmortem analysis, and in a lot of cases it was the newcomer themselves (with the help of their mentor) who would would build the prophylactic systems required to prevent the next new person from tripping over that same issue.

Fear slows teams of all sizes down. Even if you have a large team, could you create a sandboxed environment where anyone can make changes that affect a small number of customers? Even as we grew the team at IMVU, we always maintained a rule that anyone could run a split-test without excess approvals as long as the total number of customers affected was below a critical threshold. Could you create a separate release process for small or low-risk commits, so that work that happens in small batches is released faster? My prediction in such a situation is that, over time, an increasing proportion of your commits will become eligible for the fast-track procedure.

Whatever fear-reducing tactics you try, share your results in the comments. Or, if fear's got you paralyzed, share that too. We'll do our best to help.

(with apologies to Frank Herbert)

Reblog this post [with Zemanta]



  2. Would this advice translate equally to businesses where the potential number of customers is small (BtoB rather than BtoC)? where an initial bad impression affects a significantly larger percentage of potential customers.

  3. Interesting article, Eric. I'm an ex-Googler, and now a CTO of a small company with lots of talented people ( I discovered your site not long ago, and I am learning a lot from it.

    This article, like others, has challenged me to think about 'best practices' that I found obvious, a sort of Socratic questioning of the "common sense" that perhaps makes no sense. Thanks for this.

    A few interesting questions come up for me in response to this specific piece:

    (1) Can one really afford to be quite as "fast" and "fearless" with client apps (we have an Android client app, CardioTrainer, and customers get quite upset at bugs which can crash the app and their phone). Client apps are of course harder to continuously deploy plus they are not quite as well sandboxed.

    (2) My greatest fear as a CTO is not actually shipping a single bug to a customer -- this we can fix, but slowly sinking into that famous morass of bugs, where shipping stuff becomes difficult. That's why we do write a good chunk of testing code from the start -- we've noticed that almost wherever we've cut corners we almost inevitably find bugs and it takes longer. If we have a bunch of bugs floating around, we never know how long it will take to fix them all. In summary, I wonder where TDD fits into all of this -- as you've stated before you are a big fan. Do you mean continuously deploy well-tested code? Or perhaps make experimental branch after experimental branch? It would be great to hear your thoughts on this. Thanks.

  4. Great post.

    I've noticed that "starting small and immediately" is good tried and true tactic for mini and micro start-ups. Its great to get past the over analysis and fear of starting that so many "would be" entrepreneurs go through.

    as a seperate little < rant >, of late I found myself in similar conversations regularly about brand image and really being "yourself" or being authentic. For a couple of clients this concept seems counter-intuitive and quite frankly instills alot of fear that they might not be accepted for who they are. Obviously they're not voicing their objections that way, but it isn't hard to read between the lines.

    In the case of an entrepreneur pitching for finance, its the same fear that has them putting on a facade and not comfortable in what they do and dont know that will see them a long way off getting funded. The same reason they aren't able to retain an "A" team. The sheen only lasts so long, the bs goes stale and crumbles, and spin, if you stare at it long enough you can see through it anyway. The point is _its okay to not know EVERYTHING_

    The next wave of entrepreneurs will all have to face their fears and be EXACTLY who they are, and commit to BEING and BECOMING better in order to get ahead. but you've got to acknowledge your flaws and make a journey of plugging the holes for all to read/watch/hear about.

    For some reason, most are way too insecure and scared to just let it all hang out and be judged on whatever they happen to be.

    < /rant >

    Im Nick btw, nice to meet you all :) & great post again, cheers.

  5. Great post. The first paragraph alone is advice good enough to live by.

  6. I agree with Jason, the first paragraph not only applies to business practices, but to life in general. "The remedy, is the experience"

  7. 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!