Stanford MBA Trends

In Peter Thiel’s recent lecture for CS183B he mentioned that they’ve done some studies on recent graduates from MBA programs, and how as a result of who they are and the environment they’re put in, they “systematically end up doing the wrong thing, they try to catch the last wave.” He mentions Junk Bonds in the 80’s, Dot Com in the late 90’s, and mortgages/finance in the mid-2000’s as examples of MBA’s catching the last wave, or picking the wrong thing.

I was pretty interested in the idea of MBA industry choices being some kind of indicator of an industry that has just peaked and is about to decline in some dramatic fashion. So I went to Stanford’s Career Management Center and went through all their available reports from 2004 to 2013 to see what trends I might be able to spot.

Full data is available in a Google Spreadsheet.

Probably the most compelling part of this data set is the non-quantitative portion - for 2013’s report Stanford started breaking out Technology into many more sectors with the footnote: “Technology subcategories indicate industries impacted by technology jobs.”

That feels a bit like empirical validation of Marc Andreesen’s viewpoint that software is eating the world. Small chunks of what 10 years ago would have been part of Finance or Media/Entertainment are now under the tech umbrella. It likely won’t be long before the Technology label isn’t really a helpful differentiator, as every business will have to be built on some sort of technology foundation.

As far as quantitative trends, the starkest one is the most alarming - an unprecendented 32% of Stanford MBA grads are going into tech, compared to 16% 10 years ago and 13% just 2 years ago. It could be that this is part of the larger, longer term trend of tech eating into other industries, or if Peter Thiel is right, that Tech might have a correction headed its way.

It turns out that if certain objects are made visible and salient, people’s behavior can be affected. Objects characteristic of business environments, such as briefcases and boardroom tables, make people more competitive, less cooperative, and less generous.

A compelling argument for the casual office from Nudge by Thaler and Sunstein.

This is a great write-up by DHH of Rails fame about the Basecamp approach to native app development. They’re using a hybrid approach to take advantage of native experience where it matters, and development speed where the native responsiveness isn’t as critical.

It’s a great follow-up to my post on Mobile Web Performance from a few months ago, and hopefully a sign of things to come in terms of web applications making a resurgence in the mobile paradigm.

Intel’s original business plan from 1968.

In an effort to meet some new people in the tech scene in San Francisco, I’ve set up a one page site to encourage people to let me take them out for coffee.

I’m approaching this a little bit as an experiment. How many people (out of those that visit the site) will be willing to meet a random person on the internet (albeit one in the same industry)? What kinds of people will they be? What kinds of things will they want to talk about?

I’m hoping I’ll get to meet some people I’d otherwise never run into, just because they’re curious and willing to put themselves out there. Plus, who can turn down a PSL?

An ad for a mortgage re-fi I saw on TechCrunch that has me wondering: will she be my mortgage officer? Or is she the LendGo mascot?
At least they know their demographic.

An ad for a mortgage re-fi I saw on TechCrunch that has me wondering: will she be my mortgage officer? Or is she the LendGo mascot?

At least they know their demographic.

Mobile Web Performance and the Hardware Revolution

Last month I argued that the return to Native Apps was killing the potential of the coming hardware revolution. In it, I discuss how the platform fragmentation that we are seeing as a natural result of software coming to an increasing number of devices.

There can be good reasons for software fragmentation: the use cases and capabilities of a refrigerator, a TV, and mobile phone are all very different. However, fragmentation within a category, and even across similar categories, is superfluous and was, prior to the introduction of mobile, a solved problem thanks to web apps.

Speed is the other big issue when it comes to the new wave of devices around us. As discussed at length in his excellent article on the topic (which should be required reading for anyone participating in the native vs. mobile web debate), Drew Crawford points out that there are serious performance issues on mobile that you don’t see on the desktop which cripple mobile web’s performance capabilities. As illustrated in Crawford’s chart below, the iPhone 4S has browser performance that edges out IE8 in 2010, and doesn’t come close to the fast browsers available at the time.

image

According to Crawford, all the assumptions about the platform that have made Javascript (and web apps generally) successful on the desktop (tons of memory, fast CPU, low latency internet connection) aren’t available on mobile, and as a result, the performance trade-off made by Javascript in favor of programmer productivity is not tenable.

I can’t argue with Crawford’s numbers - mobile web is too slow for serious web apps today. Facebook’s HTML5 reversal should be evidence enough of that. However, as Crawford pointed out, the iPhone 4S (released in late 2011) is comparable to a slow browser in 2010, so we should expect phones released this year, like the iPhone 5S/6, to have performance near slow browsers in 2012, which is not bad when it comes to web app development. Even if hardware gains are all that we have to look forward to in mobile, it would be a mistake to bet against Moore’s law when it comes to more powerful computing making its way to phones and other devices.

While mobile devices will always lag behind their desktop peers, they will soon be “good enough” for most applications that matter to most users. Facebook’s experiment with mobile web was a failure, but as with many things in technology, it was a failure because it was before its time - in a few years (or sooner), a mobile web Facebook experience will be near native, and close enough to make the development and deployment benefits outweigh the performance costs.

Performance is an issue that time and Moore’s law will solve, but platform fragmentation is a drag on innovation that the march of technology can’t fix.

Facebook Should Buy Stripe

Facebook recently released a “Payments Test” that allowed users at certain e-commerce websites to autofill their billing info as it’s stored on Facebook’s website (from previous Facebook purchases). There was some speculation that this was an attempt to compete with the likes of PayPal as a full-fledged payment processor, but it has since been confirmed that this is more akin to Chrome saving form details, and therefore not a threat to processors.

According to TechCrunch, the strategy behind the autofill feature is to be able to track the ROI of ad placements on Facebook — they are tracking similar metrics with Datalogix in physical stores. The hope of course is that if Facebook can prove the effectiveness of their ads (which has been disputed in the past) they can win more advertising dollars.

Facebook is (was?) in an extraordinarily unique position of being a nearly universal identity provider on the web. In the early days of Facebook Platform it seemed as though “Connect with Facebook” was going to obliterate home-grown authentication systems. While the expectations are much lower now, Facebook Connect is still an incredibly popular choice, especially for the average internet user.

Ads are not the only way to monetize their position as an identity provider. In fact, they may be the least interesting way. Google revolutionized advertising, and has able to make killing on it, but that doesn’t mean that ads are the only way forward.

While there are tons of ways to take advantage of being an identity provider, payments is an absolute slam dunk. Payments online are still roughly the same as they were 10 years ago, and there is still a lot of FUD regarding the process for end users. Having a single provider that people trust, and that has their billing information on file, would be a game changer for online commerce.

In the same way that Apple has created an environment in the App Store and iTunes Store that leads to easy, nearly thoughtless purchases, so could Facebook create a safe, simple environment for every single transaction that happens online.

Were Facebook to tackle such a huge opportunity, they would need to ask themselves whether to build or buy a solution.

While they have an enormous amount of technical talent, the regulatory hurdles involved with payments makes an acquisition much more attractive, and who better than Stripe, a developer-friendly processor that is rapidly gaining marketshare on the simple premise that accepting credit cards should be easy for the people who build websites.

Stripe could continue building an amazing product, evangelizing more and more developers to switch from something like PayPal, with the added benefit that with the flip of a switch, they could enable “Pay with Facebook” - a seamless way for users that already have payment data stored to check out in seconds.

The boost in conversions that developers would see would do the marketing for the “Pay with Facebook” option itself, and if Stripe allowed customers to save billing information with Facebook after every purchase, Pay with Facebook could rapidly become a contender in payment processing, even alongside such behemoths as Braintree, PayPal, and Square [1].

There are good reasons why Facebook shouldn’t pursue payments, of course. It takes away from their core focus, and they would be competing in a space with well-established competitors (and possibly their customers).

The reality is, however, that Facebook’s current business focus is advertising, and taking focus away from that to work on payments seems like a prudent choice. In addition, Facebook Payments would compliment advertising - imagine an ad that allowed users to make a purchase with a single click, and all without leaving Facebook.

There is very well-established competition in this space, but none of the big competitors have addressed the social aspect of commerce, or established themselves as anything close to a universal identity provider, both of which could be critical for the future of e-commerce.

It seems (and this is mostly anecdotal) that Facebook’s social product is losing steam, and they might not have this opportunity for long. Building Facebook Payments would solidify their position as necessary infrastructure for the next wave of innovation, regardless of whether the social product continues to be as successful as it has been.

The looming question in my mind is why this strategy didn’t work for Google. A huge percentage of the internet population has a Google account, and Google has a good reputation with the public and with developers. They created Google Checkout to compete with PayPal, but are retiring it this year to focus on Google Wallet, a mobile payments play. With Stripe’s success, it seems that getting merchants to switch processors isn’t impossible, so perhaps Google’s execution was simply lacking.

I still think $FB is a buy, but only if they take advantage of the opportunity that they have by making a play into an open space, like payments with Stripe. They may not have an unlimited amount of time to convert their popularity into a long-lasting business.

[1] - Google is a player in this space too, but they are now focusing on mobile with Google Wallet. PayPal and Square are also heavily involved in mobile. Facebook going after traditional e-commerce might seem like skating to where the puck is, but I think that having customers accustomed to “paying with Facebook,” having their billing information on file, and having a large installed base on mobile would go a long way towards whatever happens with mobile payments.

This is a great look at startups through the lens of anthropology, and dissecting them as tribes, a human organization as old as humanity itself. All the attributes we think about when imagining a startup make a lot sense in the context of creating tribal rituals. It also supports the common startup truism that it is critical for a startup to have a cohesive, nearly homogenous culture, and to have a set of uncompromising values upon which decisions are based (so called Sacred Things).

Definitely worth the read, along with the footnotes.

Filequeue supports Streams

Filequeue, the module I wrote to fix an issue I was having while trying to open too many files at once in Node.js, now supports Node 0.10.x, and has support for the new ReadStream and WriteStream methods that were included with the 0.10.x release.

Adding streams support required that I rewrite most of the module to be more flexible in terms of method signatures allowed (previously, a callback as the final argument was required for the module to function properly).

While doing the rewrite, I also changed the way new methods were added to pass the Grep Test. The actual logic of what’s happening when the methods are called is much clearer now, which should make maintenance and extension much easier, both for myself and other contributors.

Filequeue is available on NPM.