Quantum Mechanics of Software

One of the most fundamental human desires to believe that something is either A or B, and many complex endeavors are compromised from the beginning by treating the A/B split as a first principle. Binary logic may explain well-understood processes, but eventually the old rules cease to apply, as with the failure of classical physics to explain phenomena at atomic and subatomic scales.  To understand quantum theory, you have to accept the wave-particle duality, and even then, it turns out that no one really knows why light exhibits both wave and particle properties.  We can observe, even predict, but not quite explain.

Startups are subject to similarly misunderstood dualities.  Simple minds want to know if winning depends more on doing A or B:  Should we move fast, or ship quality? Build footprint or monetize?  Optimize on breadth or depth?  The winner, however, realizes that you have to figure out a way to do both.  How this is accomplished is highly contextualized in practice, but it begins with the realization that you cannot have one without the other and hope to succeed.  If it were as simple as doing only one thing well, the success rate of venture capital would be much greater than 10%. And when you do succeed, as in quantum mechanics, recognizing that things work a certain way is more important than knowing why (for the purposes at hand, at least).

A venture also displays both continuous and discrete elements.  From a wide angle, the growth curve or product lifecycle may resemble a wave function, but it’s also extremely iterative, and is most efficient when individual iterations occur at consistent intervals.  Likewise, one characteristic is often expressed through the other, much as particle emissions are dependent on wave functions. The focus and abstraction needed to go broader also allows you to go deeper effectively.  Similarly, in the course of developing a vertical solution, you often end up sharpening your intuition about how slice the problem horizontally.

When striving to achieve both A and B, you often need to consciously set up opposing forces to achieve your goals.  For example, you need hackers who are relentlessly focused on solving the customer’s problems, even if they’re comparatively poor at productization and long-term code stability, and you need artists who are relentlessly focused on productization and pristine architecture even if their sense of customer urgency leaves a lot to be desired.  How you make them work together productively is an art - there is always some violence, but it starts by recognizing you need both, and accepting that their interactions only need to be productive, not harmonious.  The results of this type of particle collision are very difficult to know ex ante, so the safest bet is to find the best exemplars you can of each type – people you would want to work with individually.

The need to harness opposing forces sometimes extends beyond types of goal orientation to personality types (though these often go hand in hand).  Again, it’s up for debate why this is the case, but the anecdotal evidence is extensive.  The classic example from quantum physics is Richard Feynman and Murray Gell-Mann’s collaboration on the theory of beta decay.  Feynman was famously mischievous and irrepressible, while Gell-Mann was almost painfully serious and methodical.  While they frequently found each other exasperating, their tension was tempered by strong mutual respect – an obvious but sometimes overlooked component in organizational design.

Conventional high-tech wisdom posits that among the qualities of “better”, “faster”, and “cheaper” you can only pick two.  With the right team, you can do extraordinary and counterintuitive things. You can be better, faster, and cheaper – you just can’t be better, faster, cheaper, and also comfortable, which is the true contradiction. At the risk of resorting to truisms, doing hard things is hard - comfort is simply not part of the equation.  As Feynman himself once quipped, “You don’t like it, go somewhere else!