Chris Dixon

“Big timing” is a phrase I’ve heard a lot lately which refers to people who are “higher ranking” acting disrespectfully toward people who are “lower ranking”. Example usage: “so and so VC partner big timed my associate,” meaning they talked down to him/her or didn’t meet with him/her or whatever.

Big timing is a huge mistake. Why? 1) big timers vastly underestimate the degree to which senior people trust their junior people, 2) most non-jerks (no matter how successful) interpret big timing to be an insult to their firm and therefore to their senior people, 3) junior people are often far more active and informed than senior people and therefore great people to spend time with.

It would be great to think that in the startup industry, people would realize that today’s junior person could become “big time” tomorrow, and that you should therefore be meritocratic and respectful to everyone. But that’s not my experience.

One of the great unsolved questions in computer science is the P vs NP problem. It is one of the seven Millennium Prize Problems - if you solve one of them, you get $1 million and become really famous among mathematicians and computer scientists.

Here’s my non-technical interpretation of the essence of the P vs NP problem:

Can every answer that can be feasibly verified also be feasibly calculated?

What I am calling “feasible” is what computer scientists call algorithms that can run “polynomial” as opposed to “exponential” time.

There are at least four possible outcomes to the attempts to solve this problem: 1) the current situation continues – no proof of anything is found, 2) P=NP is proved true, 3) P=NP is proved false, 4) it is proved that it’s impossible to prove P=NP to be true or false.

If P=NP were proved true, there would be many serious real-world consequences. All known encryption schemes rely on the fact that prime factors of large numbers are something that can be feasibly verified but not calculated. If P=NP, that means there would also be feasible ways to calculate prime factors, and hence decrypt codes without their private keys. So if someone does prove P=NP, he or she should probably inform authorities before publishing the proof and all hell breaks loose (thanks Matt for this observation – you could also imagine a lot of conspiracy theories about what happens to scientists who try to prove P=NP..!)

Most computer scientists seem to suspect P does not equal NP. MIT computer scientist Scott Aaronson gives informal arguments against P=NP in this entertaining blog post, including this philosophical argument:

If P=NP, then the world would be a profoundly different place than we usually assume it to be. There would be no special value in “creative leaps,” no fundamental gap between solving a problem and recognizing the solution once it’s found. Everyone who could appreciate a symphony would be Mozart; everyone who could follow a step-by-step argument would be Gauss; everyone who could recognize a good investment strategy would be Warren Buffett. It’s possible to put the point in Darwinian terms: if this is the sort of universe we inhabited, why wouldn’t we already have evolved to take advantage of it?

He follows up with a much longer essay (which I found really interesting but ultimately unconvincing) on the philosophical implications of computational complexity (the field of computer science that studies questions like P vs NP).

From Jonah Lehrer, Brainstorming Doesn’t Really Work (via Stowe Boyd):

Building 20 [a scene of incredible innovation at MIT] and brainstorming came into being at almost exactly the same time. In the sixty years since then, if the studies are right, brainstorming has achieved nothing—or, at least, less than would have been achieved by six decades’ worth of brainstormers working quietly on their own. Building 20, though, ranks as one of the most creative environments of all time, a space with an almost uncanny ability to extract the best from people. Among M.I.T. people, it was referred to as “the magical incubator.”

The fatal misconception behind brainstorming is that there is a particular script we should all follow in group interactions. The lesson of Building 20 is that when the composition of the group is right—enough people with different perspectives running into one another in unpredictable ways—the group dynamic will take care of itself. All these errant discussions add up. In fact, they may even be the most essential part of the creative process. Although such conversations will occasionally be unpleasant—not everyone is always in the mood for small talk or criticism—that doesn’t mean that they can be avoided. The most creative spaces are those which hurl us together. It is the human friction that makes the sparks.

I think this underscores one of the main reasons remote early-stage projects often fail. We mistakenly think of brainstorming as something you can do in meetings, and teaching as something you can perform through carefully composed documents or lectures.

I was part of a number of failed remote R&D attempts. The one time it worked was when we decided to abandon meetings, project documents, tracking tools, etc. Instead, we got a high quality speakerphone so everyone could overhear everyone else’s conversations, and we left it on all day, every day. It wasn’t the same as being together in person, but we did manage to get some of the human friction back.

When your product extends a platform’s functionality, one of the main risks you face is that the platform could embed your product’s key features within the platform – what is sometimes called subsumption risk. This happened to a lot of startups in the 90s that built products for the Windows platform.

When you depend on a platform for distribution (acquiring and retaining users), you take on different risks. Specifically:

1) Oversaturation. The risk that supply of products on the platform significantly outpaces demand. This seems to have happened recently to the iOS App Store: there are over 500,000 apps and counting, and popularity tends to be highly concentrated, making it very difficult for new apps to get noticed. Oversaturation also happened to Google (organic) results in most query categories in the last 2000′s.

2) Barriers to discovery. The risk that the discovery methods on the platform aren’t meritocratic. iOS apps depend upon appearing in iTunes’ Top 25 lists, leading to a “rich get richer” bias, along with aggressive attempts to game the system. Apple has other app discovery mechanisms like its Featured Apps and Genius features, but those seem to drive far fewer downloads than the top lists. Google search has increasingly been favoring Google’s own products and also seems to heavily favor older, well-entrenched websites, making it very hard for new sites to gain significant SEO traction. Currently, social networks like Twitter and Facebook seem to have the most meritocratic discovery mechanisms, which is one reason so many startups target them for distribution.

3) Throttling. The risk that the platform will throttle distribution or monetization (for apps that rely on paid advertising, throttled monetization also means throttled distribution). Facebook started out letting apps send unfiltered notifications to users’ timelines but then introduced algorithms that heavily filtered them (thereby entrenching the position of leading app makers like Zynga). Facebook also started out letting apps charge users directly, but later changed that policy and imposed a rev-share.

If you are launching a new website or app, you should have a distribution strategy beyond just “people will love it and tell their friends about it”. Your strategy should probably involve at least one major platform. And you should think through the distribution characteristics of the platform and decide if they are a good fit for your product and how best to mitigate the risks.

Finally, it is worth noting that some of the most successful startups grew by making bets on emerging platforms that were not yet saturated and where barriers to discovery were low. Today, the most interesting new platforms are probably Android tablets and emerging social networks like Foursquare and Tumblr. Betting on new platforms means you’ll likely fail if the platform fails, but also dramatically lowers the distribution risks described above.

Recently, a friend was trying to recruit a programmer to join his early-stage startup. The programmer had just graduated from college and his impression of startups was shaped mostly by popular media. His main concern, he said, was: “What if we end up being the next MySpace instead of the next Facebook?”.

Of course, for those of us immersed in startup world, creating the next MySpace would be considered a huge success. MySpace was once the most visited website in the US and was acquired for $580M. It flamed out later under its corporate owner, but that happens to a lot of great startups.

Mainstream culture seems to depict startups as either being complete failures where everyone loses their shirts or else huge hits like Facebook. But the reality, as usual, lies in the middle: in 2010, according to Dow Jones, there were 522 venture-backed exits with a combined exit value of $53 billion – implying an average exit price of around $100M.

The best thing about startups is you get to work with great people on interesting projects, and can be successful by conventional metrics, even if no one outside of tech has ever heard of you or what you’ve built. There’s great stuff between failure and Facebook.

Note: The company I cofounded, Hunch, was acquired by eBay in November 2011. I am now an eBay employee. But all the opinions expressed below are my own, and were developed prior to the Hunch acquisition, through my own research on e-commerce.

Amazon and eBay are the two largest e-commerce companies. As of this writing, Amazon has a market cap of about $87B, trading at a trailing twelve-month P/E of about 139. eBay has a market cap of about $42B, trading at a trailing P/E of about 13. Each company competes with many other companies in many different areas. For example, Amazon competes with Apple on tablets (Kindle vs iPad) and digital media (Amazon’s media store vs iTunes). Ebay’s Paypal unit competes with multiple payment companies, and its marketplaces division competes with other “peer-to-peer” e-commerce sites like Craigslist. But given the potential size of the e-commerce market (not to mention the online-to-offline commerce market), Amazon and eBay’s main competitors are each other. And to understand their large strategic moves (e.g. large acquisitions like GSI and Zappos), it is important to understand their fundamentally opposing strategic outlooks: eBay wants commerce to be more decentralized (around its GSI/Magento partners and eBay marketplaces sellers) and Amazon wants it to be more centralized (around itself).

First, some background. During the dot-com boom, many largest offline brands debated how to best move their businesses online. Some tried to build their own websites from scratch. Others partnered with commerce technology providers. Toys ‘R’ Us took a novel approach and signed a “strategic alliance” to outsource all of their e-commerce operations to Amazon. Over the next few years this relationship soured – apparently Toys ‘R’ Us felt Amazon was competing too directly with them and successfully sued to end the relationship.

The end of the Toys ‘R’ Us – Amazon relationship marked a turning point for a company called GSI Commerce. GSI took an aggressively neutral approach to providing technology and marketing solutions to retailers. Their main appeal over Amazon is that they didn’t compete with their partners (but of course their partners competed with each other). This approach paid off: GSI now powers over 500 large commerce sites, including Toys ‘R’ Us, Adidas, Ralph Lauren, and the commerce sites of all the large sports leagues like the NFL, MLB and NBA.

Last year, eBay paid $2.4B to acquire GSI Commerce. They also acquired a smaller company called Magento that provides e-commerce technologies to smaller retailers. You can think of GSI as the leading commerce platform for the “fat head” of retailers, and Magento as the leader for the long tail.

The key difference between eBay and Amazon isn’t auctions vs. fixed price sales (the majority of eBay sales aren’t auctions anymore). It is that eBay doesn’t take inventory, and prefers to be an intermediary that facilitates peer-to-peer commerce. This strategy wins if e-commerce becomes more decentralized, with the majority of commerce continuing flow through small to medium retailers. In this world, eBay makes money by sending traffic from eBay.com, from fees collected by GSI and Magento, and Paypal transaction fees. In a centralized world, Amazon grows its current 9% e-commerce market share to a much larger percentage, taking advantage of its scale, efficiency, advanced technology, and the convenience of shopping in one place.

One way to view this battle is to think of eBay as a platform a la Windows or Android and Amazon as an end-to-end solution a la Apple computers in the 90s or iOS devices today. Platforms tend to provide greater diversity. In the case of e-commerce, the platform approach could also have a price advantage. As the CEO of TrialPay, Alex Rampell, argues: “Who can beat Amazon on price? The companies whose products are sold on Amazon”. End-to-end solutions like Amazon’s tend to provide greater convenience and a better user experience.

I’m not arguing that one approach is superior to the other. My point is simply that when you understand that the battle is between centralized and decentralized commerce, the strategic moves of the two companies make a lot more sense.

1. I’ve heard rumors that lots of apps have been uploading user contact lists for years. One person who knows the iOS world well told me “if you download a lot of apps, your contact list is on 50 servers right now.” I don’t understand why Apple doesn’t have a permission dialog box for this (that said, I’m not sure that’s the best solution – see #4 below). Apple has dialogs for accessing location and for enabling push notifications. Accessing users’ contact lists seems like an obvious thing to ask permission for.

2. I don’t know what the product design motivations are for uploading contacts, but I assume there are legitimate ones. [commenters suggest it is mainly to notify users when their friends join the service].  If this or something similar is the goal, you could probably do it in a way that protects privacy by (convergently?) encrypting the phone numbers on the client side (I’m assuming the useful info is the phone numbers and not the names associated with the phone numbers since the names would be inconsistent across users).

3. Many commentators have suggested that a primary security risk is the fact that the data is transmitted in plain text. Encrypting over the wire is always a good idea but in reality “man-in-the-middle” attacks are extremely rare. I would worry primarily about the far more common cases of 1) someone (insider or outsider) stealing in the company’s database, 2) a government subpoena for the company’s database. The best protection against these risks is encrypting the data in such a way that hackers and the company itself can’t unencrypt it (or to not send the data to the servers in the first place).

A bad outcome from this controversy would be to have companies encrypt sensitive data over the network and then not encrypt it on their servers (the simplest way to do this is to switch to https, a technology that is much more about security theater than security reality). This would make it impossible for 3rd parties (e.g. white-hat hackers) to detect that sensitive data is being sent over the network but would keep the data vulnerable to server side breaches / subpeonas. Unless Apple or someone else steps in, I worry that this is what apps will do next. It is the quickest way to preserve product features and minimize PR risk.

4. I worry that by just adding tons of permission dialogs we are going back to the Microsoft IE/Active X model of security. With lots of permission popups, users get fatigued and confused and just end up clicking “Yes” to everything. And then the security model says: If the user says “yes”, and the app uses “best practices” like https, it can do whatever it wants. We saw how this played out with the spyware/adware epidemic on the web from 2001-2006 and it wasn’t pretty.

The other day a friend was demoing a new app he was working on. My first reaction was: “Yeah, yeah. This is nicely executed version one of those ideas I’ve seen 50 times.” My second reaction was: “But I could say that about pretty much every successful startup I’ve seen over the last 10 years.”

Most of the time, important new ideas don’t succeed on the first attempt or even the first ten attempts. But then they do, and it seems to happen suddenly. It’s hard to tell why this is. It’s probably a combination of timing (riding some fundamental shift in technology or culture), and execution (getting the product just right).

An idea getting tried over and over tends to be a positive signal (which is one reason that competition is overrated). It’s very easy when you spend lots of time around startups to get cynical. You could tweet and blog predictions that every new startup will fail and how the ideas are derivative and you’d be right 95% of the time. The hard part – and what matters for founders and investors – is figuring out the right mix of timing and execution to finally get it right.

“Bedrock programming” is a phrase used to describe a style of programming that favors building code from the ground up versus reusing existing open-source or proprietary code.

In my first programming job out of college our bosses told us to entirely rebuild our product. The person in charge of the networking layer decided the best way to do this was to write our own low-level networking toolkit, using some new, relatively untested networking techniques. We also wrote our own versions of core Java libraries (because, it was said, the existing ones weren’t sufficiently thread safe). This decision ended up leading to repeated delays and bugs, and a codebase that most of the other employees didn’t understand. It also made it much harder to train new hires and find replacements for departed employees.

A related issue is what is usually called the “bleeding edge” tendency: the desire to use the shiny & new over the older & battle-tested. Lately, I’ve personally been programming with MongoDB and love it. But I’m also an investor in a startup that made Mongo their main production database, and when their Mongo expert left unexpectedly it took them far longer to find a replacement than it would have to find a MySQL expert.

Great programmers are intensely curious and inventive. They love to improve code and try new things. There will always be bedrock and bleeding edge tendencies within strong engineering teams. The key is to have a great VP Engineering/CTO who can balance those tendencies with the reality that talent, money, and time are scarce, especially in startups.

Recently, there’s been a lot of talk in the tech world and beyond about getting more people to learn computer programming. I think this is a worthy goal*, but the question should be considered from various angles.

1. Jobs & the economy. Businesses all over the world need more programmers. Every company I know is hiring engineers (e.g. see this list of NY tech startups). Top programmers can make $100K+ right out of college. Yet there were only about 14,000 computer science (CS) majors last year. Meanwhile about 40,000 people got law degrees even though demand for lawyers has been shrinking. America is suffering from what economists call structural unemployment:  jobs are available but our labor force isn’t trained for those jobs.

2. Programming is a great foundation for a tech/startup career. CS is a great foundation to do other things in tech industry like starting a tech company (although I’d argue that design is an increasingly valuable foundation for web startups). I suspect one of the reasons for the low number of CS majors is people don’t realize all the non-programming opportunities that are opened up by a background in programming.

3. Programming is an important part of being “culturally literate.” Algorithmic thinking is as fundamental a type of thinking as mathematical thinking. For example, Daniel Dennett convincingly argues that the best way to understand Darwin’s theory of evolution is by thinking of it as an algorithm. (I haven’t read it yet but I’m told the premise of Stephen Wolfram’s A New Kind of Science is that algorithmic methods should be applied much more broadly across the sciences). Teaching algorithmic thinking – which is what CS does – should be a core part of a liberal arts education.

4. Programming is a great activity.  Most people who program describe themselves as entering a mental flow state where they are intensely immersed and time seems to fly by. It feels similar to reading a great book. You also feel great afterwards – it is the mental equivalent of going to the gym.

5. Should non-technical people at tech startups learn to code? This is where I disagree with some of the conventional wisdom. Certainly it is worthwhile learning programming, at least for reasons 3 & 4 above. You should realize, however, that to become a good programmer takes thousands of hours of practice. I’d also argue that if you are a non-technical person working at a web company the the first thing you should learn is internet architecture (DNS, http, html, web servers, database, TCP/UDP, IP, etc). Learning some programming is good too, to help relate to technical colleagues. But if your goal is to build a large-scale web service, your time as a non-technical person is better spent recruiting people who have been coding for years.

* Disclosure: I’m an investor via Founder Collective in two companies related to teaching programming:  Codecademy and Hacker School.