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!

Scrumy update...

I sent my comments in to the Scrumy guys, and Dan responded by saying "We converted your seven bucks into 17,276 Colombian Pesos and we're swimming in it Scrooge McDuck style, thanks for upgrading!" Now you know how developers spend their hard-earned money. Anyway I'm impressed that Dan didn't just make the number up and actually converted seven bucks US at the current exchange rate.

Scrumy

So I've been playing around with Scrumy lately. From the name I'm sure you've figured out that it's some sort of tool that helps you manage Scrum-based projects. It actually works for any sort of agile-ish project, so you don't have to give up whichever agile cult with which you may already be affiliated.

Scrumy lets you play around for free, although with the free version you'll be in one endless sprint until the end of time. That gets tiresome after a while, so I finally opened up my wallet, blew the dust off my credit card, and parted with a whole $7 (USD) for the privilege of using Scrumy Pro for a whole month. By the way, I'm positive that contrary to what the developers say about the name in their slick intro video, they affectionately refer to their product as "screw me" when we're not listening. But I digress.

My $7 obviously entitles me to deliver my demands to the developers and readily expect to have them fulfilled within two weeks. Anything can be done in two weeks, right? So obviously this budget tool has a few shortcomings, and who better than me to point them out? Ready? Here we go...

Can't see "to do" items in the backlog. There's a backlog (great). You can add stories to it (great). If your story has to do items that greatly enrich your understanding of the story, you're unable to see them when it comes time to assign the story to a particular sprint (utterly maddening).

There's no search. I can't possibly be expected to remember where I put things, that's why I'm spending all this time painstakingly typing stuff into someone else's web app. If there's no search, I can't find stuff without digging through everything and clicking around like mad.

Would be great if edits were pushed out. I'm working on a project with a buddy in Toronto. We often chat about how things are going, and play with the stories and tasks until we agree on the next sprint. It would be fantastically, over-the-top-mega-cool if he could see changes as I was making them. And vice-versa of course, sometimes he has good ideas too.

No obvious way to promote a "to do" to a story. Drag "to do" to story column (nope). Drag "to do" to backlog (nope). Open up "to do" and search for "make story" button (nope). Bang head against screen, open "to do", copy text, select "new story", paste, bang head again.

The Scrumy Scrumy board isn't public. I mean really, how cool would it be to be able to see how the Scrumy guys setup their own project, and what they have coming down the pipe. Read only, of course, except for respected, rational individuals such as myself who should be given full access.

Now don't get me wrong, Scrumy is refreshingly simple and I'm really enjoying working with it. It does just what it sets out to do (replacing sticky notes) admirably well. It doesn't lock you down to particular iteration lengths. It doesn't make you do a bunch of complicated category, project, user setup crap. It embraces the simplicity and flexibility of paper (mostly), while providing the many benefits of taking it online (oh crap, the cat destroyed our project tracking system AGAIN). I wish more products were this fun to use and had such wonderfully ambiguous names.

TDD in Space

I don't know about you, but I find some aspects of test-driven development hard. Too often I'll find myself writing trivial unit tests, typically revolving around persistence or login. I mean, really, should you be spending time writing tests to ensure your application's persistence layer is functioning correctly? That should just be a given!

However, I've been pushing through my initial hurdles, and am really starting to see some solid payback. One of the unexpected benefits is that my API almost immediately becomes more readable. Not convinced? Think about it. In test-driven development, because you're writing the tests in "problem brain-space" instead of "solution brain-space", you're thinking in terms of the problem that needs to be solved, not how you're going to solve it.

While you're in "problem brain-space", you're in the same sort of place that users or maintainers of your code will eventually find themselves in. There are many possible "solution brain-spaces", each with their own set of unique concepts and terms, but typically in the "problem brain-space" you're more likely to be speaking a common language. Which is a good thing.