In my last post, I talked about super developers and the skills and traits that might make them inclined to become startup CTO’s. There is no doubt that developers with the speed and skills that I outlined are capable of delivering early versions of a website, application, or software product. But, it’s been my experience that these skills alone are not enough. In fact, developers with only this skill set that choose the CTO startup route could create a disaster not only for the startup, but for their careers as well.

Good developers themselves should know why this is the case. They know that when developing a software product, the coding of the product should be the easy part. They’ll tell you that if you have good requirements, if you identify the scope of each feature correctly, if you prioritize your stories, if you design before code, and especially if you follow a test driven methodology and develop unit tests before coding, then this is true, the coding becomes the easy part. But here is the disconnect: all these things, developing requirements, priorities, and testing methodologies are all very difficult to achieve and may be overkill in a startup.

In my experience, one key role of a startup CTO is to quickly determine how much effort should be applied to these different disciplines and tasks in developing software. Does the feature require prototyping? Does the user interface need testing? Could performance be an issue and should this be tested? To what degree, if any, should the code for a feature set be designed for reuse? Identifying how much investment in time or money in a feature is a key question for any development exercise but is absolutely critical in a startup.

So the quick answer to the question of whether a guru developer can be a startup CTO is a maybe, but probably not. A fast developer that jumps into feature design, software design, and coding will fail to recognize the costs and risks of the development exercises.

A guru developer also needs skills in project management, software QA, and some experience negotiating with business people on requirements. They need experience working with small teams and have to be strong at informal methods of estimating cost and risk.

But is that enough? It’s a start but I’ll elaborate in my next posts.