The role of a CTO is a topic that inspires many to ask so many questions. What is the difference between a CTO and a VP of Engineering? What to look for in a startup CTO? There are literally hundreds of posts on the topic and deep comments threads explaining various experiences in various scenarios. I think that is exactly the take away; the specific scenario matters. The specifics being important and not unique to the CTO role. A good sales leader in one business doesn’t necessarily work in all the other businesses.
My experience as a CTO has been in the area of building native cloud based, highly scalable platforms from the ground up. The platforms have been built to process massive amounts of data, high transaction volumes and large numbers of concurrent users or device interactions. When I say from the ground up, I mean that I run around with powerpoint slides and wireframes describing the business before a line of code is written. The first goal is alway to sanity check the business idea. The idea always changes, often in big ways (aka. the infamous “pivot”) – so it most likely is a total waste of time and money to write code to aid in describing the business value. I’ve raised at least $20M with PPT and zero code. Yet, I’m literally contacted two times a week by folks that want help or advice in writing prototype code so they can raise money. What? You might be talking with the wrong folks if they need a prototype or maybe you are not explaining your idea clearly.
Unfortunately, I don’t get to write code these days. I’ve read all the comments about if the CTO doesn’t write code then go get someone else. That advice is total baloney. What is much more likely to be true is that an architect or lead developer is needed for that particular business and you should not being describing the role as CTO.
So what do I do as a CTO? Thinking back over the past companies that I’ve been a CTO, I spend a lot of time translating business ideas to a platform concept or dear I say, vision. I also spend time researching available technology to support the future platform architecture – I refuse to build things that already exist, I want to concentrate on building the new, non-existent stuff as quickly as possible. I also spend time reverse translating platform capabilities to business use cases – in other words, how does the technology support solving the important business problem – in the end, that is the entire point.
I’m deeply involved in contract negotiations, especially in relationships that involve critical technology partners. There are many important aspects of technology partnerships that will make or break the value of your platform as an asset and in turn, maybe even your entire business model. For example, data rights and protection of intellectual property are critical. Similarly, I spend a lot of time in helping sales and business development understand customer use cases and mapping it to our platform, or in identifying creative ways to fill gaps or in recognizing a general pattern that needs to be built into our platform.
I’ve been part of businesses that have raised hundreds of millions of dollars and have sold several of these businesses. I spend a lot of time in the due diligence process – explaining our platform inside and out, describing our discipline and investments, forecasting future ideas and in general supporting the idea that we have a technology asset that is truly worth something and supports our business idea.
I’m responsible for recognizing intellectual property and doing something about it. Notice that I’m not just leaving it as, filing a patent. That is because filing a patent is just one small thing that you do to protect your IP; quite honestly, probably not the most important. I believe that if you have something that is true IP, that you need to get it to market quickly and run with it as fast as possible because that is what makes it really defendable and it often is the key business differentiator that every business wants to include in their pitch.
I spend a good amount of time identifying and understanding emerging technology and trends. I look for opportunities to use or integrate in support of solving problems or filling gaps; I’m also interested in potential threats or disruptors.
Finally, just beyond the first couple of weeks and months, there is a ton of team work investments and operational stuff that I need to make and this grows with the size of the business. Having bought and sold a few business, I understand how companies evaluate a technology based business and what value is assigned upon acquisition but also how companies forecast future investment requirements. In other words, buying a great technology idea running in my basement with no documentation run by cowboys is far less valuable than a well documented platform, running in a fault tolerant architecture cared for by a top-notch team of professionals with verifiable workflows. Building that isn’t free, but well worth paying those investment taxes along the way.
See no code, sadly for me – but then, I’m not the lead developer or architect or even the engineering manager.