Startup CTO mistakes I'd rather not repeat...

I write this as I am seemingly on the cusp of getting involved in another startup, one way or another. Either the game I'm working on will start making money, or I'll get dragged into one of the many projects my friends and acquaintances are dreaming up. So now seems a good time to reflect on some of the bigger mistakes I've made, and in the process hopefully avoid repeating them.

Now, we shouldn't be too hard on ourselves for making mistakes. In all of my personal, educational and business pursuits, I have yet to see a method of learning that doesn't involve making some as part of the process. This is a reality I'm trying to impress upon my seven year old daughter, who has somehow gotten into her head the notion that she should be able to do anything she sets her mind to the first time she tries it, and will typically go into hysterics upon discovering that it's not that easy. She's starting to get the idea, and she's starting to recognize that laughing at your mistakes, owning them, and moving on is a lot better than wasting a bunch of time crying over them.

That said, with mistakes as the basis for learning, I learned a lot at my first startup. What follows are just a few of the highlights. Enjoy!

Not getting involved in "the business"

This seems to be far and away one of the bigger mistakes I've made; assuming that the "T" in the title somehow absolves the Chief Technology Officer of worrying about or considering much what "the business" is doing. In reality, there is no "business side". Chances are good the technology is the business. The CTO needs to be on top of what marketing has up its sleeve, what countries/demographics/markets/opportunities the CEO is dreaming about, what the CFO thinks of the IT budget, never mind the fact that HR is dying to get an intranet going. If you don't touch base with these people regularly, and become part of helping them achieve their plans, they'll find ways to get things done without you. And it's almost guaranteed to be in a fashion that's not in alignment with your technology vision. About that...

Keeping the technology vision in your head

While there's a lot of conflicting opinions with respect to what the CTO role actually involves, it appears there is some consensus that evangelism is part of the role. Do you see your niche product actually becoming the platform for your vertical or beyond? Do you see your company's expertise in a particular technology being leveraged beyond the confines of its current product or market? Well then tell somebody. Tell everybody. A typical reason for not doing so is the ever-present product backlog. "There's no point talking about our technology vision, 'cause we won't be in a position to fulfill it for two years and I don't want folks to get distracted", you might tell yourself. Know what? You're wrong. You won't get around to it ever with that attitude, because it will never become part of anybody's reality unless you make it so. Besides, two years from now your product backlog will be even bigger.

Adopting bleeding-edge technology

So, back in the day (around 1999 or so), I really figured part of being a good CTO was finding that heretofore-unknown-but-up-and-coming piece of technology that would give you The Edge over your competitors. You know, that magic, silver bullet that would run 10x faster and enable 10x faster development cycles. So I went out and got us an object-oriented database.

The result? Well, I did think that it enabled slightly faster development times. There were significant caveats, however. Using their easiest "transparent" API meant that all servers in the cluster had to run the latest schema (no incremental deployment for you, my friend). Further, online backups were problematic, and we really loved it when the database server needed a restart and would come up in "recovery" mode with no progress indication, staying that way for a half hour or so.

Details aside, think twice before looking to fancy technology as a core piece of your strategy. If you think you need it, at least try to sandbox the financial and technical risk.

Giving up control of the development process

Some CTOs operate solely as a "technology visionary", and operate from the sidelines, much like a cheerleader (see "Model 2: CTO as Big Thinker" from The Role of the CTO: Four Models for Success by Tom Berray). However, I find Eric Ries' comments more in agreement with my own experience. As a CTO, it became much harder to drive product and technology innovation once I shifted managerial responsibilities sideways.

Staying too hands-on and not getting hands-on enough

This is a tough one to get right. Right up to the point where I had a team of about thirty people, I could still write a little code, and assist with design of every major feature. But that was pretty much the breaking point. However, as I tried to teach myself to let go, inevitably some features made it out the door in, let's say, a less than desirable state. I chalk this one up to focusing on the wrong things. I had focused on the product too much, and didn't spend enough time with people and process. As a CTO, it's important to stay somewhat hands-on. Write a little code. Do a little design. But choose wisely, and use each of these hands-on efforts as an opportunity to teach and mentor. Let your team make some mistakes in the early days, but more importantly, have a process in place that makes recovery easy and automatic.


So those are five fairly big mistakes I hope not to repeat. Maybe you've made some of the same ones. There are, of course, many more. Stick around!