The art of building software: The Chief Technology Officer of a Software Startup

Monday, November 29, 2010

The Chief Technology Officer of a Software Startup

During early phases of a software startup, you don’t want to be management top‐heavy, yet it’s important to bring on senior people for continuity as you scale the organization up because these people can and should set the culture for the company going forward.  Once set, cultures are harder to change.  At the beginning, you need “player / coaches”; that is, people who can be an individual contributor, manager, and leader. The CTO in such a company should initially multirole as needed the roles of chief architect, lead programmer, and VP of Engineering, eventually replacing these with full time positions at the right time.


It’s important for the CTO to select the right technology platforms and tools early on in a startup, as well as play a key role in hiring the team and setting up the team culture, development infrastructure and development processes that can scale.  To be successful in doing that, the CTO absolutely must be a visionary technologist and quality coder with the ability to learn new technologies as needed.


A common view of the CTO role is that they do not need to have strong technical skills.  John Wren Medcof shows this well in this picture on the right from his web site.  I disagree with this model, and think that a CTO needs to excel in all these domains.


While the CTO is responsible for the technology, the continuous product and project management decisions of how to balance milestones, resources, and features as development progresses must be a cross functional team decision. No one person has all the knowledge to do this. In larger organizations, you form a cross‐functional product team to balance the three factors (time / features / resources). However, in early startup stages, the executive team may need to actively multirole this until sufficient staff is in place to offload this burden. I use the word “burden” because it takes some investment of time in order to make the best call to balance these factors. 

If the executive team is also playing the role of the cross‐functional product team, the executive team meeting should be kept completely separate from the cross‐functional team meeting. The two meetings often have different people leading them as well. Usually a CTO or product manager leads the product team, but that doesn’t have to be the case.



The CTO should know when it’s time to hire people, and what kind of skill sets are needed. When the size of the engineering team hits a certain point – perhaps around 5 people and still growing, another layer of management may be introduced – this typically reports into the CTO but this is not required. The next manager brought in should either be at the Director or VP level, and that person may need to be a player / coach until the team grows to a size where the manager can’t simultaneously write code and manage.  As the team grows larger, additional layers of management should be brought in.  There are "phase changes" of sorts that an engineering organization (and the company as a whole) goes through when the total size hits certain ranges.  A CTO should be prepared to  help the company through these transitions.

So to summarize, the CTO may well start off as a strong individual contributor, but that function should gradually be reduced as the team grows in size. With that said, in order to maintain his or her edge and to retain “street credibility”, I believe a CTO must continue to develop and write code, as well as facilitate the architecture, and mentor others on the engineering team.


Most of the CxO’s on the executive team must play both an internal‐facing leadership role, and an external‐facing role facilitating investment and sales. The CTO is no exception. Initially as the company is getting going, probably more emphasis should be placed on the internal role. As the company grows, the CTO should transition to a having a larger external impact, through multiple channels. The CTO is often brought along as a “big gun” for important sales, in order to talk tech with the customer’s tech people. The CTO is usually part of the investor pitch team as well, as investors need to know that the company has what it takes to deliver the goods. In addition, the CTO should develop an external reputation for technical excellence and thought leadership, in the industry and his CTO peers in other industries. This is accomplished through several mechanisms such as blogging, articles and press releases, and talking at industry events.


I’ll close by saying that a major challenge of being a top CTO, is maintaining that technical edge that allows you to be a “player” in the player / coach model, yet spend enough time on the external facing role and continue being a thought leader. You can’t do this by just coding a few hours every couple of weeks. You need to sink your teeth into some problems.

No comments:

Post a Comment