Fear is the mind killer
Upcoming SlideShare
Loading in...5

Fear is the mind killer






Total Views
Views on SlideShare
Embed Views



1 Embed 2

https://eat1-searchindev01.linkedin.biz 2



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

     Fear is the mind killer Fear is the mind killer Document Transcript

    • Lessons Learned: Fear is the mind-killer 30/06/10 7:15 PM Share Report Abuse Next Blog» Lessons Learned by Eric Ries THURSDAY, MAY 7, 2009 Subscribe via email Fear is the mind-killer Enter your email address: 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 Subscribe take risks. It is the dominant reason I see teams fall back on "best or, add to Google Reader: 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 Blog Archive to judge process improvements. Anything that reduces fear is likely ► 2010 (35) to speed up the fundamental feedback loop. ▼ 2009 (88) ► December (4) The interesting thing about fear is that to reduce it requires two contradictory impulses. First, we can reduce fear by mitigating the ► November (1) consequences of failure. If we construct areas where ► October (7) experimentation is less costly, we can feel safer and therefore try ► September (9) 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 ► August (8) envelope, we can challenge our assumptions about consequences and ► July (8) get better at what we fear at the same time. Thus, it is sometimes a ► June (7) good idea to reduce fear by slowing down, and sometimes a good ▼ May (8) idea to reduce fear by speeding up. Austin: the Lean Startup tour continues 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 The Lean Startup at SIPA Vancouver. I spent some time with his company before the follow-up conference and discussed ways to get started with continuous Last chance to register for The deployment, including my experience introducing it at IMVU. He Lean Startup at HP... summarized that conversation well, so rather than re-tread that The Lean Startup Workshop - material, Ill quote it here: now an OReilly Master... Fear is the mind-killer One thing that I was surprised to learn was that IMVU started out with continuous deployment. They were deploying to More video "what to do if production with every commit before they had an automated customers dont like you... build server or extensive automated test coverage in place. Videos galore Intuitively this seemed completely backwards to me - surely it would be better to start with CI, build up the test coverage Lean Startup webcast post- until it reached an acceptable level and then work on deploying game continuously. In retrospect and with a better understanding of their context, their approach makes perfect sense. Moreover, ► April (5) approaching the problem from the direction that I had ► March (11) intuitively is a recipe for never reaching a point where ► February (10) continuous deployment is feasible. ► January (10) Initially, IMVU sought to quickly build a product that would prove out the soundness of their ideas and test the validity of ► 2008 (59) their business model. Their initial users were super early adopters who were willing to trade quality for access to new Labels features. Getting features and fixes into hands of users was the greatest priority - a test environment would just get in the way agile (8) and slow down the validation coming from having code runninghttp://www.startuplessonslearned.com/2009/05/fear-is-mind-killer.html Page 1 of 7
    • Lessons Learned: Fear is the mind-killer 30/06/10 7:15 PM and slow down the validation coming from having code running audio (3) in production. As the product matured, they were able to ratchet up the quality to prevent regression on features that case study (2) had been truly embraced by their customers. continuous deployment (10) Second, leveraging a dynamic scripting language (like PHP) for building web applications made it easy to quickly set up a customer development (11) simple, non-disruptive deployment process. There’s no engagement (3) compilation or packaging steps which would generally be performed by an automated build server - just copy and change events (35) the symlink. five whys root cause analysis (6) Third, they evolved ways to selectively expose functionality to hiring (5) sets of users. As Eric said, “at IMVU, ‘release’ is a marketing term”. New functionality could be living in production for days iPhone (3) or weeks before being released to the majority of users. They lean startup (12) could test, get feedback and refine a new feature with a subset of users until it was ready for wider consumption. Users were listening to customers (10) not just an extension of the testing team - they were an minimum viable product (4) extension of the product design team. product development (19) Understanding these three factors makes it clear as to why continuous deployment was a starting point for IMVU. In recommended reading (5) contrast, at most organizations - especially those with mature search engine marketing (5) products - high quality is the starting point. It is assumed that users will not tolerate any decrease in quality. Users should slides (11) only see new functionality once it is ready, fully implemented sllconf (10) and thoroughly tested, lest they get a bad impression of the product that could adversely affect the company’s brand. They split-test (5) would rather build the wrong product well than risk this kind of startup visa (7) exposure. In this context, the automated test coverage would need to be so good as to render continuous deployment Test-driven development (8) infeasible for most systems. Starting instead from a position video (8) where feedback cycle time is the priority and allowing quality to ratchet up as the product matures provides a more natural virtual goods (2) lead in to continuous deployment. About Lessons Learned The rest of the post, which you can read here, discusses the Welcome to Lessons Learned by application of these principles to other contexts. I recommend you Eric Ries. Want to learn more about take a look. me? Try About the author. Trying to learn more about lean startups? Returning to the topic at hand, I think this example illustrates the See Four Myths about the Lean tension required to reduce fear. In order to do continuous Startup or The lean startup. deployment at IMVU, we had to handle fear two ways: Get in touch: 1. Reduce consequences - by emphasizing the small number of Twitter customers we had, we were able to convince ourselves that Email exposing them to a half-baked product was not very risky. Although it was painful, we focused our attention on the even Facebook bigger risks we were mitigating: the risk that nobody would Linkedin use our product, the risk that customers wouldnt pay for virtual goods, and the risk that wed spend years of our lives building something that didnt matter - again. Additional resources 2. Fear early, fear often - by actually doing continuous deployment before we were really "ready" for it, we got used Startup Lessons Learned, to the real benefits and consequences of acting at that pace. All Seasons: Every post On the negative side, we got a visceral feel for the kinds of from the blog, in one 600+ page PDF. changes that could really harm customers, like commits that take the whole site down. But on the plus side, we got to see Startup Lessons Learned just how powerful it is to be able to ship changes to the season one: Every post product at any hour of the day, to get rapid feedback on new from the blogs first year ideas, and to not have to wait for the next "release train" to in print form. put your ideas in action. On the whole, it made it easier for us Startup Lessons Learned for to decide to invest in preventive maintenance (ie the Cluster Kindle Immune System) rather than just slow down and accept ahttp://www.startuplessonslearned.com/2009/05/fear-is-mind-killer.html Page 2 of 7
    • Lessons Learned: Fear is the mind-killer 30/06/10 7:15 PM Immune System) rather than just slow down and accept a Startup Lessons Learned - the larger batch size. conference. April 23, 2010 in San Francisco. Making this fear-reduction strategy work required more than just the core team getting used to continuous deployment. We eventually Lean Startup Wiki - including a discovered (via five whys) that we also had to get each new complete list of local meetups employee acculturated to a fearless way of thinking. For people we and meetup organizers. hired from larger companies especially, this was challenging. To get Lean Startup Circle - a mailing them over that hurdle, we once again turned to the "reduce list of dedicated and helpful consequences" and "face your fears" duality. entrepreneurs. Bring your questions. When a new engineer started at IMVU, I had a simple rule: they had to ship code to production on their first day. It wasnt an absolute FeedBurner FeedCount 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, wed 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 @ericries on Twitter had to be a real bug and it had to be fixed live, in production. For Terrible iPhone 4 bug today: gets some, this was an absolutely terrifying experience. "What if I take stuck in an endless loop with the site down?!" was a common refrain. I tried to make sure we hotel wifi that redirects via SSL. always gave the same answer: "if you manage to take the site down, Had to reboot. about an hour ago thats our fault for making it too easy. Either way, well learn @zburt afraid not, but sounds something interesting." like a great event about 9 hours ago Because this was such a big cultural change for most new employees, more updates... we didnt leave them to sink or swim on their own. We always assigned them a "code mentor" from the ranks of the more Facebook Fans established engineers. The idea was that these two people would operate as a unit, with the mentors job performance during this Startup Lessons period evaluated by the performance of the new person. As we Learned on Facebook continued to find bugs in production caused by new engineers who Like werent properly trained, wed do root cause analysis, and keep making proportional investments in improving the process. As a Startup Lessons Learned has 676 fans 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. Shaherose Greg Enrique John 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 Burton Jimmy J Nicholas Elodie environment that required special manual setup. Such changes inevitably waste a lot of time, since we generally build a lot more Recent & Upcoming Events developer sandboxes than we realize. Most importantly, we immediately thrust our new employees into a mindset of reduced 2010 fear. We had them imagine the most risky thing they could possibly I am experimenting with using do - pushing code to production too soon - and then do it. Plancast to track my 2010 event schedule. Take a look and let me Heres the key point. I wont pretend that this worked smoothly every know what you think. 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 2009 show still turned out OK. We didnt 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 Amazon they werent going to be fired for making a mistake. Wed 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.http://www.startuplessonslearned.com/2009/05/fear-is-mind-killer.html Page 3 of 7
    • Lessons Learned: Fear is the mind-killer 30/06/10 7:15 PM 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 fears got you paralyzed, share that too. Well do our best to help. (with apologies to Frank Herbert) Related articles by Zemanta Work in small batches (startuplessonslearned.blogspot.com) Continuous deployment in 5 easy steps (radar.oreilly.com) 2009 05 01 How To Build A Lean Startup Step By Step (slideshare.net) Continuous integration step-by-step (startuplessonslearned.blogspot.com) Like Be the first of your friends to like this. Labels: continuous deployment 9 comments: Anonymous said... http://500hats.typepad.com/500blogs/2008/10/fear-is-the- min.html May 11, 2009 9:04 PM Ian Wilson said... 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. May 11, 2009 9:42 PM Artem said... Interesting article, Eric. Im an ex-Googler, and now a CTO of a small company with lots of talented people (http://www.worksmartlabs.com/). I discovered your site not long ago, and I am learning a lot from it. This article, like others, has challenged me to think abouthttp://www.startuplessonslearned.com/2009/05/fear-is-mind-killer.html Page 4 of 7
    • Lessons Learned: Fear is the mind-killer 30/06/10 7:15 PM 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. Thats why we do write a good chunk of testing code from the start -- weve noticed that almost wherever weve 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 youve 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. May 11, 2009 10:12 PM Nicholas Kormas said... Great post. Ive 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 theyre not voicing their objections that way, but it isnt 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 arent 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 youve got to acknowledge your flaws and make a journey of plugging the holes for all to read/watch/hear about.http://www.startuplessonslearned.com/2009/05/fear-is-mind-killer.html Page 5 of 7
    • Lessons Learned: Fear is the mind-killer 30/06/10 7:15 PM 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. May 13, 2009 6:38 AM Jason Lander said... Great post. The first paragraph alone is advice good enough to live by. May 14, 2009 10:05 PM Jeff said... I agree with Jason, the first paragraph not only applies to business practices, but to life in general. "The remedy, is the experience" May 16, 2009 10:22 AM Jeff said... I agree with Jason, the first paragraph not only applies to business practices, but to life in general. "The remedy, is the experience" May 16, 2009 10:22 AM Jeff said... I agree with Jason, the first paragraph not only applies to business practices, but to life in general. "The remedy, is the experience" May 16, 2009 10:22 AM Thom Singer said... 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! May 25, 2009 4:31 AM Post a Commenthttp://www.startuplessonslearned.com/2009/05/fear-is-mind-killer.html Page 6 of 7
    • Lessons Learned: Fear is the mind-killer 30/06/10 7:15 PM Comment as: Select profile... Post Comment Preview Newer Post Home Older Post Subscribe to: Post Comments (Atom)http://www.startuplessonslearned.com/2009/05/fear-is-mind-killer.html Page 7 of 7