Offer a Conversion Path!

I’ve had a curious experience with Amazon EC2 recently, and it made me think of a the process of adoption of new systems and services. In short: it doesn’t matter how good your product is, if it’s too hard to switch from the old way of doing things to your new-and-revolutionary gizmo. Let me share two stories.

Microsoft Word vs WordPerfect, 1991. Out of the gate, WordPerfect is a giant with almost 50% market share. Microsoft just released a “better  mouse trap”; they also know that the competitor’s product has massive adoption, and Word will hit a big wall because of the incompatibility of the two document formats. If a customer buys Word, they can’t open their old WordPerfect documents:

“No matter how good Word is, I have to buy WordPerfect anyway to have access to my old stuff. Damn, I already spent money on one word processor.. Why do I need another?..”

Microsoft does the smart thing: they write adapters for WordPerfect import AND export. Now, if you are an early adopter of the new-and-amazing MS Word, you can still send documents to your dinosaur friends. The barrier has been lifted, the purchasing decision is now to be made only on merit; with this single move, they were able to wipe away most of the network effect advantage of their competitor.

Fast forward to 2012. VMWare and on-premise virtualization providers are under attack by platform-as-a-service vendors, first and foremost, Amazon EC2. Amazon has built a cost-effective, scalable, very advanced mouse trap. It’s not a perfect replacement – but it’s better in many ways. Lots of Amazon’s potential customers today are using various on-premise virtualization solutions. And yet, 6 years after the launch of EC2, there is still no way to take my VMWare Linux box and upload it – seamlessly – into EC2.

No wonder that only under 5% of top 5000 websites by traffic are using Amazon EC2 today.


Influence of Your Work on the World

As I was finishing school, I had a dream – I wanted my job to maximize my influence. I wanted the product of my craft to touch, in a meaningful way, as many people as possible, helping them in small and large ways. It’s mostly pride and desire to maximize the control over your environment: isn’t it awesome when everyone around you knows what you’ve been working on?

“You work on the search engine at Google? Wow, I use that every day!”

“You’re at Boeing developing the new 787? So many people are going to fly on that!”

A beautiful quote from a Microsoft engineer on this subject:

Very few projects at Microsoft have “small” impact. Everywhere you turn, the projects people are working on are likely to be used by thousands or millions of people. You have the opportunity to earn, save, or cost the company millions of dollars through your work. It’s an awesome responsibility, but an awesome chance to create widely influential software.

I’ve found a hole in this logic: it’s missing a key variable. It’s not just about the number of lives you touch. It’s also about the number of people that are working on this same product. The logic is simple: if there are thousands of people working side by side with you, your individual contribution will be lower. You will own and contribute to a smaller part of the puzzle.

Moreover, for technology projects, I’d argue the number of engineers working on the product has an even stronger, quadratic effect on each person’s influence. Ancient, yet so contemporary book Mythical Man Month makes this point well.

Here’s my attempt at quantitatively measuring your work influence number as an engineer in a high-tech company:

Let’s look at some examples:

  • Microsoft Office is one of the world’s most used products; yet there are quite a few engineers touching it. Spread-out, shared ecosystem of Office Shared services that own cross-product components and installation, as well as groups that own localization and documentation, makes the denominator in the equation above quite high.
  • Facebook is famous for having a restriction on the number of engineers that can work on a given product; I can’t find references to the exact number, but anecdotally, it’s under 10. So let’s say 10. Let’s look at the example of the Timeline: with Facebook’s 900M users, influence of an engineer working on that team is 900M/100 = 900K.
  • At Wetpaint, there are 3 engineers working on the website. Last month, we had 12 million readers. Influence of each engineer = 12M / 9 = 1.3M.

If you’re looking for your job to have influence – right out of the gate – work in a small, isolated team that has full control over its destiny. Startups are by definition structured this way.