Fractional or Part-time CTO

July 15th, 2017

Another alternative for a startup might be a fractional or part-time CTO. I’ve previously talked about the spectrum of scenarios surrounding whether you need or don’t need a CTO. Running parallel to that spectrum is the scenario of utilizing the services of a Fractional or Part-time CTO. My previous posts have dealt with the need for a CTO from purely a technical and product perspective. However, another consideration is chemistry.

If you consider that bringing on co-founders is similar to a marriage then you should only want to bring on people that you’ve previously worked with. If you don’t have anyone that you know, then finding a true co-founder is a bit risky.

While not complete, here are some of the advantages and disadvantages of a fractional or part-time CTO:

• As I previously discussed, your startup may not need the full-time services of a CTO. Going the part-time route will save you money on paying full-time for part-time effort.
• If the person doesn’t fit with your organization the “break-up” cost will probably be less.
• You may be able to scale-up or scale-down how much time the fractional CTO spends with your organization based on need.

• Plenty of people believe that you need to have a CTO who is fully engaged, involved and has skin in the game.

In the end, the decision will come down to a combination of factors including need, funding available and your comfort level with the individual person and the role.

While a part-time or fractional CTO may not work for every organization, it is certainly a very viable option for many.

Over the past several posts I’ve talked about the technical roles you might need to fill in your startup along with some of the factors you need to take into consideration, but I’ve only briefly touched on answering the key question of whether you need a CTO.

Let me start by looking at the two easy cases.

You probably don’t need to hire a CTO if you have a very simple app for which you are not planning on adding new features and functionality. In this case you can hire a firm, on a project basis, to develop and roll-out the app.

At the other extreme, you do need to hire a CTO if your application is complex, has cutting edge technology, is an MVP with substantial plans for improvements and enhancements, requires a sophisticated hardware architecture to support it, will require a product evangelist and/or you have substantial investment capital.

That leaves us with the large, and more complex, middle ground. I’ll break this up too since the skill sets you need at the inception of product design and development are most likely going to be different than the skills you will need later on.

I think that when you are creating a product you need someone with an immense amount of technical experience, particularly in creating products and architecting for the future, a visionary, a great project manager and someone who has the credibility to scope and make the tough calls on features and functionality in the initial release – all wrapped up into one. This really means you’re looking for someone who has led product development at a startup before. And, you’re certainly looking for someone who has more experience than a developer. Technical decisions made at this stage of a startup can have tremendous cost and timeline implications, even years into the future. You want to give your concept the best chance of success at the same time you want to conserve what are most likely limited investment funds. You also want someone who can identify and bring on the right people, when they are needed, to fill the technical roles that I previously discussed. Therefore, I think that you need someone with previous experience at a startup to fill the CTO role during product conceptualization, development and rollout.

However, after an initial product has been developed, there are certainly scenarios where you may only need a developer and/or someone to monitor and administer your application and not need the services of a CTO. For example, you launched a great product with a solid infrastructure. Your organization is now into the sales and marketing phase and acquiring customers. Depending on the complexity of your product, you may not need a CTO for a period of time. Minor functionality additions or bug fixes can be handled by a developer. This can save you money, especially if the sales cycle turns out to be longer than expected. At some point you may need the services of a CTO again to handle growth and new functionality, but you may be able to save on this expense for a period of time. Several other options in this scenario are part-time or fractional CTOs that I will discuss in future posts.

To conclude this series of posts, there are multiple considerations to take into account on whether you need a CTO, and multiple technical roles that need to be filled in a tech startup. In some instances it is clear that you will need a CTO to start, others where you don’t need a CTO and then a big gray area where you may or may not, but also may for a time and then not. If you do need a CTO, make sure you look for one with the experience and expertise to get your product to market efficiently and effectively, especially in what is likely to be a resource constrained environment.

In follow-up posts I’ll talk about part-time and fractional CTOs.

The MVP ‘Box’

February 15th, 2017

Wikipedia defines a minimum viable product (MVP) as a product with just enough features to gather validated learning about the product and its continued development (

On the surface, this strategy sounds like a great idea as it avoids building products and functionality that customers do not want and maximizing the amount of information gained and minimize the amount of money spent in gaining that information.

In practice though, defining what functionality is in the MVP is difficult due to the numerous conflicting desires of members the startup team. It is a very delicate situation and, from what I’ve seen, the CTO is usually at the center of the discussions, negotiation, compromise and eventual implementation, essentially defining what the MVP will include and fitting the agreed upon functionality into a ‘box’.

Let’s take a look at some of those potential high-level conflicts:

• Investors – Obviously they want as much functionality in the product as quickly as they can get it.
• Marketers – The marketers have several concerns. Having a product maximizing the features and functionality makes it easier to sell and to a wider audience. They are also rightly concerned about the fact that in many instances you only get one chance with potential customers so if they sell or attempt to sell a product with limited functionality the customers will be disappointed and will not buy or not continue using the product.
• Founder with original concept – The Founder who had the original concept usually has a grand vision of what he/she wants the product to be. There are usually numerous ideas and bells and whistles that the Founder may have been thinking about for years. There is an immense amount of enthusiasm and a desire to get the product finished quickly with all of the functionality.
• Product Users – The users have an expectation of getting their money’s worth for what they purchased and even if they are given a free trial, their time is valuable so they will only use, and continue to us, a product that is of value to them.
• CTO – All of this puts the CTO directly in the middle. The CTO is usually the person who has to come up with time and budget estimates for various pieces of functionality. This means the CTO will be the person responsible for giving the news that no one wants to hear and will ultimately be pressured into promising more functionality, and faster than is possible.

With these competing demands from the various stakeholders, it is imperative that the startup have a CTO who is not just technically strong, but also has the following strengths:

• Ability to listen to the needs and wants of the various stakeholders.
• Ability to estimate costs and timelines accurately so that various alternatives can be compared.
• Ability to look at the product from a business perspective. Ability to develop prioritized features and functionalities that can be used in conjunction with the estimated costs and timelines to put a ‘box’ around the complete list of product functionality. Ability to develop a strawman minimum viable product that can be further discussed.
• Ability to rationally and logically present the strawman MVP and an ability to compromise to change what is included in the MVP, including priorities for follow-on MVP development.
• Ability to effectively communicate that there will be justifiable changes during the course of development and that these changes could have time and budget impacts.
• Ability to effectively and efficiently manage the development of the MVP including the ability to incorporate changes with the least impact possible.

As a CTO, at times, it is very easy to get so involved with the product and the technology and wanting to do ‘cool’ technical things or a desire to make everyone happy that you can sometimes lose sight of what NEEDS to be done so that the organization actually survives. This principally includes keeping the budget and timeline (which usually means limiting the functionality) within business based parameters. Therefore, for many startups, they need a CTO who is not just a technical expert, but someone who has a combination of technical, business and project management experience. It is imperative that your CTO is able to work within the organization to contain functionality to the MVP box and serve as a true business partner and not exclusively a technical expert.