Shyam Sankar

If you have more than a passing interest in the future – be it yours, your venture’s, or humanity’s writ large - Peter Thiel’s CS183 lecture #13, “You Are Not A Lottery Ticket” is a feast for thought.  Thiel interrogates the underpinnings and consequences of determinate and indeterminate worldviews in numerous contexts, including as they apply to startups. 

For the aspiring tech entrepreneur, one of the most useful frameworks Thiel invokes is that of calculus (determinate) vs. statistics (indeterminate).  In calculus, you make precise determinations, often concerning discrete futures.  You can figure out exactly how long it will take to drain even the most irregularly shaped swimming pool.  And this enables you to do things of vital importance.  As Thiel notes, when you send a rocket to the moon, you need to know where it is at all times – you can’t just figure it out as you go.  In statistics, on the other hand, there are no certainties.  It’s about bell curves, random walks, and drawing an often uncomfortable line of best fit between limited data points.  Thiel furthermore notes a powerful societal shift towards the belief that statistical thinking ways of thinking will (and should) drive the future.   

The example of landing a rocket on the moon is probably no accident. The 1950s and 1960s (coincidentally the first golden age of Silicon Valley) were a time of widespread American optimism.  The moon landing was a fundamentally optimistic venture that captured the American imagination (and quite literally would not have happened without calculus).  It only makes sense, then, that statistics would be the dominant modality of the cynical world we now inhabit.  If you look at the natural disasters, economic collapses, terrorist attacks, and disease outbreaks of the 21^st century, some might seem more or less predictable by conventional wisdom, but the popular perception is that humanity was caught napping, apart from a few obscure Cassandras.  Especially in light of the truism that we’re usually planning for the crisis that just happened, it’s easy to see the appeal of the indeterminate/statistical model.  Statistics couldn’t have predicted exactly which bad things would happen, only that some bad things would happen.  

It’s enough to make you throw up your hands, yet this is exactly what Thiel is not arguing for.  This should come as no surprise. Thiel is a renowned contrarian, and many of his greatest interests reflect a healthy disregard for statistical/indeterminate thinking, life extension being a prime example.  The conclusion of the lecture begins with an acknowledgment that as we embrace the statistical worldview, society is sliding into pessimism, and without indulging in too much pop psychology, it’s easy to see how such thinking becomes self-fulfilling.  The lecture ends with an appeal to “definite optimism”, and posits that computer science offers the best hope.  CS is not only a great way to solve problems, but as Thiel observes, its fundamental determinism may have something to teach startup culture, which is widely presumed to be governed by indeterminacy.

Of course, software itself is greatly misunderstood, and this is one of the primary challenges computer scientists face as entrepreneurs. People who don’t understand software assume that its value is statistical by nature, and fundamentally unknowable (in contrast to hardware, for example).  If you’re a math phobic, single-variable calculus and E = mc² are just two things you don’t understand, and the differences and relative complexities are immaterial.  To make matters worse, people who truly understand software are relatively rare, especially among those with purchasing authority, and this unknowable fallacy leads to a sort of permanent agnosticism in principle as applied to software.  Within the statistical frame, it’s assumed that two competing software packages lie in the same general area of the bell curve, and therefore the differences are negligible or at least unknowable.  You know that the value of software follows power laws and the differences between good and great are logarithmic, not linear, but the statistical frame ignores all of this.

One consequence is extreme risk aversion: if you believe that the relative merit of one kind of software isn’t calculable, you stick with what you already have, and this has plagued many otherwise forward-thinking institutions.  There is also the simple matter of what’s tangible.  To the layman, hardware seems straightforward, whereas software doesn’t (even if hardware may owe much of its performance to superior software).  As a result, hardware is often seen as a reasonable expenditure, whereas software isn’t.  No one blinks at a $50 million aircraft, even if that aircraft is agreed to be 1980s technology, whereas $50 million for software is not only unthinkable to many, but being newer and better may very well work against you, due to the unknowable fallacy.  

For the aspiring software entrepreneur, there are a few takeaways.  It’s a fact of life that software is misunderstood and undervalued.  However, that doesn’t mean quality doesn’t matter.  In fact, it matters more than ever.  The challenge is that when you are up against a heavy incumbent, it’s not enough to be 10% better – you have to be 10X better, because ultimately your success is dependent on enough people feeling strongly enough about your product to risk rocking the boat.  Earlier we discussed that the idea of any complex product being great enough to sell itself is a myth, and again, concluding that being great is unimportant is absolutely the wrong lesson.  Put another way, if you want to bring people around to viewing software through a calculus frame, you have to make their daily existence demonstrably better.  But wasn’t this always the goal?

This brings up a final point about determinacy: some things are worth doing regardless.  In the last CS 183 class, “Stagnation or Singularity?”, Thiel is joined by several guests, including Dr. Aubrey de Grey, gerontology expert and Chief Science Officer at the SENS Foundation.  De Grey makes the point that while we may have a fair idea what technologies will be developed, the timeline for development is much more tenuous and subject to various externalities.  However, he concludes (paraphrased), “In a sense, none of this matters. The uncertainty of the timeline should not affect prioritization. We should be doing the same things regardless.”

Once again, it all comes down to doing important things, and when this is the stated goal, the inherent pessimism of the statistical approach becomes apparent.  This applies to your own life as well as it does when building a company.  If you wanted to take the statistical view to its logical extreme and hedge against all possible uncertainties, you’d become a jack of all trades/master of none, and consciously choose not to go long on any particular superpower or world-changing problem. If the goal is to live an inoffensive, comfortable life, this might makes sense.  If you want to do anything of lasting value, this is crazy.  In some ways, it’s easier to grasp this concept when designing new technology or building a company – although it’s easy to suffer from too many features or too many business models, most entrepreneurs accept that trying to be all things to all people is a recipe for failure (as software development illustrates so neatly).  Technology needs a problem to solve.  You, on the other hand, are not a problem to be solved – yet what to do with your time and gifts is perhaps the most worthwhile problem of all.

Execution is hard, and distribution is one of the hardest (and not surprisingly, least understood) aspects of execution.  Peter Thiel gives the subject of distribution an extremely thorough treatment in CS183 Lecture 9, “If You Build It, Will They Come?”, including mathematics, psychology, and market-specific models.  Rather than trying to summarize the extensive substance of the lecture, I’d like to focus on how you might think of the distribution challenge as an engineer, in the context of the Your Future series.

Thiel begins by addressing the most basic question – what is distribution? Surprisingly, many people can’t give you a coherent answer, and if they can, there’s a very good chance they underestimate its importance.   If we agree to define distribution as how you get a product out to customers, it becomes a bit more concrete why there’s so much misunderstanding around the topic.  It’s especially difficult when you’re creating software or other technologies that require meaningful user engagement.  If you think of distribution as just getting a product into users’ hands, you’ll likely fail – either because you assume that a product will get used just by virtue of being available, or that the product will remain in users’ hands once it’s reached them.

If you look at two of Thiel’s biggest success stories to date, PayPal and Facebook, you’ll find two companies that nailed distribution, and in very different ways.  It’s worth noting that online payments and social networking sites were both extremely noisy spaces when PayPal and Facebook joined the fray, and neither company had first mover advantage (though as Thiel discusses elsewhere, this may not be such an advantage after all).  Also significant is the fact that online payment processing and social networking sites are both fairly easy to prototype and hack away at.  Of course both PayPal and Facebook hired outstanding engineers and eventually encountered (and overcame) serious technical hurdles – security/fraud in the case of PayPal and scale in the case of Facebook – but I’d argue that those problems only emerged because they got distribution right first.  

As Thiel calls out early in the lecture, engineering bias works against you when it comes to distribution.  As engineers, we are conditioned to think that great products will just reach consumers by virtue of being great (and there’s a dangerous tendency to assume that your idea of “great” is representative).  The concept of a product being “so good it sells itself” is universally appealing - and universally incorrect.  It just doesn’t happen.  It is possible to create an environment where the best idea wins within the confines of your own company, and I urge you to retain this form of idealism, but any market is a fundamentally irrational place, and you need to make peace with that fact.  

Another major difficulty is that so many young engineers in Silicon Valley have been spoon-fed a massive user base, either because they joined a company that already had one, or they piggybacked on one.  Of course, this is a valid distribution channel – the path of least resistance is by no means the wrong approach.  The problem is that it skews the way you think about design and innovation.  Most engineers in non-entrepreneurial roles haven’t had to think about distribution at all.  And that’s fine, as long as you realize that you started on 3^rd base and didn’t hit a home run—not for the sake of your ego, but for the sake of your next venture.  You have to approach the might distribution challenge with the humility it deserves, so suffer at her hands.

Whether distribution can really be “engineered” is a topic for another day, but it worth thinking about what makes engineering different from sales, and for the aspiring founder, this is one of the biggest takeaways from the lecture.  I’m not so much concerned with the merits of different distribution approaches as with recognizing the how the skill of distribution (to include sales) lines up with your and your team’s strengths and weaknesses.  It’s no secret that I’m a huge fan of engineering-driven companies, but it’s not enough to focus on your strengths – you also have to even out the competencies you lack, and chances are sales/distribution is among these.  

Why is this? As Thiel notes, sales is a fundamentally irrational enterprise, and engineers are concerned with rationality and truth-telling.  However, their general discomfort with and lack of aptitude for sales isn’t just about purity of spirit, but also about knowing what to look for.  In many cases, it’s not clear what quantifiable skills are actually involved in “sales.” (hint: this ain’t it: Crazy Ernie).  If you convince yourself that these skills aren’t important, or don’t have a place in the kind of utopian company you want to create, you not only ignore one of the central aspects of distribution, but also create a huge talent gap, because you need at least a few folks with these skills.  Think of it as a special sort of project management skill—the ability to get a distribution project across the finish line.  A crude model, but useful in framing the challenge for us engineers.

There are many risks inherent in the worthy goal of starting a company: team risk, innovation risk, technical execution risk, and business execution/distribution risk.  In addition to the first three, distribution is something you need to be thinking about in the foundational stage, not something to be revisited at an undefined point in the future.  Importantly and subtly, distribution risk affects innovation and technical risk in turn - and every form of risk is ultimately a team risk.  Feedback from the field/your customers becomes the fuel (to your creative mind’s spark) for iterating and conquering – you will be on an empty tank without distribution.  If you’re trying to start something, it’s almost more important to ask who on your team is credible in each of these areas than how you’ll specifically get there.  

Mark Twain was said to have remarked “I have never let my schooling interfere with my education”, and whether the quote itself is apocryphal, the sentiment should be applauded.  True education is a beautiful thing. A master’s degree, on the other hand, is not only a waste of time (with a few exceptions I’ll get to), but often epitomizes that proverbial interference.  

As I spend a lot of time talking to college students I encounter many who are signing up for the increasingly popular one-year master’s degrees.  I understand the appeal from the student’s perspective and I understand the appeal from a parent’s perspective.  In fact, I pursued one myself.  I had just finished undergrad, I didn’t have a compelling opportunity, and more importantly I had somewhere to get to (Silicon Valley).  For many of today’s brightest engineers, I don’t think a master’s degree makes any sense, and that was exactly the advice I gave my brother who just graduated.  In order to appreciate why a master’s might not be such a wise idea after all, it’s worth considering what makes education meaningful to begin with.  

To begin with, education creates opportunity.  This has probably been drilled into your head from an early age, and for good reason.   If your parents were the first generation in your family to attend college (or you are) this needs no explanation, and it’s a tragedy that education is taken for granted by anyone, let alone so many.

There is also much to learn – much more than most people would ever guess.  When I went off to college, I certainly thought I knew more than I did.  Being disabused of this notion may seem like the first step in one’s education, and it often is, but it’s a really a lesson worth relearning at any stage.  Then there’s the process of learning how to learn, and this is one of the primary reasons you go to school, independent of your field of study.  There are countless dimensions: learning to make abstractions and conceptualize, to interrogate a problem, to work inductively and deductively, to separate first principles from careless assumptions.  You need to experience breadth, both to strengthen your foundation, and to find subjects worthy of exploring in depth.  

Education also provides a unique platform to gain impactful life experience in a low-risk environment.  School is a place to build formative relationships, explore different paths, be in charge of your own time and activities, even start something if you are so inclined.  Perhaps most importantly, it’s a time to learn about your strengths and weaknesses with high upside and low downside.  Of course, college is costly, and time itself is far from trivial, but it’s much easier to avoid loss aversion and do something truly experimental when you’re not deep into your career.   The phrase “do something” is the key here – “finding yourself” has become sort of a cliché of indolence, but it’s while moving forward that you truly find yourself, and college can be the perfect place to do this.

Finally, education validates that your best years really are ahead of you.  High school is certainly a valuable experience, and in the best case can lay the groundwork for the level of exploration that college makes possible.  At the same time, it’s a small pond both socially and in terms of what you’re asked to do.  However triumphant or painful it is, it’s not a place to remain.  College may feel like a time for reinvention, but it’s really a time for original discovery.  

 To understand why master’s degrees are superfluous and even counterproductive for engineering students, I like to use the framework of getting somewhere versus getting something.  You can also think of this as a means to an end as opposed to an end in itself.  Education provides many things of intrinsic value, but much as nine months, give or take, is enough to prepare you for the outside world, so is one degree.

The exceptions tend to fall into the category of getting somewhere: for example to Silicon Valley or to the United States.  A master’s degree can also be a good way to test the waters of academia.  You can take classes with doctoral students and get a feel for the academic life without having to commit to a dissertation or taking on a teaching schedule.  For some friends, a master’s has been an informative gateway to a promising academic career, whereas others consider it worth the price of admission to have been persuaded that doctoral studies aren’t for them after only a year.  I am not coming down on one side or the other, only advocating for informed choices.

On the other hand, if you’re trying to obtain something – experience, distinction, deeper cultivation of your superpower – it’s usually better to just get that thing in its pure form.  If you want entrepreneurial experience, go out and get some – don’t learn about it in an MBA course.  If you want to be a better software engineer, don’t sign on for an extra year of TAing - work on challenging, real-world problems in a production environment, with peers who force you to raise your game.  

I’ve said before that learning for its own sake is not necessarily valuable, and this is especially true of master’s degrees in the workplace, especially degrees in one pure subject (as opposed to MBAs and other first professional degrees).  There is a lot of misleading and unsubstantiated chatter that a master’s degree makes you a more valuable employee ipso facto, and this is just not the case, as many people find out the hard way.

It’s also worth acknowledging that there is often a socio-cultural bias towards more education, especially among generations who experienced firsthand the power of education to achieve an objectively better life.  This is not a perspective to be discounted, but at the same time you need to recognize when the preference for more higher education is no longer contextualized and ignores the question of somewhere versus something. 

Finally, and most importantly, don’t do a master’s because college is fun and it will never get better than this.  If you care about your future as much as I imagine you do, that simply won’t be true (regardless of whatever sentimental projections people offer you).  The fifth year isn’t like the fourth.  Everyone is gone, and you realize that what made college meaningful was the people who went through the experience with you, not the buildings and the campus.  Moving on is not always easy, especially when you strip away the structure and predictability of school, but it’s simply time to forge new experiences.  If there’s one thing I’ve learned since leaving school, it’s that they can all be the best years of your life when you get out there and Do Important Things.

When you are doing something truly disruptive, you are in a David versus Goliath situation (and this is especially true for technology).  The story of David is highly instructive for anyone who aspires to do world-changing things, and its lessons go much deeper than an inspirational tale of the little guy beating the big guy.  

Let’s begin with the obvious: David wins by not playing by Goliath's rules.  He doesn't out-muscle Goliath, instead fighting a lightweight, guerrilla style insurgency.  David is Exhibit A for the theory that speed, wits, and the ability to adapt can trump size, resources, and heavy armament.  After felling Goliath with his slingshot, he beheads him with his own massive sword (a gory but potent bit of symbolism often left out of the retelling).  

However, David’s selection as champion of the Israelites and his rise to field commander were unconventional, even revolutionary acts in themselves.  In fact, almost every key event of David’s ascendancy was highly unlikely.  It began when the prophet Samuel sought out Jesse of Bethlehem, believing that one of his sons would become king of the Israelites.  Samuel rejected each of Jesse’s grown sons in turn before Jesse reluctantly presented David, his youngest son and a mere shepherd.  Anointed by Samuel, David went to the court of King Saul, initially as his armor-bearer.  Yet it was as a musician that David made himself indispensable to Saul, healing his afflictions with his sublime harping.  When war broke out with the Philistines, David was not even asked to fight at first, instead going home to tend his father’s sheep.   When David arrived at the front to answer the call, he faced fierce opposition from within the Israelite ranks, chiefly from his own brothers.  I suspect that when Saul, not renowned for his piety, gave David permission to face Goliath, he was not 100% faithful, but instead thinking “this is so crazy it just might work.”

After numerous trials, including his betrayal by Saul, David was crowned King David.  He ruled unconventionally and brilliantly, true to his essence, and in doing so established the House of David and the true throne of Israel.  Famed as a warrior, he never forgot that he was also an artist, and crafted psalms as powerful in their own way as his armies.  This is not to say that David’s reign was a wholly peaceful one, or that his better judgment always prevailed.  He made his share of prideful mistakes, and suffered no shortage of tragedies, none more painful than the deaths of two of his sons.  However, David proved willing to build on his failings, and never stopped bucking convention.  When the time came to choose a successor, he passed over his heir apparent for Solomon (originally the product of adultery with the wife of one of David’s commanders).  Solomon, of course, built the great temple of Jerusalem, composed the Song of Songs, and became synonymous with surpassing wisdom.  Ultimately, the line of David exemplifies the divine ascendancy of the unlikely.

For technology entrepreneurs, the story of David is a highly attractive one, and the modern-day parallels are striking.  You can think of David’s slingshot as one of the original disruptive technologies – it’s lightweight, requires minimal training, and utilizes off-the-ground commodity hardware.  It is likewise fitting that the term “Philistine” has come to mean someone without any appreciation for art and learning, and this is especially true concerning the perception of software, perhaps the most misunderstood and underappreciated form of technology at the institutional level.  Of course, David himself is the most inspiring part of the story, a young, fearless, brash, but supremely talented leader who emerges from the least likely of places with the most counterintuitive blend of skills.  

However, those who would follow in David’s footsteps must beware the catastrophic, yet often subtle pitfalls along the path.  It is paramount that as David wins, he doesn't become Goliath.  For leaders who emerge from the tornado of the hyper-growth phase, this is deceptively easy to do, and the annals of technology are piled with the cautionary examples of companies born from innovation that faded into irrelevance by allowing themselves to become the hated establishment.  David must be true to who he is, not by consciously choosing to remain small and irrelevant, but by resisting Goliath’s arrogance and vulnerabilities - even while embracing growth and influence. 

I spend a lot of time working with large and important institutions to help them solve their biggest problems.  This tremendously rewarding, and as the sense of partnership and investment in their mission develops, it is tempting to want to be of them as well as work with them.  Yet you can only help them if you are true to David, and this requires you to maintain the unique identity and vantage point of the constant outsider.  And this is why massive institutions need the help of entrepreneurs, even if they don’t realize it at first.  This is inevitably a bumpy process, because the cultural bias is to keep David in a limited role, away from the front.  Eventually, though, it becomes clear that in order to do radically different things, they need radically different competencies and perspectives.  If it was simply a matter of finding better top-down management, they could promote from within.  To enlist a warrior psalmist is a different thing entirely.  

Of course, embracing unconventional wisdom is only the first step.   The far greater hurdle is how to institutionalize agile and independent thinking without becoming doctrinaire and inflexible about it – an ironic but all too common mistake.  Interestingly, this applies to both the century-old brand name that seeks to embrace entrepreneurial culture and the scrappy startup that suddenly finds itself with thousands of employees.  Once again, David rides to the rescue.  Consider the fundamental challenge faced by US Special Operations Command, a four-star headquarters with almost 60,000 personnel, charged with maintaining supremacy in lightweight, unconventional warfare.  Former commander General Bryan Brown, who enlisted as an infantry private and retired as one of the great visionaries of special operations, once remarked that USSOCOM needs its poets too. David knew it all along.

In the light of delivering outcomes, we should consider the respective merits of horizontal and vertical approaches.  The more common (and not necessarily incorrect) approach is to slice a problem horizontally and build layers to a stack based on objectives with clear left and right parameters.  This not meant to imply that there is a direct correlation between inefficient, services-based businesses and horizontal integration – indeed, many companies could (and do) achieve considerable efficiency through sophisticated slicing of problems and applying focus and discipline to a specific layer.  

However, this scenario presupposes that horizontal slicing actually makes sense for the problem at hand.  More often than not, this won’t work for truly world-changing problems – thorny, costly messes that have always defied incremental or partial solutions.   For these kinds of problems, you generally need a vertical slicing methodology, wherein the problem writ large is solved end to end.  

Complex problems are a lot like the classic peg-and-hammer game: knock one peg down and another one almost instantly pops up.  Focusing on one problem may cause another one to become more pronounced, or it may result in an entirely new problem emerging (the law of unintended consequences).  Once you begin to recognize that the underlying structure defies incremental approaches, the revolutionary no longer seems implausible – in fact, it often proves to be essential.  

One aspect that makes vertical approaches so hard is the amount of abstraction required.  Many business leaders pride themselves on seeing the bigger picture, but paradoxically, successful abstraction requires a concurrent grasp of concrete problems throughout the stack.  You can code in Java or C, but if you want to truly push the boundaries of performance, you need to understand what the computer is doing at the CPU level.  Conversely, nuts-and-bolts problem solving does not amount to a transformative business without some broader vision, and this requires abstraction.  In the vertical methodology, there are two main tiers of abstraction: that required to solve a specific problem end to end, and that required to generalize this solution to whole classes of problems.  Finally, it is worth noting that the abstraction challenge is equally crucial to management as well as technology, and morale tends to be worst when people can’t make meaningful abstractions – or feel they can’t.   

Apple is a great example of the success of the vertical approach, not only for its mastery of end to end considerations, but for rethinking the whole model of personal computing – a deft blend of granular and abstract problem solving.  In contrast to the Microsoft approach of focusing on operating systems and desktop software and letting hardware manufacturers fight it out, Apple chose to take responsibility for the entire experience, from the hardware to the user.  This required not only solving all the normal granular problems associated with each layer of the hardware, OS, and software stacks, but actually creating a continuous whole.  It’s about more than just a pleasing design – the idea that the user interface encompasses the device itself is central to Apple’s identity.  For Apple, the medium is the message, in three dimensions.  By slicing multiple user needs vertically, Apple ended up creating a whole new vertical, one it continues to dominate.

Where most companies saw problems they’d rather not touch, Apple saw opportunities – in device design, in platforms, and in challenging a monolithic company that conventional wisdom would suggest was unbeatable.   For years, Microsoft succeeded because they had created the most effective walled garden.   Although Apple’s OS had always had loyal adherents, Microsoft’s wall arguably started to erode with the introduction of the iMac and Macbook, which caused consumers to reconsider the fundamental relationship between form and function.  With the creation of the iOS developer platform and app store, the walled garden concept was turned inside out.  Yet I would argue that the platform, for all its merits, would have been exponentially less attractive if people were not already loyal to the device and the entire experience it represents – a shining validation of the power of vertical problem solving. 

There is one quite interesting twist to all of the above: in the course of developing a vertical solution so you will actually develop strong intuition about how the problem can be sliced horizontally. This is the entropy of the human approach and the way we naturally organize to solve problems in teams – i.e. frontend and backend, to use a very broad example.  Within each category, you can further refine the dynamics of the cross-functional teams that enable each horizontal slice. 

As a final note, it’s worth mentioning that while the vertical approach at its most successful may create the impression of an all-encompassing technology, an end-to-end solution almost is achieved through scrupulous attention to each layer of the stack.  However unified the whole may appear, the parts each play a discrete and necessary, not sufficient, role.  Developing vertical solutions is not a matter of finding a silver bullet, but rather the most effective combinations and permutations of thousands of lead ones.

The remarkable ascendancy of China and India as high-tech powerhouses has illuminated a non-obvious but profound truth: The United States remains the best place in the world for high-end software development.   Despite widespread economic pessimism and rumors of a global power shift, talk of across the board decline is ill-founded.  When it comes to software, American exceptionalism is alive and well.  The first secret to our dominance is our engineers.  To anyone familiar with the basic mechanisms of software development, this is really no secret at all.  What is more surprising is how much our engineering culture owes to the heartland.  While our software industry may be concentrated among the coastal elites, the ethos that makes it possible was largely forged in the wheat fields and corn rows of the Midwest.  Properly applied, it is this ethos that will see us through current uncertainties and solidify our place at the top for generations to come.

 “Global” does not equate to “world-class”, and there is no better illustration of this than the booming software industries of China and India.  This is a period of unprecedented growth and opportunity - certainly compared to the landscape my own father faced when he left Tamil Nadu a generation ago.  At the same time, per-capita income in India is less than half of China’s, itself a seventh of that enjoyed in the United States.  Yet income disparity is merely a symptom of a larger trend: for all the high-tech jobs created in the past decade, China, India (and the rest of the developing world, for that matter) have yet to produce their own Microsoft, Oracle, or Google.  Instead, “body shops” offering outsourced IT services and low-end development are the rule.  On the value spectrum, such businesses are the equivalent of the call centers that now symbolize the tremendous growth and equally tremendous limitations of the new global economy.

When software development is a process of manufacturing, not invention, the resulting products are commodities, and the same holds true for software engineers.  This is the crux of the issue: great software is not a commodity, but a highly evolutionary thing, and great engineers are irreplaceable, not interchangeable.  The relative talents of software engineers, and the elegance of their output, lie on an exponential, not linear, scale.  The difference between the very top and the median is not 30%, not 300%, but rather 10,000%.  Of course, this phenomenon is not only illustrated by the IT factories of Bangalore and Shanghai.  Plenty of American tech companies persist in believing that an arbitrary number of decent software engineers equals one savant.

However, the creation of a high-end software industry requires more than just top technical talent.  In the absence of the right environment, innately gifted engineers will either flee or toil in obscurity.  This environment must be supportive of personal aspirations, while remaining a firm meritocracy in which the best idea wins.  A sense of fairness must prevail, especially as it relates to competitive marketplaces, respect for intellectual property, and recognizing top individual contributors while promoting a spirit of teamwork and cooperation.  Most importantly, new talent is attracted to this environment by the promise of just opportunity, not a pre-ordained lot in life.  These are the essential Midwestern values that drew the first homesteaders inland from the American colonies, sustained a young Thomas Edison through countless early failures, and, in our own century, have given rise to the greatest icons of the knowledge economy.

All of this helps to explain why, despite tremendous advances in technical education throughout Asia (and comparative stagnation in our own system), the United States continues to be the epicenter of world-class software development.  This is not meant to suggest that the recent educational achievements of Asia are anything less than remarkable.  However, the best measure of these achievements is not the number (or lack) of new Googles springing up across the Pacific, but rather the influx of highly qualified Asian engineers and students seeking opportunity in top American companies and universities.  China and India have succeeded admirably in creating cultures of productivity, yet a culture of invention remains elusive. The upshot, for American software leaders, is a workforce that is much more diverse than it is often gets credit for.  Ironically, it is the native Midwesterner that is often absent from the popular perception of what a software company looks like – but we should remember that the first Midwestern settlers were primarily immigrants themselves.

While panic and pessimism are not appropriate reactions to our changing world, neither is taking our dominance and innovation for granted.  Instead, we should consider what our values have to teach us in light of certain austerity.  Our forebears, facing similar challenges, learned to do more with less. Happily, this concept applies better to software than to almost anything else.  Moore’s Law states that computing power doubles roughly every two years.  Given the ingenuity of our software developers, we should absolutely demand twice the performance for half the cost when it comes to IT infrastructure for healthcare, defense, treasury, and other mission-critical departments.  It is not enough to slash underperforming programs (and they are legion) without making concurrent investments in world-class technology.  This may seem counter-intuitive given our shrinking budgets, but we can only achieve the efficiency and productivity gains required by thinking in terms of value as well as cost. We must reward our top producers, but only while demanding their very best efforts. 

The unique software engineering culture of Silicon Valley may simply be the most recent manifestation of America’s pioneer values. However, it is these enduring values, more than any technical achievement, which will ensure America’s continuing dominance of the software world in a time of global change. 

Even a cursory glance at the worlds of technology and services (and the murky realm that lies between them) makes one thing clear: it is time for a new type of product company.  

What’s wrong with the old one?  Take enterprise resource planning as an example.  ERP/supply chain management was once a world-changing problem, yet even after decades in which to evolve, the typical ERP system solution still costs tens or hundreds of millions of dollars and requires substantial time to implement - sometimes as long as or longer than the first versions.  Why, then, does this model of “solution” persist so stubbornly?

One explanation is outdated reference points.  The previous generation of product companies grew up in a world in which bespoke software was the only viable option.  To solve a problem by conventional standards, they either had to build everything from scratch, or glue a bunch of existing products together into an uneasy coexistence.  Given the obvious shortcomings of the latter approach, the former takes hold in many cases.  

Of course, the bespoke approach has numerous shortcomings of its own.   It is largely inefficient, and discounts the extent to which large classes of solutions can be productized.  Interoperability with existing systems and future products invariably suffers.   Many customers will commission products that should be reusable elsewhere, yet impose IP restrictions that prevent wider application.  The largest companies may succeed in creating a continuum of seemingly complementary offerings (end-user software, administrative software, databases, mainframes, hardware, etc) - yet behind the kimono they are actually services businesses.  Each additional piece of hardware or software exists to sell more services, and in doing so, consolidate ownership of customer environments.  

However, the deeper (and much more destructive) phenomenon at work here is the matter of structural incentives.  From the vendor’s perspective, the bespoke development model usually means each product has been developed on a specific, proprietary customer’s dime (indeed, it is hard to imagine a purely bespoke model working without rigid exclusivity clauses).   The bespoke developer bills for the engineers’ hours, not the final product, and inevitably requires a legion of consultants to make the product work and provide further customization ad infinitum.  Conveniently, the longer the project takes to complete, the more money the company makes.  Even if there is no gross corruption, there is no incentive on the margin to make anything more efficient.  

On the customer side, structural incentives should be better aligned, but loss aversion tends to create resistance to change, especially in big companies.  The larger an organization’s technology purchasing infrastructure (and the more layers between it and the end-user), the more the incentive structure is influenced by the practical need to defend oneself to the outside world.  Because appearance is everything, the relative downside of being associated with an unsuccessful technology acquisition is fairly high, while the relative upside of a successful new implementation is surprisingly low.  As a result, “safe” decisions quite often win out over the best decisions, which are usually non-linear and difficult for everyone to easily recognize, even with the purest of motivations.  The effects of loss aversion reverberate far beyond technical functionality – they limit the vision of the whole organization, even among those who ordinarily might embrace innovation.   As consumers and as a society, we have not been as perceptive as we probably ought to be about the efficacy of the traditional approach to building products - if we were, we would be more willing to learn and iterate with a long-term outlook.  

Left alone, the traditional approach, for all its faults, seems destined to persevere.  Hence, I maintain that we need a new type of product company: one that actively takes responsibility for the outcome the product is supposed to deliver.  This may sound intuitive enough, but it actually represents a revolutionary departure from traditional companies that deliver technologies or capabilities at best.   This company must have both the skills to productize new technologies and the incentive to continue iterating until its products work out of the box (and working out of the box must sooner or later be seen as a firm requirement, not a nice-to-have).   The tricky part, however, is that this incentive must be created alongside the product itself.

Let’s first consider the incentives driving the traditional model.  Creeping development schedules and requirements reliably create larger and broader revenue opportunities.  This results in an obvious disincentive to stay on schedule and under budget, but it is a commonly accepted model that many large customers are well-prepared to accommodate.  Increased dependency on services creates more revenue opportunities, and has the additional benefit of locking in customers, who may not have the desire to administer their own technical systems (or even believe it to be possible).  Finally, a subtle but profound incentive is that companies are rewarded for convincing customers that each of their problems is a unique snowflake and requires an equally unique solution, built from the ground up, at bespoke speeds.  

The new model is a study in contrasts.  There is no incentive to delay, partly because the company does not rent labor by the hour, but largely because working out of the box is a major part of the value proposition.  The outcome-based model prizes efficiency for both customer and vendor, and as a result, the focus is on solving immediate problems with the subsequent goal of generalizing and productizing solutions to whole classes of problems.  However, the desired outcome must be achieved without compromise, so there is also a strong incentive to create a product that is adaptable to very specific requirements.  The overriding incentive, however, is to do something truly extraordinary, and realize substantially more value based on a substantially better outcome.   If you can save a customer $1 billion, it is not unreasonable to charge $250 million for the privilege.  By the same token, a solution that is duct-taped together over months and years and thrown over a wall, leaving the customer to struggle to realize a fraction of the savings themselves, should be rewarded proportionally.

This is the big bet driving the outcome concept: outsized rewards for outsized (and demonstrable) value.  Of course, it will absolutely never happen this way overnight.  No doubt the outcome model is much riskier business in the short term.  The company must assume the risk of development costs, since the new model requires them to create value first before they can charge for it.  Delivering a meaningful outcome also requires top engineering talent, which cannot simply be purchased, and certainly not as quickly as one would like.  Finally, lest we forget, the structural incentives to avoid change are alive and well.   In order to have any chance at all of making it, the entrepreneur must take on the lion’s share of the risk, betting that a fair price for a guaranteed outcome will be a lagging indicator in the best case scenario.  In the short term, true outcomes will almost inevitably be undervalued, but the reality is that the burden of proof is on the innovator.  (To be fair, there is risk for the customer as well, even if their initial monetary outlay is low.  Ideal outcomes are not usually achieved all at once – early on, they will require the customer to invest their time, provide access to their hardest problems, and be willing to iterate without real certainty that the new company will necessarily succeed where previous vendors fell short).

A business model based purely on delivering outcomes would amount to a seismic shift – a wholesale reinvention of what it means to be a product company.  So be it.  This is unquestionably a difficult road, but if the past has taught us anything, it is that the only way for entrepreneurs to achieve the changes they desire is to see them through from inspiration to outcome – as high-tech companies everywhere like to say, end-to-end.   More often than not, this means solving problems (and even conceptualizing them) vertically rather than horizontally.  A truly vertical approach represents a major distinction and radical departure from the norm, and will be covered in depth in the next installment.

 

Those selected for development have one universal trait in common: They are by definition high achievers. But there is a difference between those superstar achievers that can make the leap to CEO and those that will implode: To what degree do they feel invigorated by the success and talent of others, and to what degree does the success of others cause an involuntary pinch of insecurity about their own personal inadequacies? Only an individual who feels genuinely invigorated by the growth, development, and success of others can become an effective leader of an enterprise. And it remains the most common obstacle of success for those trying to make that leap.

from Narcissism: The Difference Between High Achievers and Leaders

Doing what you’re good at is an obvious prescription – perhaps a little too obvious for the aspiring entrepreneur who most likely takes pride in discovering the hidden dimensions of everything!  It can’t be that simple, can it? I would argue that it really is simple - just not easy.  Discovering what you’re good at takes time, intellectual honesty, and an even greater awareness of what you’re not so good at.  Usually, some failure is required.  It’s also not a binary system – not everything fits into neat categories of what you should and shouldn’t be doing, and as discussed, starting something substantive inevitably requires you to do a little bit of everything.  That said, ascending to the next level will require you to leverage your strengths as never before.  

You have certain obvious strengths you already know about.  Getting into (and through) college requires a broad range of competencies that we often take for granted, and it’s easy to confuse competencies with real strengths, especially if you have the kind of work ethic that can compensate for subtle weaknesses.  Even so, you probably have a good idea where your major strengths lie, and they can all serve as a clue as to what you should be doing with your life.  

Within these strengths there is something you are so good at that it seems effortless – and because it’s so intuitive, you may assume others can do it too.  This sometimes manifests itself when working in teams - when something comes so easily it can be hard to appreciate how it could be a real struggle for someone else.  As a result, you may even undervalue this strength, which would be a shame, because this is your superpower - the key to making your greatest impact.  The common factor among every great entrepreneur I know is having a superpower and knowing how to use it (despite often being below average in many other facets).  “Well-balanced” individuals, by contrast, tend to be a hit at management consulting firms and other places where job titles actually include the word “generalist”.

Then, there are the things you aren’t good at, but would really like to be.  The problem is that early on, you define yourself in part by being good at these things, and this can be really hard on the ego.  It is a massive distraction from your true strength.  But it is really important to emotionally and intellectually learn to let go here.  And context matters as well – you might be perfectly adequate at one of these aspirational strengths in most people’s eyes, yet exist in an arena where you need to be among the best.  I eventually had to accept that I would never be the greatest programmer (as much as I wish that weren’t true!).   I could have continued to program for a living, but not if I wanted to someday work with the top software developers in the world (as I now do).  I don’t regret having tried, but really this was just part of my journey to really understanding my strengths.  

This is not to say that struggle isn’t valuable, but as with learning, people overestimate the value of struggle for its own sake.  It’s largely a matter of recognizing what’s worth struggling for and what isn’t.  Achieving your maximum impact isn’t just about identifying your talent and riding it to greatness.  Almost everyone has weaknesses that blunt the impact of their strengths, and while these weaknesses might never be banished, you can absolutely learn to control them.  

The final thing to remember is that this is largely a process of self-discovery.  Your mentors and colleagues can help you get there, and they will definitely have insights that only an outside vantage point can provide.  Ultimately, however, no one can do it for you – and that realization should excite and inspire you even more.