How to have a happy CTO & CEO marriage

In a web-based startup company the most important relationship is often between the CEO and CTO.

VC Brad Feld touches on this issue in a pair of posts today (The Constipation of Scale and Lighten Up / Tighten Up). As he correctly points out the relationship frequently hits the skids when faced with the inevitable drama of: scale vs. features.

The scale vs. features story goes something like this:

  • a) building services that “scale” (i.e. can grow to support a large number of people) takes much longer than building services that “don’t scale.” This typically has to do with issues around how a site is actually coded. For example if you had blog software that showed 10 blog posts per page and each of those blog posts showed the number of comments on it you could code the software to do a database lookup for “number of comments” ten times or you could “cache” that information in a table on the database server so it was “one lookup.” If you have 10 people come to your website each day it makes little difference, but if you have a million people come a day you have 10M database lookups vs. 1M (or none, again depending on how you code it). However, the amount of time it takes to make “optimized pages” takes five days vs. one day of programming.
  • b) The CEO wants to show the board of a company, the press, and the users ten new features. Each feature will take one day to code if you don’t care about scaling or a week to code each if you want it to scale. So, in that example it could take two weeks or almost three months to produce the same forward-facing product.
  • c) At the start of a company, when getting attention is important folks rush features out the door to impress folks like investors or the press. Then the service gets a crush of users based on those features and the service shuts down.
  • d) The CTO goes to the CEO and says “I told you so… we should have built this to scale” and the CEO goes “I wouldn’t have been able to get us all this press, the users, and the VC investment if we didn’t have those features!” Thus starts the problem.
  • e) The CEO gets hammered for the site being down and takes it our on the CTO. The CTO has to rush and clean up the mess while everyone is in a panic that the service is down. All the while the board, the press, investors, and reality of competition insists that you add more features–so, you’re back to the “should we build to scale or not” question all over again. Then the CTO can play the “I told you so” card, and the CEO has to play the “I have to replace you with someone who can go fast at scale” card. It breaks down real quick.

The correct answer to the “should we build this to scale” question is dependent on a number of factors. Of course, in a perfect world you would have 20 developers, tons of cash laying around, and no competitors chasing you down with features and showing them off to the press. However, the reality is that you’re going to cut corners at times for strategic reasons and that’s OK.

Here are the factors you have to consider when making a decision to build something to scale or to just “get it out the door:”

  1. How many people are actually going to use this feature? Is it something buried on the user interface or is it on the homepage?
  2. How important is getting this feature out there to the business? Is this going to be a game changer in terms of closing financing, getting onstage at a major tech event, or landing a partnership?
  3. What other features are you neglecting by making this “get it out the door” feature?
  4. How much time will it take to “redo” an “out the door” feature into an “scale” feature.

In some cases showing off a couple of “get it out the door” features as a teaser serves a very real purpose. When we were raising capital for Mahalo I showed folks the Mahalo Follow toolbar. It was a framework, but it certainly wasn’t ready to scale. However, we knew this feature wasn’t going to be released to the public for six months and the work put into the prototype was well worth it because we needed to have VCs understand what a “clean dataset” could do when combined with a kick-ass API. Note: VCs and the press tend to have a hard time imagining things (probably because they get BSed so often), so it’s best to show them a prototype even if it is one that doesn’t scale at the moment.

If we were building Mahalo Follow today I wouldn’t need a prototype version three or four weeks early. There’s no need to impress the VCs who’ve already invested, I can tell them it will be online in a month and show them some design mockups and be done with the conversation. Different times but the same core factors can lead to a different decision sometimes.

Microsoft was famous for pushing a version of the “non-scale” concept and it was called “vaporware.” The concept was to show screen shots, canned demos, and even just rumors about a product in order to ankle a competitor. I remember when I was installing Lotus Notes as an IT guy in the early 90s there were rumors of “Microsoft’s Lotus Notes killer” coming right around the corner. You know what? It worked. Many businesses just held out and never tried Lotus Notes for fear they would invest $400 a desktop on it only to replace it with Microsoft’s killer. Of course, the Lotus Notes killer never arrived. Go figure.

Now, back to the relationship between CEOs and CTOs. In most cases CTOs will want to build at scale and CEOs will want ammunition in the form of features. When you’re a CEO out there at an investors meeting or a meeting with a press you need bullets, and bullets are features. Going to a VC or a press person and saying “our website can now handle 1M more users a day” and you’ll get a blank stare that scream “Who cares?!”

The press, conference attendees, and investors want candy… and CTOs give the CEOs the candy to give out. Call it “feature crack” if you wanta stronger metaphor, but it’s the reality. Kevin Rose spoke at the last Web 2.0 conference and showed two very slick visualizations of the digg dataset. Everyone went wild… they were very, very cool. Of course, these visualizations will have zero impact on digg’s business. None. They are pure feature crack intended to get folks high for a short period of time, Kevin is a genius for doing it.

Now, if you’re site is down all the time that’s when the crack comes home to roost. Twitter got their ass-kicked for a month or two this past year. Their inability to scale their service set the stage for… wait for it…. Kevin Rose to come in with Pownce and take much of their steam.

Pownce of course had a couple of new features that Twitter didn’t, and now Twitter is left going “hmmm… do we play catch up or build things right?” Perhaps Twitter is moving to slow and losing mindshare OR is Twitter moving slow and KEEPING a ton of happy customers looking for a stable solution. It’s hard to tell sometimes isn’t it?

Taking a page from Kevin’s playbook they hired the same design company that Kevin did to do crack-visualizations of Twitter dataset. Again, these visualizations are nothing more that a “ohhhhhhh…. ahhhhhh…. ” crack hit. They don’t do anything for the business or for the users at the end of the day. HOWEVER, they might bring in a sponsor or get some nice press/mindshare for Twitter. That’s part of the game we’re in, so in that way they are important.

So, how do you balance “crack hit” features with a healthy lifestyle filled with scale you’re probably asking right now?

My long-time collaborator and friend Brian Alvey and I had the CEO/CTO relationship essentially three times. The first two I was the owner the business and the last one we were partners. In the first two life was easier in the sense that our professional relationship was one of employer and employee (of course, layered with a long-standing friendship). At Weblogs, Inc. however the relationship had changed since both Brian and I were equal owners of the business. Sure, I was the CEO and the front man, but Brian and I had equal say in where we took the company.

At Weblogs, Inc. I decided I couldn’t just tell Brian “do this please” as I’d done in the past. He would obviously come back and say “why are we doing that and not this?” So, I brought Brian into my thinking process and said “I need some crack for this trade show” or “investor meeting.” I don’t need it to scale, I don’t care if it breaks… it’s just to show folks what could be. Of course, I’d always be upfront when showing these things saying “this is a mock up.”

Once Brian understood what I was doing–and that took all of 60 seconds–we were on the same sheet of music. I’d tell him when I needed features to show off and he would balance that with building a great service. “Get me some crack” I’d tell him… anything. I need something.

That, in my experience, is the sweet spot. If you can understand what the CTO is going through (no credit for being up and a million arrows for being down), then agree with them on when you move in and out of scale mode, you’ll have a health relationship.

As CEO if the service goes down after you insisted that something be done on the cheap you have to step in front of those arrows. I did this many times, telling folks at the company “I didn’t give Brian the resources to do this right… this one is my fault.”

If everyone feels they are in on the decisions together it gets a lot easier. That’s my advice… make you CTO your partner, don’t blame them for things you’ve caused, and stratigize with them–NOT AT THEM.

Leave a Reply