Sam Aparicio

The job of a CTO is to translate R&D dollars into long-term sustainable competitive advantage for their organizations. It’s not to code, to evangelize, to make technical decisions or to attract top technical talent, although it may involve all of that. Those are inputs. The output, though, is innovation that creates differentiation. If you can do this, you will be richly rewarded and have a long tenure. If you can’t, you will get relegated.

Here is an excerpt of an interview with Nathan Myhrvold, CTO at Microsoft:

BROCKMAN: What’s a CTO?

MYHRVOLD: Hell if I know. You know, when Bill and I were discussing my taking this job, at one point he said, Okay, what are the great examples of successful CTO’s. After about five minutes we decided that, well, there must be some, but we didn’t have on the tip of our tongues exactly who was a great CTO, because many of the people who actually were great CTO’s didn’t have that title, and at least some of the people who have that title arguably aren’t great at it.

My job at Microsoft is to worry about technology in the future. If you want to have a great future you have to start thinking about it in the present, because when the future’s here you won’t have the time.

Convention

There are some interesting stereotypes about CTOs: the founder who could code, a sales engineer with gravitas, the mad scientist, the evangelist. Although you’ve surely encountered some CTO who fits that description — and it’s quite the case that many CTOs don’t know how to manage people, these stereotypes are just that, caricatures of reality.

A great CTO can do these things, but above them he/she can see the future and how technology can shape it, then gets to work turning those ideas into a product or service reality and explaining to its audiences how life is about to change.

He persists through all difficulties to see the company’s vision go out the door embedded in those products and harnesses the R&D resources to execute.

An example of a great CTO

One of the people I look up to is Steve Trundle. Steve was the original CTO of Microstrategy, from ‘92 to ‘01. Steve then went on to become the CEO of Alarm.com, where he is doing an outstanding job of growing the business. While at Microstrategy, Steve managed some of the most significant milestones for the business. Within the organization, he is widely credited with being a leader of technical people, and for setting the foundation for Microstrategy’s multi-decade technical dominance of the Business Intelligence industry. He didn’t do it by coding, or by doing great demos, but by aligning people with goals and removing obstacles for them to solve long term challenges. In other words, plain old execution. The fact that he so successfully transitioned to a CEO role is an indicator of how he understood the importance of creating value.

Cream of the crop posts on the job of CTOs:

• Eric Ries proposes 5 key contributions of CTOs: 1) platform selection and technical design, 2) macro and micro picture at the same time, 3) generating options, 4) finding the 80% of user value that can be built for 20% of the cost and 5) growing technical leaders
• Ben Brinckerhoff has some draft notes and he draws good distinctions between a CTO, a VP of Engineering and a Chief Architect.
• Tom Berray proposes  4 stereotypical roles for CTOs in a well written white paper.
  

  The 4 stereotypes of CTO at large organizations

• The CTO to CEO transition stresses the central tenet of this post, that a CTO needs to focus on applying technology to the generation of revenue.

CTOs are not…

• CIOs. CTOs produce technology, CIOs consume technology. CIOs make the company productive and keep its data safe. More on CTOs vs CIOs.
• VPs of Engineering. VPoEs focus less on strategy and more on execution. “They are process / management gods (and goddesses) – totally focused on building and shipping products.  Most of them are “medium technical” – strong enough to stand up to the engineers they manage, but not necessarily the best coders on the team.” says Brad Feld

If you are a CIO and you want to stay relevant 5 years from now, your #1 job is to make every employee at your company more productive.

Yes, you have to deal with compliance, and security, and IT projects and budgets and infrastructure maintenance and cost control. But in comparison, none of those tasks can have the strategic impact and scale of achieving small incremental gains in empowering your company’s employees with technology.

By choosing to ignore (or in some cases directly hurt) this responsibility CIOs relinquish their seat at the table with the top executives at a company. Of equal value to sales, finance and operations is a function that maximizes the return on human capital, and these days it’s not really HR’s job to accomplish this. (On a personal note, I feel HR, as traditionally conceived in most organizations, is a bankrupt paradigm). It’s the CIO’s.

Some things you want to stop doing:

• Preventing employees from installing software on their computers
• Preventing employees from bringing their own laptops to work
• Blocking access to sites such as Facebook, Twitter, meebo.
• Saving money on monitors

Some things you want to start doing:

• Find the line managers trying to innovate within your organization (maybe they have Macs on their desks or are running wikis under them)
• Implement grassroots systems: IRC, Forums, wikis, IM
• Implement personal productivity tools: GTD software, email search, mindmapping software
• Help teams get organized: Basecamp
• Provide the means for semi-structured information to flourish: wikis.

The days of the centralized large IT organization delivering centralized large IT projects are counted. As viable SAAS alternatives emerge and a younger, tech-savvy, self-sufficient employees make it through the ranks, they will demand the freedom to innovate their own way, they will provide their own tech support, and will want to run their own systems.

Like Ross mentions in a recent CIO magazine article on the role of wikis

Most employees don’t spend their time executing business process. That’s a myth. They spend most of their time handling exceptions to business process.

The logical conclusion to that is that most business value is derived from empowering those employees to handle those exceptions and capturing and disseminating the knowledge generated by solving them.
And it’s real hard to do that without the right technical tools.