The Great C's - CTO

My last post was about my view of a great Chief Revenue Officer (CRO). This time my focus is on the Chief Technology Officer (CTO). Once again, I have to say I have worked with a few really great ones, and a few not so great. My entire career has been in the tech world, so when I think about the CTO position, it is through the lens of businesses that were dependent upon tech as their primary product. The role of CTO in a company that does not sell its tech is quite different, and not what is described in this post.

Tech founders are often the original inventors of their products. Many early stage entrepreneur CEOs have a technology background, but as their companies grow, most of them quickly realize that their skills are not suited to the CEO position, so they seek to hire or partner with a CEO who is more business operations minded. Although my educational background was far removed from computer sciences and engineering, in my career, I grew up in the engineering and product management world before making the leap to the CEO position. In the stone ages, I learned to write code, but all of those skills atrophied long before I moved into management. What I retained was an appreciation for the challenges of building technology, an ability to almost understand what engineers told me, and after leading a number of engineering teams and product launches, I developed a pretty good B.S. meter that enabled me to read between the lines of what engineers and technical teams were saying. All of that background colors my definition of a great CTO, and may differ from how others view the role.

Leading a bunch of engineers is hard. In my experience, the stereotype of engineers being anti-social and uncommunicative hermits is completely false. The engineers on the great teams I have worked with were highly competitive with each other, and very social with their teammates. They routinely challenged each other’s technical skills to see who could write the most efficient or elegant code, or solve hard problems with the fewest steps. They would hangout together and eat together. They shared fanatical interests, and once you found some common ground they would light up and become incredibly interesting to speak with. I was once out for drinks with a team of engineers who built products to thwart hackers. In other words they were just like hackers, but they were the good guys. Engineer #1 bet Engineer #2 that within 24 hours he could penetrate Engineer #2’s personal computer at his home and leave a specific message in a specific folder. The trash-talk was like listening to two athletes challenging each other on the field. For a CTO to succeed in this type of alpha environment, the baseline requirement is to be a standout technologist. That seems pretty obvious, but I chose the term ‘standout’ for a reason. Game respects Game. For a CTO to get the best out of a team, they have to standout and be able to inspire and demand great engineering. They must have the technical skills and knowledge to earn the team’s respect, and the leadership skills to motivate the team to deliver great products.

Engineering teams often see the world as ‘us’ against ‘them.' All of ‘those people’ in sales and marketing and admin are ‘them.’ The engineering team wants a leader who understands their needs and can bridge the gap between ‘us’ and ‘them.’ That means the CTO has to be adept at providing context to translate market and customer needs to engineers, and the skills to explain technical challenges to non-engineers. A great CTO can synthesizes mundane business requirements into projects that maintain engineering enthusiasm and curiosity. Bored engineers create boring and often flawed results, and if they are talented, they do not stick around for long in boring roles. A great CTO figures out how to retain and motivate great engineers while delivering the mundane business requirements.

Curiosity is an important trait for a great CTO. They are always learning and exploring new technologies and dreaming about how to reinvent or expand the product offering. As a CEO, I relied upon the CTO to introduce me to the possible and urge me to take bold steps with our products. The key attribute for me was that the CTO had to be grounded with a deep appreciation for our business, our markets, and our customers. Cool new tech was not enough. It had to be presented in a manner that tied to benefits for our customers and our business, and it had to be achievable within the realities of our financial capacity. That meant that a great CTO had to also be a great business person. One of the best I worked with recognized this need and at some point in their career went back for a Masters in Business Administration.

In a high-performing business, the executive team operates like a fine tuned machine where all of the gears mesh and turn together. A great CTO is a member of that team, and a leader for the entire business. Engineering projects have schedules and commitments. Nobody likes to be derailed from their plan, but in the software world, bugs pop up, customers demand attention, and prospects announce that they will buy “if only the product can do this one new thing.” A great CTO looks for ways to help drive the business in the short-term, but they are also the stewards of balancing ‘the tyranny of the urgent’ with the longer-term good of the company. Delivering products on time and within budget is a hallmark of a well run tech group. The company depends upon predictable delivery of product updates and new capabilities, and expects them to be of the highest quality. Creating an efficient team that addresses the immediate urgent matters and sticks to the plans for scheduled projects requires a constant juggling act that great CTOs do well. Not so great CTOs alienate their executive peers by being insensitive to real-time business needs in favor of solving long-term projects, or consistently failing to deliver as promised.

A great CTO is an excellent public speaker and able to translate technical brilliance into great understandable presentations. Prospects and customers love to meet and hear from the CTO, and a great CTO will be in high demand by the sales team. They are also called upon to present to the board of directors and potential investors, and they have to instill confidence in each audience. They must be able to support and defend technical decisions on the basis of business and financial implications as well as technical rational. 

In the businesses I led, the CTO was truly the chief technologist. We generally did not have a Chief Information Officer (CIO), so the CTO oversaw our business technology infrastructure in addition to our product line. To do that well, the CTO had to become aware and immersed in how the company operated. They needed to have a pragmatic view of infrastructure and tools. Great CTOs introduced productivity tools to the entire company, guided the company through security certifications, and ensured optimal licensing for enterprise platforms, while basically making sure the business operated smoothly on our computing platforms. 

One area of controversy is whether the CTO should be responsible for product management or not. I have been on both sides of this argument. In general, I consider product management to be a strategic function, potentially as an executive role reporting to the CEO. I believe a great product manager is a CEO in training. However, more typically, it is considered a strategic marketing function that may report to the Chief Marketing Officer (CMO). or it is defined to be strictly a product function that will report to the CTO. The really great CTOs I have worked with have earned the right to be responsible for strategic product management. They have embraced the business vision and internalized all aspects of the business so that they are able to define, build, and launch the products that will be the lifeblood of the business. There are no excuses and no places to hide if you own all aspects of the product, and great CTOs rise to the occasion. Not so great CTOs bring their ego to the table and too often build what they want or what they think the market wants without a lot of real insight, and their products typically miss the mark. Where to place product management is a tricky decision for a CEO and not to be taken lightly. Just because a CTO candidate asks for product responsibility does not mean it should be given.

Bottom line, great CTOs build great products and lead vibrant technical organizations. As only a quasi-technical CEO, I relied heavily upon my CTOs. The great ones stood out and were a key to driving business success. Finding the right mix of capabilities to complement the CEO and the entire executive team is a challenge, but fundamentally worth the effort.