Non-Linear Growth

A glimpse around the next corner; mind the curves.

Soccer, Fail Whales and APIs

I played a good bit of soccer as a kid and even more in college. I mostly played defensive positions. One of the things I most appreciate about the game is that the smallest of errors can have game-changing impact. As a defensive player, an errant pass in the mid-field or a moment out of position in your defensive zone can result in a goal. To borrow a term I don’t really like, solid defensive soccer requires “constant vigilance”. As a defensive player, you have to have your radar up all the time; scanning, marking, closing gaps, nothing can get through. It is as much a mental exercise as a physical one. There is no room for downtime.

Which brings me to the real topic of this post; APIs. Twitter is perhaps the business most frequently associated with the term API. This week, when I think about Twitter, I think about soccer (the World Cup to be precise). And when I think about Twitter and soccer, I think about the fail whale. With the World Cup in full stride, I’ve seen a lot of him the past couple of weeks; you probably have too. The World Cup is wreaking havoc on Twitter’s infrastructure.

But, you know what, it’s OK! The worst thing that will happen is that your urgent tweet about what your dog ate for breakfast will not reach your several hundred loyal follows who are too busy tweeting about their own useless drivel to notice that they have missed this earth-shaking news that Fifi loves coco puffs. (See Tweeting Too Hard for lots of examples.) Twitter has lots of room for downtime, because it is not a mission critical application and there are limited consequences.

The fail whale has become a cute little visitor we cherish seeing every once in a while because it reminds us how frivolous our participation in the twitterverse has become. The risk, however, is that we develop a mental association between downtime and APIs. Lets not confuse the term API with what is behind the API; service delivery infrastructure. They are not one in the same. An API is simply an access point into an infrastructure based service. When it comes to understanding issues of downtime, reliability, etc., the service delivery infrastructure behind the API is what really matters.

Lots of APIs link to mission critical transactional infrastructure. Think payment services (IP Commerce, PayPal X); think about voice services (Ribbit, CloudVox, Twilio); think Internet advertising infrastructure, which is linked together through APIs. Unlike Twitter, the services behind these APIs are truly mission critical. One misstep and few thousand payment transactions don’t get executed, a couple of hundred thousand advertising impressions are lost. Downtime has consequences; they are economic, quantifiable and impactful. The high stakes are what make these services compelling, valuable and difficult to replicate.

In my opinion, the tech community has become way too cavalier about APIs. We can change that by understanding that when it comes to APIs, what is behind the API is what matters. So when you see that fail whale this week and start cursing that “boring, low scoring World Cup soccer thing”, remember that it is the constant vigilance required in soccer that makes soccer the World’s game. There is no downtime allowed in soccer; and we shouldn’t tolerate downtime in APIs that access mission critical services infrastructure. Then remind yourself, that Twitter does not qualify as mission critical and have a good chuckle about the absurdity of your Twitter stream.

UPDATE: Funny timing, but Twitter rate-limited its API several hours after I posted this. Mission critical services don’t get to automatically degrade the quality of service they provide by rate-limiting traffic. Lets not ever confuse Twitter with a mission-critical infrastructure service.

Filed under: APIs, Cloud, Platforms, , , , , , ,

Why I’m Contrary on Compensation

When I was a teenager, I spent two summers working in a furniture manufacturing factory. The company, Steelcase, was (and still is) one of the largest office furniture manufacturers in the world. I worked in the binder-bin plant – a binder-bin is the cabinet that mounts on the back of your desk at about eye-level. I assembled the damn things. It was physically demanding (binder bins are heavy) and repetitive work. There was absolutely nothing intrinsically rewarding about the work; suffice to say, I did not enjoy it.

I was well paid though. I received a base wage rate plus a piece-rate, where I was paid an additional amount for each binder bin that I completed. The piece-rate was set based on meticulous analysis of the manufacturing process which determined how many units I should be able to produce per hour. The full-time factory workers, who were lovingly referred to as “factory rats”, were paid under the same scheme. This scheme was intended to motivate higher output on the manufacturing line.

A couple of weeks into my first summer, I figured out that I could improve my output of binder bins, and therefore my compensation, with a couple of tweaks in the process.  During lunch, I shared with some of the factory rats what I had discovered. Their response was not what I expected. Essentially, I was told:

You don’t get it. If you improve the process, management will modify the piece-rate component of our comp scheme. We’ll have to make more units to get the same total compensation. You’ll only be here for the summer, but we’ll have to live with that change forever. Don’t do it. Don’t ruin it for us.

The factory rats didn’t want to help the Company figure out how to produce more, because they didn’t believe they would receive more compensation for identifying ways to produce more. This was my first experience with what compensation experts call “if-then” rewards. I have been skeptical of “if-then” compensation schemes ever since. If this kind of pay for performance scheme doesn’t work for a mundane repetitive task, imagine what happens when you apply “if-then” rewards to knowledge work.

Established management philosophy treats all employees like the factory rats – with carrots and sticks. That philosophy says “I can cause you to do more of what I want you to do if I pay you when you do it” and “If you don’t do what I want, I will withhold rewards or worse punish you”. This is tantamount to giving a mouse a piece of food for pushing the blue button and shocking it if you push the red one.  The only problem is we’re not mice (or rats for that matter). WE’RE HUMAN and that makes us complicated. Carrots and sticks don’t work.

The first book I read on this topic (many years ago now) was Edwards Deming’s The New Economics. Yes, that Deming, the American-borne manufacturing process guru who helped to usher in Japanese domination of manufacturing process. It turns out that Deming was also a management psychologist who was well ahead of his time. Deming believed that we should abolish performance reviews in the workplace and grades in school. He felt that those types of subjective measurements of performance wiped out the employee’s/student’s intrinsic motivation. The employee’s goal becomes to please management, rather than to do good work. The student’s motivation becomes to get a good grade, as opposed to learn. It turns out that we complicated humans like to do good work and we enjoy learning; we are intrinsically motivated beings; external rewards and punishments get in the way.

Many years later, I’m encouraged that there is finally a new management regime beginning to take hold. It is best summarized in my most recent reading on this topic. Written by Daniel Pink, Drive: The Surprising Truth About What Motivates Us gives a good overview of the roots of our antiquated management/compensation philosophy and the science (much of which has been around for many years) that shows how flawed it is. Pink also offers insight into what we can do to change. To sum it up; pay people what they are worth, give them autonomy in their work, provide them the opportunity to master their craft and create a sense of purpose in the workplace. It is not that hard.

My own experiences, my personal reaction to comp. schemes I’ve had imposed on me in the past and years of reading on this topic (Here are my favorites) make me contrary on compensation. I’m done with carrots and sticks. How about you?

Note: For a good summary of Drive, check out this RSA Animate sketch narrated by Pink.

Filed under: Books, Economics, Lessons Learned, Venture Capital, , , , , , ,

Platforms: Of Governance and Taxes

I like analogies. This week, Brad Burnham of Union Square Ventures wrote a thoughtful post based on an analogy between software powered platforms and governments. Bob Warfield of the SmoothSpan Blog did a follow-up post claiming that application developers should seek platforms that act like Switzerland; something Warfield has apparently been saying since 2007. The government-platform analogy is good, albeit imperfect. The most salient aspects of the analogy are in the area of governance.

Governance is a critical role for any platform provider. David Evans, who I consider a leading expert on platform strategies, has long said that platforms have three primary roles in their ecosystem, “building, stimulating and governing”. From Chapter 2 of Catalyst Code, a book Evans co-authored:

Catalysts create communities, and communities need governance lest they devolve into anarchy. Catalysts enact rules and impose punishments, and they promulgate standards of behavior.

Evan’s use of the term Catalyst is synonymous to platform. So how do you know if the platform you are working with is going to play fair? As with most governments, it’s all about the rule of law and taxes.

The rule of law

The platform gets to make the rules, codified in the terms of service. Evaluate them carefully and ask these questions:

  1. Are the terms of service stable over time or do they change frequently?
  2. Do they restrict your freedom to operate or do they enable your fee will?
  3. Do they bind you to monetization services offered by the platform, or do they offer you the opportunity to work with monetization schemes provided by third parties?
  4. Do they enable the platform to compete with you, or do they make clear that the platform was established to help you become successful?

Taxes and platform monetization

Governments get their revenue from the collection of taxes; and the government gets to set its own tax code. The same goes for platforms, they get to determine how they will monetize their platform. If you are building on a platform, make sure the tax code is well established, stable and predictable. If the tax code is not clear, you are at risk.

Lots of Twitter application developers wrote their applications well before Twitter knew how it would monetize its platform. Said in the context of the government analogy; the Twitter platform emerged before Twitter had a tax code. The increasing tension between Twitter and the application developer community can be traced back to ambiguity in Twitter’s monetization strategy in the early days of the platform’s emergence. As Twitter’s monetization strategy has become more clear, Twitter has been forced to evolve its platform strategy. I’ve argued that we should no longer view Twitter as a platform, but rather as a consumer application. In Twitter’s case, it is clear to me that they have decided that the best way to monetize Twitter is to own and control the consumer experience, enabling them to offer advertising capabilities. Facebook suffers from the same tension as it is both consumer application and platform. If you don’t understand how your platform will monetize itself, your business model may very well be at risk.

To summarize, make sure you understand how your platform partner will govern. The rule of law and the tax code will tell you whether or not the platform is there to help you succeed or if it may compete with you one day.

Filed under: Platforms, , , , ,

My Twitter Feed

Follow

Get every new post delivered to your Inbox.