Moonshine Development Company World Wide Web Log

The Role of Fear: A Startup Retrospective

Posted 25 Feb 2013 to livingsocial, startups, deep thoughts and has Comments

Cross-posted from FindingScience.

While there are plenty of emotions that can affect your psyche while at a startup, I think that fear is one of the most interesting. Unlike passion/ego/etc., I think it is unique in that the role it plays undergoes a dramatic change over time. While that change is decidedly gradual, the mutation is easily noticed, and is quite possibly preventable (which, I contend, is a worthy effort).

Fear as a Motivator

When I began my two year stay at LivingSocial the engineering team had fewer than 10 people (I was number 6). Changes were made to the product (just daily deals at that point) and email systems many times each day. New ideas were constantly being tried to decrease latency, increase efficiency, increase signups, decrease bounces, and everything else you can imagine. There was an understanding that a failure to succeed and dominate could quite easily mean we’d all be looking for new jobs in the near future. That fear of failure was a fantastic motivator to continuously perturb our system with new code, new products, and new approaches in an attempt to find the maximal “steady state” for our product.

That low level continual fear feels somewhat healthy. Forgetting the reality of what a “payoff” may actually mean, knowing that your small group of people has the ability to steer the boat to either rocky shoals or sandy beaches of success is fantastic. The rocks are large and sometimes loom ominously on the horizon - but that’s the adventure. Success may never come in a financial sense, but the possibility of being a part of something awesome can lead you to channel the fear of potential failure into a scrappy tenacity to find success.

It’s not just fear of failure that is the motivator; there’s clearly a fear of what a partial success could mean in the face of failing to “go big” when you had the chance. No one wants to look back months or years later wondering, “Did we do the most we could have with what we had, or did we leave too much on the table?” Fear of future regret can produce a powerful incentive to make sure you’re doing everything you can at every point to take advantage of opportunities.

Fear as the Mind Killer

Eventually, the positive aspects of fear diminish and the negative ones begin to dominate. As the boat gets bigger, the value of the cargo increases, and so does the number of people who think their opinions should help steer the organization (incidentally, this is also the point at which you probably refer to your company as “the organization” or “the org”). Fear of not succeeding is replaced by the fear of losing the success that has already been gained. New hires have never known the fear that their jobs may not be around in a few months unless they and a small group excel at their jobs (though new hires at LivingSocial may now arguably have some of that fear).

Failure is the norm in the beginning. So many ideas are tried that a majority of them are going to naturally be terrible. Once the product reaches that “steady state”, however, and those major changes are no longer being made, the culture shifts. No one wants to fail at anything, especially when so many people are watching. It leads to a type of paralysis that eventually favors group decisions, spread blame/responsibility, and then action only after consensus. No one (understandably) wants to be responsible for breaking anything (which is natural in the beginning), especially when millions of dollars could be on the line.

This culture shift is reinforced internally by demands for consensus. Product changes that once would have just been implemented by an engineer testing something eventually required a room full of product/project/design managers to argue about every change over the course of multiple meetings. Adaptation and maneuvering are simply painful at this point. People become individually tied to specific long-term projects and initiatives, which makes it hard for them to admit when their specific endeavor is failing to meet expectations. Instead of dropping it quickly and moving on to the next idea, they hang on and keep pushing for as long as possible. In the beginning, global success is the most important (without it, no one has a job) so people aren’t so much scared about the success of their own ideas as the success of the company in general. It’s easy to move on to the next idea when all you care about is that some idea ends up being successful, not just your idea’s success. Once the company is stable and established, people will focus more on their own questionable success given that the company will likely still be around even if they fail. This completely shifts the global view of “the antagonist” from external forces (chief competitors, inability to raise money, lack of market penetration, etc) to internal ones (how can I make sure my idea is completed instead of Suzy’s so I can get the raise and promotion).

Mitigating the Mutation

Maintaining flexibility and fluidity is tough once the boat gets big. The shift is natural and may be largely unavoidable. Here are some ideas, though, that may be worth trying:

  • Make sure that your technology choices give you the freedom to make rapid changes and evaluate their effectiveness. The faster you can try/test an idea and branch and bound early, the better. If changes can be made that only affect 1% of the user base, then it’s less likely that multiple meetings of many product/project/design/etc managers will be necessary.
  • Be honest internally. Pick honest metrics for measuring success and stick with them for each internal project. Kill or pivot anything that doesn’t meet goals.
  • Make it easy teams to form into inner startups and rekindle some of the useful, initial fear. Let these teams pitch their ideas (effectively having to “sell” them), give them necessary KPI’s that they have to hit, and then give them (almost) complete autonomy. This is the same model adapted to startups that visionaries like Paul Romer are trying to use to help correct failed states (for a great overview of the process, see the This American Life episode).
  • Artificially perturb the system. You might have big ship with exceptionally valuable cargo - but if you can regularly try crazy ideas (“I know we’ve always done X, but what if we stopped…”) with a small subset of your users/clients/etc then you may be able to keep teams from becoming paralyzed.
  • Know the difference between maintainers and builders in your workforce, and keep the builders happy and a solid percent of the total workforce (“builder” doesn’t necessarily mean “build from scratch” - could be “create some new feature”). It takes a different kind of person and a different set of skills to prototype a new product than you want working on maintaining your primary/static product.

These are a few ideas, but they’re certainly not exhaustive. The role of fear in a startup is an interesting and useful one - but one that has to be monitored and shaped carefully over the long term.

DC RUG Presentation Slides

Posted 13 Nov 2012 to dcrug, moonshine, opbandit and has Comments

I had a lot of fun last Thursday presenting at the DC Ruby Users Group. I covered the basic background for A/B Split Testing, how to evaluate the results of a split test with ABAnalyzer. I then went on to talk about the foundations for Multi-armed bandit optimization and covered the Rails gem Bandit.

My slides from that talk can be found here.

For some additional background, you can check out some of my old posts:

The DC RUG is definitely a great group - you should go to one of their meetings if you haven’t yet. Stop Arguing, Get Fed

Posted 31 Oct 2012 to moonshinedevco, projects and has Comments

We all know the drawbacks of having too many choices. One perfect example of group indecision brought about by the paradox of choice is the eternal question of what’s for lunch. I don’t know, what do you want. I don’t know, what do you feel like. I could eat anything. Me too. Where should we go? I don’t know - do you have any preference? No, do you? Blah blah blah and so on.

Larry Wall says this about the first great virtue of a programmer in the Camel book:

Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer.

Naturally, this means that a program should be created to solve the eternal question once and for all. We’ve called it

At first, I tried to use the Yelp API, but when I requested access to more than 1K hits/day they sent me this:

Hi Brian,
Thanks for your interest, but this is a use case that we can't support. We're typically interested in use cases that are more complementary to than extensions or replications of the Yelp experience. We also ask that API partners refrain from using names that are confusingly similar to Yelp, such as Please refer to the Terms of Use and Display Requirements for more info.

Yelp Partner Relations

There are so many things wrong with this (least of which is the implication that Yelp Roulette somehow replicates existing functionality) - but rather than fight it I figured I could just find a way around using the Yelp API.

Enter the Google Places JavaScript API. I can search for restaurants via JavaScript, randomly select a result, and then send the user along to the Yelp page. The only last hurdle was trying to figure out what the Yelp page is going to be for a given establishment. Thankfully, Google has already figured that out by crawling their entire site, so all I have to do is send a user to Google’s ”I’m Feeling Lucky” page with a specially crafted query, and the user is automagically sent along to the right page on Yelp. Magic! And I didn’t even have to use the Yelp API.

So here’s the one remaining question: Will Yelp thank me for the traffic or send me a take down notice?

Showoff: Github Repo Lists on Pages

Posted 22 Oct 2012 to github, moonshinedevco and has Comments

I was looking around for a decent way to embed github repository information in web pages but couldn’t find anything. All I wanted was the ability to show the same things that are listed for each repo on a user’s homepage, but I wanted to be able to show repos from across accounts (I have code under a few different organizations). I couldn’t find anything, so I created a little Javascript library called showoff.

It’s pretty simple to showoff two repos, each under a different organization. You just give a div you want to fill, and the usernames and repos you want to see.

$(function() { 
  SHOWOFF.load('thewell', { 
      'bmuller': [ 'sexmachine' ], 
      'moonshinedevco': [ 'showoff' ] 

This results in the following display:

It’s not as pretty as the one github shows, but they have their own octicons. If you want to use it, check out the showoff github repo to play.