Startup CTO mistakes I'd rather not repeat

Great post on Startup CTO mistakes I’d rather not repeat…

1. Not getting involved in “the business”
2. Keeping the technology vision in your head
3. Adopting bleeding-edge technology
4. Giving up control of the development process
5. Staying too hands-on and not getting hands-on enough

I actually found it interesting how these were still applicable to my current non-startup role.

The bleeding edge technology one is one I’ve managed to avoid (though my team would argue any open source and anything but java is bleeding edge), but I think more poignant is the one about giving up control of development since it makes it impossible to execute on a technology vision. And yeah, could probably be accused of keeping too much of the tech vision in my head (or not communicating it well enough). Sometimes what seems obvious and transparent when you’ve thought it up is pretty murky to other people (so add communicating it better as well).

Interestingly, I’ve got the opposite problem on the “Getting Involved with the Business” side. I try to get involved with the business outside of pure tech and get rebuffed, at least in my current non-startup role. Yes, this is more political gatekeeping and small-minded empire building/protecting and not at all good for the org. It’s maddening, especially when you’ve got actual expertise in a particular area (like for example, business intelligence or KPIs but can’t get traction because “you’re the technology guy”). The other flip side of this is too many wish list demands rather than things that may actually be needed.

I was thinking about the other mistakes I’ve made in the past as well reading this.

Going with What’s in Place

Quite often, you’ll find that coming into someplace there is already a “solution” in place. Sometimes it’s clear that this solution is not going to scale, meets the needs a few months down the road and generally will be painful. Examine the assumption underlying the selection and if they’re no longer valid or have big holes, well… Kill it. Smother it with a pillow if necessary while it sleeps but get rid of it if you have a better solution that is clear and unambiguous (or even less problematic). If it cost money and the current thing is “free” build up a case to show that it isn’t or how the new thing will solve problems/drive benefits. If you don’t need to do these things, just do it quickly. Out behind the shed. With a shotgun.

Just Good Enough is Good Enough

Perfect is the enemy of better. I’ve gotten a lot better at this one, but the fact is users and the business always want a pony. Follow the idea of 37 Signals’ : Be ruthless about adding new features in if you can avoid it at all. For example, on one of my apps at this very moment I’m ripping out massive stuff we put in since it never gets used and clutters UX and functionality (and we sacrificed actual useful features to build). See next point though.

Not Paying Technical Debt Back Quickly Enough

Technical debt accumulates rapidly. You might think the interest on your credit cards is bad, but the fact is not refactoring and not redesigning when you have to leads to a while lot of problems for later iterations. It goes on long enough and you require a big bang re-write which is always problematic. Trying to re-implment all those features and knowledge of the system all over again is rarely done with perfect fidelity. Work it into your plans. Do it often. Do it early. Even if you’re being lean.

Disclosure: Carl had the terrible misfortune to hire me for the first year I was at my previous company. I still think working with Carl and Core was some of the most fun I’d had had in a long time when I took the job. I still miss our desks back at the old office on Pacific (and the experience is a stark contrast to my current experiences with AI). I fully intend to make the new gig in Aus at least as fun as Van was.).