Startups and the expert opinion fallacy

Imagine 100 people in a stadium. Write down their heights, round it up and take the average. I don't know what your imaginary stadium looks like. Neither do I know who your imaginary 100 people are, but I can tell you for sure that the average you just wrote down is no more than 8 feet. Now, go back to the beginning and this time write down your contenders' wealth and take an average. This time, it would be impossible for me to give you a range of this average number. I can make a guess about the average height, because I know it to be impossible for a human being to be so tall to raise the height average of 100 people up by so much to take it over 8 feet. However it's completely possible to imagine only 1 of your 100 sample to take the average to $100M dollars or more from the global average of well below $10,000. By the way, how did you manage to get Bill Gates into a stadium?

If you are familiar with Nassim Nicholas Taleb's brilliant book, The Black Swan, you know that the above experiment is based on his book. Height, Taleb says belongs to Mediocristan where things live within normal ranges and events are more or less predictable with reasonably normal impacts. Wealth however belongs to Extremistan where there is no limit to attributes and highly improbable events have a huge impact. Now you can think of quite few attributes that belong to either of those universes: Weight, number of children or siblings and number of pages in a book belong to Mediocristan. Wealth, YouTube viewers and number of book copies sold on the other hand, belong to Extremistan.

The Black Swan, is about the impact of highly improbable. Until the 17th century people used to think swans are only white. It was simply not possible to think of a black swan. However, in 1697 the Dutch explorer Willem de Vlamingh discovered black swans in Australia. Following black swans, Mediocristan and Extremistan, Taleb tells us how predicting the future in Extremistan is impossible, futile and potentially a bad thing. He tells a convincing story of how self proclaimed "experts" fill up the airwaves and newspaper columns to tell us about the markets and other things from Extremistan where their opinions fare no better than a coin toss. In Thinking Fast and Slow, Daniel Kehneman, the Nobel prize laureate in economics, cites numerous experiments where not only the estimates of experts were worse than random guesses but actually worse than of the average population (who fared slightly better than random chance).

What about startups? Which world do they belong to? Repeating the same experiment with 100 startups this time, can you guess their average valuation? Would it be possible for a single startup in your randomly selected group to be as valuable as the rest put together? Common sense and our experience with Ubers, Dropboxes and thousands of failed startups suggests they certainly belong to Extremistan. This is confirmed if you believe how VCs think of their portfolios: most VCs think the Power Law applies to their portfolio where a single portfolio company can be responsible for the desired return of the entire cohort, hence their non-stop talk of the 10x return. Peter Thiel famously said of venture capital: We Don't Live In A Normal World; We Live Under A Power Law.

Now, don't get me wrong. I believe in mathematics as much as those VCs and cannot disagree with their logic of trying to find companies that will produce a 10x return for their funds to beat the market. My point is that, in a world so firmly grounded in Extremistan where events are unpredictable, improbable and have huge impacts, how do they pick the winner? More importantly, how do they, and the founders they pick predict the future, forecast it, plan for it and succeed?

Since predicting the future is not my specialty, let me rollback the clock and see how things turned out from no more than 15 years ago. It is 2003. You are an entrepreneur and founder of a new company that helps people connect with their friends online. You are sitting at a beautifully crafted walnut table in an amazingly designed conference room with a view of sycamore trees on Sandhill road, trying to convince a brilliant mind, reputable investor and Harvard MBA to invest in your company. To make your case, you produce charts, numbers and quotes in an attempt to show how the future is going to look like and how that future is going to make that man 10 times more money than he's investing in your company. This is 2003. Next year Google will be rolling out a social network called Orkut which for some reason will be very popular in a few random countries like Brazil and Iran but not in many other places. You've heard of a possible competitor called MySpace but not much more is known about them. Zuckerburg is still a spotty teenager living with his parents and Evan Williams has just sold Blogger to Google and it will be another 4 years for him to start Twitter. Snapchat founders are still asking their older brothers to buy them beer and What's App founders are in the queue of their local soup kitchen. Now, can you tell me how you predicted the way the world would turn out to be in the next 15 years, expressed your vision to the brilliant MBA in the room and avoided the people in white medical coats he consequently called in from the local mental asylum to take you there "to make you feel a bit better"?

I don't know the answer. If you are that person who's pitched a social network in 2003 to a VC, I'd love to hear your story. What I do know however is how things turned out to be, with the benefit of hindsight of course. I know Google abandoned Orkut for unknown reasons shortly after that. I know Facebook became popular with college students, until their parents showed up on the site so they had to leave Facebook for Instagram and Snapchat. I know everyone thought $1B is an insanely high price tag for Instagram until Facebook bought What's App for $19B and made Instagram founders look like losers. I know none of those who invested in What's App could give me a reason why they invested in it and more importantly none of those who didn't invest in What's App could tell me why they didn't. I know everyone thought Snapchat founders are rich, spoiled kids out of their minds for refusing a $3B acquisition offer until they went public. I know Twitter finally managed to be a business, more or less, or still is trying, this time in the public eye while Ev Williams started Medium to encourage long-reads, as if to resolve himself from his sins of making people's attention spans even shorter. I know once they realised they lost the social media game, Google tried to enter the market again with Google+ but didn't succeed and no one knows why they left the market they were in first and why they didn't succeed the second time with all their might.

I know all this because we all know it, and we all know it because it is 2018 now. We watched this crazy movie for 15 years and it's still not over. We don't know if the 2016 US elections is going to have a lasting impact on how social media advertisement is going to work and regulated. We don't know where the teenagers of tomorrow are going to hangout next year or if it involves disappearing pictures, enlarged eyeball video effects or cutified bunny ear face changers with voice modifiers that make you sound like a rat in a microwave.

We don't know these things because we haven't seen the rest of the movie yet but that's not the point. The point is there is nothing, absolutely nothing in the past events in this space that can be used as an indicator of what's coming next. In short, there is no value in history when you operate in Extremistan.

But now that the history has been played out, many "experts" have come out of the woodwork and tell us all about why Microsoft hasn't created it's own social media and why Google+ was a flop. If Facebook had sold to Yahoo! for $1B and turned into a social portal / media / advertisement entity with severe identity issues or had flopped and we were living in a Facebook-free world today, the same experts would have written hundreds of inches of OpEds on why and how accompanied by dozens of charts, numbers and quotes, trying to make sense of the highly improbable, high impact events and build their own personal brands and make a buck or two on the way.

The point is, startups are as extreme as Extremistan gets. As a founder, you can - and should - have a vision of the future. You can - and should - have faith in your ability to change the world (and reality) and execute your vision. Without the vision and borderline delusional faith, you won't be able to make it. You might even want to raise capital from some of those experts, known commonly as VCs to accelerate what's working for you. But don't confuse what's necessary for success with what makes you successful. More importantly, don't ever listen or believe the experts who weave stories about the past events to convince you they can use those events to predict the future.

Those experts, journalists, investors, MBAs, growth gurus or whatever, are like Turkeys thinking they've figured out life just because; today, they were fed great food for the 1000th day in a row just to learn today is this thing called the Thanksgiving! Those who survive, will be writing another story about what happened and how it can be avoided next time, until the next Black Swan event of their lives. Your job as founder is to avoid believing those who try to use the past events as a way to tell you how future would be in Extremistan.

How to waste $5M on containerized infrastructure

“We’ve built a 70,000-node Mesos cluster for our developers, but they won’t use it. Can you help?” This was the beginning of a conversation with the VP of infrastructure operations in a very large and famous company. While an impressive feat to accomplish, it was also by far the largest containerized infrastructure setup I had seen that had gone unused—nor, sadly, was it an isolated incident.

I’ve talked about this encounter with a large number of customers, analysts, friends, colleagues, partners, venture capitalists, and competitors. We all expressed similar experiences, and all wanted to know why this is so. After all, if so many resources are being wasted in our industry, we are all risking a great deal by not understanding and solving the problem. Otherwise, the next wave of adopters might start to doubt containers can help their businesses, and we would all need to starting polishing our resumes.

I have to be honest here: I am a developer, an engineer and a technologist who loves to build products and use the latest technologies. So, the first place I looked, in my quest to find an answer to this 70,000-node question, was the technologies used. Was Mesos the wrong technology? Was it implemented the wrong way? Did they use open source or closed source? Was there an SI involved? Questions like these came first to mind. In hindsight I think those were probably the wrong questions.

The answer came to me when I remembered a day in my career 15 years ago:

Sitting at my desk as a developer in a large bank, I remember impeccably dressed salespeople coming and going into our meeting rooms, courting our VP of infrastructure and his team. They were from VMware, back then the company for virtualized infrastructure. I was just a developer at the bank, but not even my boss or his boss or even his boss’s boss were invited to any of the steakhouse dinner events the VMware people were hosting almost every week. VMware salespeople were only interested in the operations and infrastructure decision makers. Two or three months later, our team was told that a deal with VMware had been signed and we would be moving our services over to VMs soon, and shortly after this move took place over a couple of weekends.

Then one Monday morning, the services my team were responsible for were running on VMs instead of the old bare-metal servers with flashing blue lights and noisy fans. That was all. Our entire infrastructure was virtualized in a matter of months without much say from the developers, and while we were putting on some fake resistance for this change (and who likes change after all?) and grudgingly agreeing to be on standby over a couple of weekends, we couldn’t really tell the difference between the old and the new setup: Everything was the same. Our VM servers behaved and felt like “real” servers. I am sure we wouldn’t have been able to tell the difference in a double-blind test if anyone had conducted one.

Remembering those days made me wonder why the new containerized wave of infrastructure change doesn’t work the same way. Why can’t we build a Mesos or Kubernetes cluster over a weekend or two and send a memo to the developers with the subject: “Welcome to the future of infrastructure. You’re welcome!”?

The answer as we all know is that containerization is not going to work without developers’ involvement and buyin. Developers need to build applications for a containerized setup, but inherent to containers, with APIs like Kubernetes exposed across the software life cycle, is the imperative for developers and operators to change the way they work and communicate with each other. The reason for a 70,000-node shiny cluster that runs tumbleweed instead of business applications is that the tools we have built for this new transition are not addressing this fundamental and essential organizational change, the meshing together of devs and ops.

The exciting reality is, setting up containerized infrastructure is getting easier, as there is an abundance of open source solutions that get you up and running with a Kubernetes cluster. If you are already running on a major cloud provider, you are simply a couple of clicks away from having your own containerized cluster, managed, serviced, and billed by the minute. The benefits of running a containerized infrastructure are visible to operations teams: single-configuration servers (no more “snowflakes”), built-in high availability and resilience, and improved resource utilization, to name just a few. Developers also see the value of running in a containerized setup: more influence over the running environment, improved control over libraries and dependencies, and narrowing the gap between production and development environments are some of those.

Each side of this equation (devs and ops) has its own vendors, tools, and open source projects to help them with what it takes to move to a containerized world—but that’s not enough. We are still missing the framework for devs and ops to work together to make this a success. There are simply very few, if any, tools and technologies available that facilitate this communication.

We are all so focused on our individual areas of innovation—from network to storage and orchestration—that we can lose focus on our customers’ achievement of their business goals. In such an environment, system integrator, consultancy and professional services companies do well, as they are the only ones who are focused on the result and on delivering across the software supply chain; but this is not sustainable. Technologies that require customers paying so much to consultancies to make them work are not going to be breakthrough technologies. Let’s face it: If virtualization needed McKinsey to be ever-present on the payroll for it to work, there would be no cloud today.

For us all to benefit from a breakthrough technology like infrastructure containerization, we need to think more broadly than our single-purpose tools or primary focus areas and rethink the way we build products for this industry. This is different from the revolution of virtualization and cloud, and the sooner we realize that, the greater the benefits to our customers.

Devops is not just a bunch of fragmented tools or a fancy “digital transformation” project, it is a method of working collaboratively between functions, enabled by technology. Therefore, any technology aimed at the devops market, specifically around containerization, also needs to address the continuous collaboration mindset before anything else. So, let’s all build products with that in mind to start and maintain a conversation between developers and operators.

This post was first published here

SaaS economy in the age of containers

The killer feature of any SaaS business is the massive reduction of operational cost and complexity including setup, configuration, ongoing maintenance and upgrades. Given the runaway success of SaaS in recent decades, we can clearly see that using a SaaS model instead of traditional shrink-wrapped software has made perfect financial sense for many customers. This in line with a theory that says that is a constant level of complexity in a system at any given time—IT organizations can deal with this by investing in-house (investing in a team that handles complexity), or outsourcing to a partner or SaaS/PaaS/IaaS vendor (exchanging money for complexity). When one combines the latter with an OpEx vs. CapEx financial model, easy installation/setup, and flexible pay-as-you-grow options—it becomes be very difficult to justify any other delivery model for generic software.

SaaS businesses, on the other hand, make this model profitable by distributing the operational running costs between many customers using (almost always) a subscription-based model. While legacy software delivery models share the same cost-spreading principle on the R&D level, they lack the ability to arbitrage the operational cost at the delivery level: it is costly to deliver a secure, highly available and continuously upgraded software at scale—and it takes a skilled team of developers and operators to deliver software within the customer-defined SLA boundaries, over time.

Since a large portion of the cost of SaaS development and delivery goes into building the robust and secure infrastructure needed to host the service, vendors make money by building and breaking up a large, robust infrastructure into smaller pieces of the same quality, and sells those pieces to many customers. SaaS infrastructure usually consists of many components—from databases to load balancers—each configured specifically to deliver the service in a particular way, with component-level high-availability (HA), redundancy and security requirements. Think of a typical CRM SaaS: you will need a multi-zone replicated database server, a group of load-balanced and securely firewalled frontend servers, and a cluster of servers to take care of background jobs and housekeeping of the system.

As an example, to keep the details of your 2,000 customers, you will need about 12 servers, two load balancers and several gigabytes of storage; on top of that, add the Ops team cost of maintaining those databases and servers—all of this probably represents a cost of $20k per month just to get going. To make things worse, even with this investment, you are not going to get anywhere near the five-9’s (99.999%) uptime that a SaaS vendor is going to give you at a fraction of the price. In this scenario it makes perfect sense to sign up for a SaaS alternative, paying $2,000 per month for a service that’s always up, upgraded and backed up.

This, however, might change

To see why, it’s worth understanding why running a highly available, secure and robust infrastructure is so expensive. When it comes to infrastructure, “the chain is as strong as its weakest link”. High availability and security cannot be achieved by only making parts of the system highly available and secure—this needs to be done across each and every component, which adds to the cost and complexity, increasing the bill even further.

Now, consider if all those requirements were built into a generic, self-healing, hyper-scale infrastructure, so any application running on top of it was inherently highly available, redundant and secure. This is the promise of containers. Instead of spending time on each service being delivered at a high SLA, the infrastructure takes care of this at the lower level, and provides these attributes as a service to the user. By doing this, containers take away one of the biggest benefits of the SaaS delivery model: infrastructure arbitrage, which I defined earlier in the post. 

Container-based infrastructure systems like Kubernetes allow companies of any size to build their own custom, highly-available and robust infrastructure on top of private data centers or public clouds, at a high granularity and flexibility, without compromising much in return. In this new world of container-based infrastructure, IT teams spend their time on building and maintaining a few Kubernetes clusters, while external vendors and in-house developers use those clusters to provide services to their clients.

It will probably take years to get to a point where this shift affects the SaaS industry at a significant level. However, if we look carefully, we can already see savvy IT teams who are looking to bring on this future: building pipelines for their code, as well as application management stacks that unlock the automation of containerised infrastructure, on both public and private cloud. 

The SaaS delivery model still has a lot of great things going for it—for one, it is now the dominant model for consuming software, wherever it sits or however it is procured. However, infrastructure arbitrage is not going to be one of its key advantages for long. While cloud computing was the killer application for virtualization, changing the economy of SaaS might be the killer application for containerization.

This post was first published here

On cancer and startups


Around 6 months ago, I received an email from Laura, our financial controller. It was the monthly financial projection of our company, but it was different from the previous projection emails in one crucial way: it showed we are going to run out of money in 6 months. Suddenly we were going to die.

It was late at night and while the urge to pick up the phone and call Laura was almost unbearable, I managed to hold back and think. Reflecting on my emotions, I couldn’t help but to have the same feeling as when I had a cancer scare some years back. It was the same feeling: the feeling of facing imminent death.

Naturally I went through all of our available options: raising more capital, taking pay cuts, or letting people go. None of those were good or feasible options. It was like driving at 100 mph and suddenly seeing a concrete wall on the road 50 meters away. Being paralyzed from the neck down on a life support machine might be the best outcome you can hope for.

A cocktail of fear and anxiety about the future, guilt and embarrassment for not seeing this coming, and confusion and hopelessness about the next steps had such strong paralyzing effect that I couldn’t think straight for a couple of hours. Gradually I managed to calm down and think through the options we had. But before firing off any emails, I wanted to talk to Laura and go through the numbers again.

The next day, first thing in the morning, we sat down and reviewed the numbers. It turned out a misunderstanding on some cashflow realization and rent payment caused the “runway” to drop to 6 months. We were not about to die after all! We made the changes in the spreadsheet and the concrete wall in the middle of the road was gone.

That episode, while triggered by a false alarm, made me think about life of startups and how they are similar to our own lives. The prospect of death brings focus and attention to the most important things in life. This is no different in startups. When faced with imminent death, I didn’t think “maybe we should build a new feature to get out of this” or “perhaps it would help to release our product as open source and get out of this by increasing the number of retweets we are going to have on the story”.

One option however looks deceiving: raising capital. On the surface raising capital might look like a reasonable way to get out of a running-out-of-money situation. I believe that’s not the case. I would go further and say raising external capital has become an overgrown part of the startup life. It’s not the cure; it’s the cancer itself.


No matter what the latest article on HackerNews or your favorite VC’s blog post tells you, your aim should be to build a profitable and purposeful business. All the land-grab, moonshot, “reach for the Mars,” “you are the next Elon Musk,” “build the next unicorn” hoo-ha is self serving for the VCs who want you to raise loads of money and burn it fast so they can get a 10x return or stop wasting their time with you and turn over to the next entrepreneur.

The question we should be asking ourselves is, did we escape the dogma of “living the corporate life” so we can live the dogma of “raise tons of money, go big or go bust”?

It seems to me that we might have overestimated the role of external capital in building a business. Our industry’s over-reliance on VCs is absurd, unhealthy, and downright dangerous.

Let me be clear here, I am not against raising money to grow an existing successful model. I also acknowledge that some businesses can only be built at scale which requires external capital. But those are exceptions, not rules.

To be fair to VCs, I also need to clarify something: my issue is not with external capital coming from the VCs. It is with having too much cash in the bank. In most startups, this is either by raising money from a VC or by the virtue of having a rich founder. No matter where your money comes from, if it is not from your customers, you are harming your business by having it. Those zeros next to your bank balance take the focus away from what’s most important in your startup’s life. They will fool you into thinking you should be spending your day in upgrading your infrastructure or building your next awesome feature. Would you be doing that if you only had 6 months to live?

I find it ironic that while many might look for external capital as a way of getting out of deathbed, it is the cancer-like growth of venture capital in the startup business that’s causing a lot of those businesses be on deathbed in the first place. This constant demand for building more, capturing more, and grabbing market faster without solid foundations of a business, serves investors very well and that’s why they propagate it in the startup market so readily, but most of us started a business to live our own lives and not someone else’s. It feels to me that many of us are now in danger of living a VC’s life instead.

It is true that “If you live each day as if it was your last, someday you’ll most certainly be right.” It certainly applies to us mortals and while it doesn’t have to be true for businesses we build, living by it is the best thing we can do to stay hungry and focused, both for ourselves and our startups.

Quotes in this article are from the Commencement speech given by Steve Jobs at Stanford University in 2005. For many, Steve Jobs is the guy who brought smartphones to the world but for thousands of entrepreneurs around the world, he is the inspiration to take on the daunting challenges of building a business and creating something new from nothing.

I read this speech every year or two to remind myself why I do what I do and I know many others who do the same. I invite you to listen to his talk if you haven’t done so already.

This post was first published here

Smart products, dumb designers

I own a Smart car. It is Smart only in name, especially the "Multimedia System" that comes with it.

Every morning when I get into my car and start it, the multimedia system comes on and plays the radio. I don't listen to radio much but my smart car probably thinks it is good for my mental stimulation and cultural cohesion. I disagree with the car and want to listen to Spotify on my iPhone connected via Bluetooth. So I wait for the multimedia system to connect to my phone. This takes about 20 to 30 seconds.

Once it is connected, I go to the Menu, select Media, then Bluetooth. My car shows each page with a smooth visual transition as if choreographed by a movie director: each page fades out and the next one slides in from behind while fading in with vivid orange colors. Beautiful. It takes 3 seconds for each page to run this transition.

So now 40 seconds later I have gone through 3 pages of menus to get to Bluetooth. Once I press Bluetooth, the multimedia system starts playing the same song from my iTunes: a song that begins with letter A. Every time with no exceptions. I never listen to iTunes (or Apple Music or whatever it's called now). I listen to Spotify, and I had just listened to Spotify at home before I left to get into my car, so I expect that to carry on. But my smart car thinks Apple Music is better for me.

So we disagree again, I stop the first song on my phone, open Spotify and play my favorite playlist. Well, not so fast.

Since connecting to my phone, my multimedia system decided it wants to download all my phone contacts first, and since it has the CPU power of a calculator in the '80s, this takes a couple of minutes at least, during which everything on the multimedia system slows down to grind. This is slowed down even further by interjecting alerts that it has "Downloaded contacts" or "198 traffic incidents received". Why do I need to have my contacts on my car and why would I want to know that there are 198 traffic incidents in town that morning is beyond me, but my multimedia system thinks it's a useful piece of information. Perhaps I'm supposed to spot a trend in the number of traffic incidents in the city. I wait patiently for technology to be helpful in its own way.

So now, about 2 minutes after getting into my car, I am ready to listen to my favorite music and drive off to work. This is my daily dance with a bad product.

My car's multimedia system also uses a car icon instead of an arrow in the GPS navigation. Better still, it allows me to change the color of this car icon. I have a choice of about 42 different icons of Smart cars with different models and colors to choose from. I never change that, of course, but my children love that feature. The first thing they do when they are in the car is to choose the color of the car icon for the day. I don't mind the feature. Its uselessness and its appeal to 10 year olds who clearly are not the primary users of a driving navigation system is puzzling, but hey, what's the harm?

As someone responsible for a product, I'm intrigued by my car's multimedia system. What possessed the design team to decided they need to have 42 cars to choose from in a GPS navigation system when almost every mobile on the planet uses an arrow and is completely fine? Or why is downloading all my phone contacts to the car is needed (for the voice commands I guess, another useless feature when you have a smartphone) and why is this something that should happen right after connection, which is when most people need to interact with the UI before driving?

Do they actually ever drive their own cars or they just love listening to radio every morning? Because there is no other way not to notice the issue with this daily dance of technology.

As a customer and user of this multimedia system I am not annoyed by the complexity of the UI as much as the daily inconvenience I have to face every day, however minor they might be. Inconveniences like this add up to frustration while configurability of a GPS navigation icon is just silly.

Many product startups know the value of minimalism and "doing less." They focus on doing fewer things and doing them well. Asking for a new feature from many of them is most likely going to get a "no" answer, and for all the right reasons. I, however, think that customer churn is not caused by silly or unwanted features. Even edge-case missing features are not a big factor in customer churn: it is these daily inconveniences that contribute to churn the most.

As a product designer, you need to be able to see your product with a fresh pair of eyes and see if often and regularly. You need to be the primary and first user of your own product and notice how you work around inconveniences caused by bad design or poor quality in your product without getting used to or blind to it.

If those who designed my car multimedia system used it every day themselves, I wasn't going to look for CarPlay in my next car. I not going to buy a car because it's called Smart. I would buy a car called Dumb as long as its designers are smart.

This post was first published here

Party like it’s 1999












This post was first published here

The startup pitch: It’s a short elevator ride

If you've been part of any startup accelerator or have talked to a "startup mentor" you know how obsessed most of them can be with the elevator pitch i.e. the ability to explain your idea or business during a short elevator ride. During my time working at startups, I've heard different versions of this ranging from the beer mat pitch (a pitch that can be written on a beer mat and explained to a fellow drinker at the bar) to the grandma (or granny to my fellow Brits) pitch, which is describing your business in terms your grandma would understand.

I've always disagreed with these notions and at this point in my life, having founded several companies and running Cloud 66 for about 4 years, I'm pretty sure I'm right. The elevator pitch is useless, the beer mat pitch is a waste of time, and grandma's pitch is just plain old stupid.

Elevator pitch issues relate to two areas: context and goal.

To illustrate my point, allow me to introduce you to Paul. Paul is a Professor of Applied Mathematics at UC Berkeley. I'm sure you know what it means to be an Applied Mathematics professor. I wouldn't be surprised if you assumed he must be a good professor, since he teaches at a university like UC Berkeley. You might even be able to accurately guess his age and even picture his appearance in your mind.

This is because you have a great deal of context and an existing pattern in your mind about what Paul does. You know what Applied Mathematics is. You know what a university is and what being a professor means. You know UC Berkeley is a good university and might know it has a particularly good Applied Mathematics faculty.

Now imagine you didn't know any of this. Let's see how he'll fare pitching his work in an elevator:

Me: So, Paul. What do you do?
Paul: I'm a professor of Applied Mathematics at UC Berkeley.
Me: [looking confused]. Hmmm.... I know what mathematics is. But what's applied mathematics?
Paul: It's the practice of finding uses of mathematics in science, engineering, business, computer science, and industry.
Me: Right. I think I have an idea. So what's UC Berkeley?
Paul: Erm.... It's a university in Berkeley, California.
Me: University, eh? What do you do there?
Paul: I'm a professor.
Me: What's a professor?
Paul: [murmurs something] ... I help people gain a better understanding of the world by providing them with regular lectures and introduce them to instructional books.
Me: Ah! Now I get it! Like a school teacher, right? But what's your USP? Why not just call yourself a teacher instead?

At this point, we've ran out of beer mats, grandma is snoozing on her rocking chair, and the elevator has reached the roof garden and people are waiting for us to leave so they can get in.

OK. So this example might seem slightly bizarre. Paul's elevator pitch would have ended after his first sentence with a relatively good understanding of the job he's communicated to me. Because I have context.

But while it's difficult to think of someone who doesn't know what a university or professor are, it's completely plausible to imagine the same assumptions being impossible if Paul was pitching a cold laser surgical scalpel for retina surgery. In this scenario, it's not hard to imagine me asking him, what's a cold laser? What's retina surgery? Why cold? Is there a warm one? What's the USP? How is this different from any other scalpel?

The problem is, many startups work in cutting edge science and technology fields. Fields that inherently have few people with insights into them. That's the exact reason they can build something new: Because they know something others don't. The context is seldom as commonly shared for those types of companies. As a result, elevator pitches for startups have evolved to take on 3 different guises:

  1. Useless or meaningless: "We help companies turn into social enterprises"
  2. Incomprehensible: "We reduce tissue damage by using flexible fibre CO2 lasers"
  3. Relative: "We're the Airbnb for washing machines"

You can see how only the third one is useful in communicating something meaningful, because it benefits from a shared context. I know what Airbnb and washing machines are. Frankly this isn't unique or a particularly new insight. This is what communication is. This is what we humans do when we communicate: start from a common ground and build new pieces on top of it.

It's often said that the aim of an elevator pitch is to get the other side to ask intelligent questions and guide them through the course of understanding your business. While I agree that this is a method to engage people, the goal of an elevator pitch for a startup isn't to be a conversational piece. It's to go get investment, form a partnership, or sell a product -- not start a conversation.

Given the goal, it's justified to ask a simple question: "How likely is it to get investment from someone who doesn't even have a contextual understanding of your field? How useful is that investment going to be? And how likely is it to sell your cold laser scalpel to a removal van driver?"

While it's possible for those conversations to turn into a business transaction, it's not the most optimized way of approaching a business deal. The scarcest thing in a startup is time. Waste your time and you'll watch your startup die. It's the same thing.

But not all startups specialize in cold laser scalpels. A dating website, an online cookery school or a mobile gaming app startup can benefit from elevator pitches, precisely for the reason that people will share their context with you. But if you're building a business on new frontiers, solving hard or novel problems -- what Sam Altman called Hard Tech Startups -- elevator, beer mat, or grandma pitches are as efficient as advertising lease time of the Large Hadron Collider on TV during prime time Saturday night viewing. It might work, but it's quite likely not to.

So do your homework. Find relevant investors and business partners who don't need priming about your business. You have a short elevator ride. Don't waste it on context.

This post was first published here

Google's infrastructure for everyone else

Our office in San Francisco has communal bathroom facilities, which like other communal areas, gets thoroughly cleaned every morning. But everyday around 5pm, if you go to the men's restrooms you’re usually confronted with a pool of urine right in front of the urinals.

This is obviously not a pleasant experience for anyone, including those who contribute to the aforementioned pool of fluids. So it got me thinking: Why does this happen? And why would you not stand just that little bit closer to the porcelain to avoid pool formations by the end of the day?

I couldn't really think of a reason, but I thought of a solution: Printing a sign and attaching it at eye level that reads: You’re not as big as you think, please step closer!

I haven't tried this solution yet. I might report on the success or failure of it in a future post, however it made me think about a current industry trend: Google Infrastructure For Everyone Else or in short and cute form: GIFEE.

This term was coined by fellow container evangelist companies, who are trying to sell Google's way of managing its infrastructure to the rest of us. We’re told that Google is millions of light years ahead of everyone else in building and managing infrastructure. And we’re told that Google has been running containers in production for everything since the dawn of time in a system called Borg. We’re also told that products like Kubernetes are based on Borg and are built to help us benefit from their years of experience in the field.

I think most of what we’re told is true: Google is indeed light years ahead of many others in running infrastructure. I also have no reason to believe Google hasn’t been using containers in production, nor do I think systems like Borg don't exist.

I would, however, question two things: Kubernetes was built by Google to make us benefit from their expertise in running containers and that everyone is better off running infrastructure like Google.

The truth is, Google is unique. With all the talk about unicorns and the next Google and Facebook, the likelihood of your startup making it to unicorn league, let alone becoming the next Google is less than being hit by lightning, while eating an ice cream as you're swimming away from a shark attack during The X Factor final.

That's OK. Not being a unicorn with a valuation in billions and VCs falling over themselves to give you money, there’s a decent chance you can build a profitable business you can be proud of. Let's be honest with each other, you won't sign up Price Waterhouse Cooper (PwC) or Ernst and Young for your accounting, Merrill Lynch to run your current account, and attend Davos instead of the next Ruby Meetup.

But wait, doesn't Google use PwC and Merrill Lynch, and isn't Eric Schmidt part of the furniture at Davos? So why wouldn’t you do the same?

The answer is simple; those services are built for Google size. You don't find a company saying GAFEE (Google Accounting For Everyone Else). That would be ridiculously absurd, and we all know that. Interestingly, Google's accounts are more likely to look like a normal multinational than their infrastructure. I can think of at least a dozen companies that have the same accounting practices as Google: Unilever, Procter and Gamble, Glaxo Smith Klein, Volkswagen, Exxon Mobile, British Petroleum ... but none of them are anything like Google in terms of infrastructure sophistication, and we can imagine why.

“So what's the problem,” you might ask? "OK, we get the point, we’re not as big as Google and we don't use Google's accountants because their practices don't apply to us (or are too expensive).”

“But what's wrong with using Google's infrastructure when they’re giving it to us for free?" I hear you say.

In reality, it's not all about the nominal price. Getting Merrill Lynch to do your banking. even if it’s for free, might not be a good idea for your company because of the burden it puts on you and your admin department. The situation would be akin to taking a Formula One car to do the school run at best.

The issue is, by using tools that aren’t built for your goals, size. and achievable targets, you’ll be burdening your business with unnecessary complications that can be avoided both now and in the future. As software engineers, we’re familiar with Donald Knuth’s saying: premature optimization is the root of all evil.

Why does Google promote tools like Kubernetes? Google's promotion of containers is a lot about taking on Amazon. In short, Google has no way to take on AWS in their game of compute, network and storage -- the traditional blocks of cloud computing. But they have a lot of experience in running infrastructure that doesn't provide those traditional components since they’re using containers. By promoting containers as the building blocks of infrastructure, they’re hoping to leapfrog over Amazon to become the infrastructure setup of the future. Their advertisement campaign for Google Cloud Engine also points to this goal.

You surely noticed how I said “infrastructure setup of the future.” I see containers as the building blocks of this infrastructure (otherwise I wouldn't be spending every waking moment of my life building a business based on this premise). While I think we’re going to be better off building our next-gen infrastructure based on containers, I don’t think we all need to build and manage like Google via these super configurable and modular tools. Most of us need simple tools that just work and get out of the way to let us do what we should: build a business.

By using tools that aren’t right for our size, we run the risk of contributing to and stepping in a pool of urine as the day draws to an end. It’s not only harmful technically, the administrative costs can also quickly become a burden. As a start-up, we all want to believe we’re destined for greatness as the next big thing. Mentally, chasing after an aspiration to become the next unicorn makes us into an unsustainable business, addicted to where the next round of funding is coming from. We see this everyday in Silicon Valley, and trying to imitate Google’s infrastructure is just one aspect of this mentality.

And if all else fails, it's always useful to have a cautionary sign in front of us as a reminder: You’re not as big as you think you are, please step closer!

This post was first published here

Defining the 'open' in open source


















This post was published first here

Why tech journalism needs more tech experience

On last count, Jeremy Clarkson, the infamous creator and presenter of "Top Gear," the world's most famous car show owned a Ford GT, a Mercedes SL55 AMG, a Ferrari F355, a Lamborghini Gallardo Spyder, a Jaguar XJR, a Volvo XC90 SUV, a Toyota Land Cruiser SUV, and an ex-military Land Rover Defender. Richard Hammond his co-presenter, drives a classic Morgan, a Porsche 911 GTS, a 1965 Open Kadett plus 2 Land Rovers, while the other "Top Gear" presenter, James May has a pilot license and drives a Bentley T2, Fiat Panda, Jaguar XJS, Mini Cooper, Porsche Boxter S, Porsche 911 and a Range Rover. That's 21 cars!

It is no secret that these guys love cars and know a thing or two about driving them. Clarkson, Hammond, and May are lucky, rich, and influential because they have made "Top Gear" an extremely successful TV show about cars. Car companies fall over themselves to get a slot on the program for a review of their latest supercars and the commentary provided by the program has a great influence on serious car buyers' decision.

Watching an episode of "Top Gear," you cannot help but to feel the presenters' passion about cars and admire their expertise on the subject. I think that passion and expertise is an integral part of the global influence and success of "Top Gear" and the respect it rightly deserves.

Now let's imagine a car show where the presenters don't know how to drive a car, have no driving license, and never have owned a car in their lives. It is hard to see how a program like that is going to be successful, influential, or predict the next big thing in the automotive industry.

The sad reality of software journalism is that the number of journalists writing about the software business who can code or have written a line of code in their lives is less than the number of fingers on your left hand.

As someone who's developed software and read about software for more than 20 years, I still cannot comprehend how a software columnist can comment on success and failure of a product without having the skill-set to try it before forming his or her opinion on the matter. Read the writings of Joel Spolsky, a developer and creator of Stack Overflow and Trello and compare it with the commentaries you read about Docker or cloud computing on the tech media, and the difference becomes clear.

Examples of tech media missing the trend and trying to jump on the bandwagon after the horse has bolted is far too many to count. Github, Docker, and AWS are all examples of companies that made some existing technology easy to use by developers and there was no way for a non-developer to understand how they add value and why they are going to be successful. It's just impossible for someone who hasn't used Linux containers to predict Docker is going to be huge. 

It is interesting to see how Paul Graham writes about how you should build a successful company: Build something for yourself, he insists. As software developers, we are naturally going to build thing we use as software developers. Being our own first users enables us to build great tools and improve them every day. This is the story of Slack.

Slack was built by software developers to be used in software developer teams. That's what makes using it so great for everyone. First and foremost, it's the experience that made it great. As a software development team, we couldn't wait to get an invite for Slack so we can start using it. Two years later, many of my non-developer friends still don't get Slack. How can I ever expect them to have seen it coming before it was old news if they are not users of the product?

Open source is becoming more important in the enterprise and large companies are trying to court developers to have a place at the table for the next generation of the big companies. But tech journalists are still following the tired patterns about "the next big thing" -- the amount of money raised by the company or the moves of the largest players in the market -- instead of finding out what actually makes a product so successful in the developer space.

Let me be up front about this: I have nothing against tech journalists. However, I think we as a community will benefit from informed commentary on trends of our industry. A commentary fueled by knowledge, experience, and passion about technology in general and software in particular. After all, if software is eating the world, we developers of this world, should become better at writing about what we do, where we are taking software, and what the world can expect from the fruits of our labor.

That's why I accepted the offer of writing for InfoWorld: I am a developer. My work is eating the world, and I am best positioned to tell you about it. Let's talk!

This post was originally published here