The Role of Fear: A Startup Retrospective

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.

require 'socket'
require 'openssl'

tcp_client = TCPSocket.new "example.com", 443
ssl_client = OpenSSL::SSL::SSLSocket.new tcp_client
ssl_client.connect
cert = OpenSSL::X509::Certificate.new(ssl_client.peer_cert)
ssl_client.sysclose
tcp_client.close
  
certprops = OpenSSL::X509::Name.new(cert.issuer).to_a
issuer = certprops.select { |name, data, type| name == "O" }.first[1]
results = { 
            :valid_on => cert.not_after, 
            :valid_until => cert.not_before, 
            :issuer => issuer, 
            :valid => (ssl_client.verify_result == 0)
          }

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

require 'rubygems'
require 'abanalyzer'

ABAnalyzer.calculate_size(0.1, 0.11, 0.05, 0.8)
 => 14751

ABAnalyzer.confidence_interval(711, 4000, 0.95)
 => [0.1659025512617185, 0.1895974487382815]

ABAnalyzer.relative_confidence_interval(711, 4000, 0.13, 0.95)
 => [0.27617347124398833, 0.45844191337139606]

from genderator.detector import *
d = Detector()

d.getGender('Bob') == MALE # True

d.getGender('Sally') == FEMALE # True

d.getGender('Pauley') == ANDROGYNOUS # True

d.getGender(u'\301lfr\372n') == FEMALE # True

# import the client
from txyam.client import YamClient

# create a new client - hosts are either hostnames (default port of 11211 will be used) or host/port tuples
hosts = [ 'localhost', 'otherhost', ('someotherhost', 123) ]
client = YamClient(hosts)

# Run some commands.  You can use all of the typical get/add/replace/etc
# listed at http://twistedmatrix.com/documents/current/api/twisted.protocols.memcache.MemCacheProtocol.html
client.set('akey', 'avalue').addCallback(someHandler)

# Additionally, you can set / add / get picked objects
client.addPickled('anotherkey', { 'dkey': [1, 2, 3] }, compress=True)
client.getPickled('anotherkey', uncompress=True)

# get stats for all servers
def printStats(stats):
    for host, statlist in stats.items():
        print host, statslist['bytes']
    client.stats().addCallback(printStats)

# import the observer
from txairbrake.observers import AirbrakeLogObserver

# Create observer.  Params are api key, environment, and use SSL.  The last two are optional.
ab = AirbrakeLogObserver("mykey", "production", True)

# start observing errors
ab.start()