Sunday, April 13, 2008
I wanted to start writing a little bit about the role of a CTO in a startup company. There's a wide range of behaviors in that role from the more execution oriented engineering manager to inventing a fair amount of the technology to a visionary steward who directs the company towards the optimum market value. I have played many roles in multiple companies across this continuum and wanted to get a few thoughts down that may be of help to others out there trying to make sense of this elusive function.
A CTO is the Chief Technology Officer in the company. In more well established companies this is a contributing role that would typically report up through the Chief Information Officer (CIO). In a technology startup, the CTO role is critical for the successful launch of the company. It all starts with the idea, and in many cases the CTO is not only the founder but the individual who had the idea and the knowledge to determine whether implementing the idea is likely. For the moment though I would like to set aside the notion of solution probability.
Ideas often start with personal pain. Engineers, or rather inventors are inherently lazy. When confronted with a problem, an inventor will ironically go to great lengths, often expending much more energy than giving in to the brute force approach, to try to find a short cut solution. The brainstorming that follows traverses a series of what if's with numerous cerebral dead ends. The beauty of this stage is in the search for the possible and you may have no f*cking clue how likely a solution is but are making probability guesses based upon incomplete knowledge. For instance, in my last company, Dante Software, I had just finished reading the O'Reilly book on Perl for Bionformatics. I was currently the CTO of a Web 1.5 services company where we built Commerce, Content, and Community sites. I'm going to give myself a smallish bit of credit here for incorporating community directly in the site, although I didn't recognize the importance it was going to play in the future. Anyway, we would continually have issues with system performance and outages that impacted the business. The aha moment came after reading the bioinformatics book and realizing that the web business and it's integration to traditional parts of the business had become specialized and the interactions complicated enough that a similar model in bioinformatics to track protein-protein interactions for disease detection was not all that far off from what I was trying to solve. That is, I wanted to detect problem conditions that could impact the business before they became problems for my customers without having to know what alert thresholds to place on every possible metric in the underlaying IT stack.
Now I have a big hairy problem. There's nothing out there solving it (as far as we know). And there's a solution model in a completely different space that looks like it might be adaptable or at least used as a guide for my problem. Aha, idea born. This could work! The next step is to reverse engineer the problem and map to the proposed solution to come up with a reasonable guess as to how it might work. Then researching whether something already exists that may be close enough or could get there faster than you. And SWAG (silly wild ass guess) how long it would take you to prototype. But these are market and time to market questions. I'll address those later. It's a great feeling just to sit with your idea for a bit and relish the brilliance of it before taking that next scary step of analysis. This will be a long road. Right now you need to build up your confidence to herculean levels :)
I remember once telling a VC at this stage about an idea and they said how about company X, haven't they been working on something similar for the last few months. Knowing the people in the other company and having an inflated sense of confidence in my ability to get this idea off the ground, I looked him straight in the eye and said "We'll crush them". ;)