After 4 years of building, fixing, and managing software, I’ve come to realize that the default state of everything is failure.

Chances are that your fancy feature doesn’t work when you first ship.  That new process probably has plenty of holes in it.   Everything is a work in progress, and your world is in perpetual beta.

In startup life, there are TWO worlds you live in.  One that celebrates your successes — i.e. when you raise money, when you get press.  One where the sky is falling and nothing goes right — when your site goes down,  when a new feature is delayed.  The fundamental dichotomy of startup life is that you are building a business — an act that is so bold with so much ground to cover — that you are simultaneously living as a success AND as a failure all at once.

That can be a difficult thing to accept.  I’ve distilled two personal maxims to help accept this dichotomy:

1. You can’t be upset when things don’t work.
2. Find shit that doesn’t work.  Always be testing.  Test your boundaries.  Test the boundaries of others.  Test your features.  Do performance load testing.  Test your process.  Look for balls that others’ve dropped.   Test the character of your team.  Test their morale.  Test your VCs.  Push the boundaries on everything.

Equanimity is not easy to come by, but, once you’ve accepted that you need to test your boundaries, and you don’t get upset when you find that boundaries are facades, you can get to work fixing things.  You invest in automation.  You set aside time to find holes. Acceptance is hugely liberating, to the point where I believe that not being upset when things are broken is one of the most visible signs of maturation of a teams execution.  THEN, and ONLY THEN, you can actually get shit done.