Insanity Is What Divides CIOs And CTOs

I got this lesson from a customer:

The difference between a CIO and a CTO is a certain level of insanity. A CIO would never take a working infrastructure, turn it inside out, and redesign it. But a CTO will.

Another customer I talked with – a CTO – described his job this way:

There are five stages to technology adoption: monitor, evaluate, standardize, proliferate, and retire. I’m responsible for all but the fourth. It’s not my job to proliferate technology through our infrastructure, but it is my job to figure out when to proliferate, exactly what to proliferate, and – eventually – when to stop proliferating.

I asked for details about these different stages. He described monitor as a casual awareness of a technology, maybe from reading occasional articles or white papers, and keeping an eye on it to determine when to investigate more deeply. Evaluate is when you seriously consider whether a technology is valuable enough and mature enough for you to deploy. To make a technology manageable in a large enterprise environment, you standardize on a particular set of configurations and management processes. At that point, you can proliferate the technology broadly, until a replacement technology is ready, at which point you retire this one.

I’ve noticed that the CTO title is used very differently, depending on the company.

In tech startups, the CTO is a smart development engineer, often a founder, who has the technology vision for the company’s product. These technology-CTOs are deeply involved in technical details – the bits, bytes, atoms and electrons of the new technology.

In very large corporations, the CTO is often a person who reports to the CIO, and whose job is to define the technology vision for the company’s IT infrastructure. These IT-CTOs generally care more about the big picture – how all the different technologies fit together to solve a business problem – than they do about the bits and bytes.

Companies that sell enterprise IT products often have one or more CTOs who work closely with customers. These customer-facing-CTOs work especially closely with IT-CTOs, so they tend to think more about the big picture than about the bits and bytes.

Using the same title for different jobs can cause confusion. Sometimes when a customer asks to “talk with your CTO”, they want the nitty-gritty details about product technology, in which case the technology-CTO is the right person. But sometimes they want advice on enterprise data center issues – on large-scale deployments and optimal procedures and best practices – in which case a technology-CTO may be a bad fit, and a customer-facing-CTO would be better.

My opening quote was about CTOs who report to CIOs, but I recommend against asking for “the insane one” to distinguish between the different types.

Comments

[Shibin Zhang]

This is a fun web-site. I discovered it and had some comments in:

http://blogs.netapp.com/dave/2007/10/is-nfs-a-form-o.html#comments

Since then I took a break because of the holiday. When I come back, I found more interesting contents.

I basically agree with David, except for two things:

1. If CTO ‘s job is technology adoption, then who is responsible for creating new technologies?
2. If CTO is not the biggest engineer, who is? More specifically, who is the CIO (David’s definition) of Netapp?

Shibin

--------------------------------------------------------------
Shibin,

Your question makes me realize that I explained myself poorly. A large tech company may have all three types of CTOs:

(1) The CTO in engineering who is the “biggest engineer” who “is responsible for creating new technologies.”

(2) The CTO reporting to the CIO whose job is to define the vision of the IT architecture.

(3) The CTO associated with sales whose job is to work with IT-CTOs (type 2) at customers.

That’s where things get confusing, because if you ask to speak to “the CTO”, you need to make sure you get the right one. If you want to talk about the technical details of a company’s products, you should talk to the CTO in engineering (type 1). If you are a salesman and want to sell IT equipment to a company, you probably want to talk to the CTO who reports to the CIO (type 2). And if you work in IT and are considering purchasing products from a tech company, and want to understand how they can help you address your business issues, you probably want to talk with the CTO who is associated with sales (type 3).

I have to say, there isn’t much consistency in these titles. One company might use "CTO" for all three roles, while another company might use a title like "Chief Scientist" (as an alternate title for type 1) or "IT Infrastructure Architect" (alternate for type 2).

So when you are trying to hunt down the right person, the trick is to focus on the role -- on the type of work the person does and where they report -- rather than just using the CTO title.

The CIO title, on the other hand, almost always refers to the person who runs all of IT. Not much ambiguity there.

-- Dave

[Bruce Leverett]

Interesting. I never knew about the three types of CTO's -- only the "technology-CTO". Reading this blog entry no doubt saved me from some embarrassing gaffes :-)

[HANSU]

Dear Mr. Dave

This is HANS

I am a university student studying Enterprise Management in KOREA.

I and two more my friends are on a study for improving Korea's Human Resource Management.

We have seen and gotten lots of stories about your company and its revolutionary HRM system from Fortune and many more. It was so impressed to us as one of the students who studying Enterprise Management.

We have been researching 'What factors make best place to work for' and 'How to set this up '. And we recognized that we need to experience real field to get highly acceptable results for this and apply Google 's revolutionary HRM system to Korean companies in Korean' s way.

So, we really love to visit and meet person who works in HR department.

The meeting might take just for a minute.

So we sincerely hope that you can help us.

My e-mail address is "hansu1111@gmail.com"

Your Sincerely

[Chuck]

Hmmm, That deja-vu feeling like I've had this conversation before ;-)

After talking with you about this topic and reflecting some more on it I believe there is an entirely overlooked discipline in modern business which is "technology management." The technology and processes that are the arteries and synapses between the people which keeps an organization functioning has a very very real effect on the productivity of the organization. And while there are many, many books on spotting the people who are the stars and the underperformers in your organization why isn't there one that does the same for technology?

--Chuck

[Armen Hovanessian]

Hello Dave,
As usual very interesting and insightful blog! I am ex-cisco (Quality Systems) manager, I was there 95-06 ... In my early Cisco years, we had a "Real" Type 1 CTO - Ed Kozel, very knowledgeable and technology advisor to the CEO. Then we had a Chief Strategy Officer -- more for technology acquisition. Later years we just had a CIO, Type 2, kind of internal IT implementation person, often interfacing with Customers regarding how we implemented our own technology inside Cisco.

General comment: Thanks a lot for your suggestions on books - esp. Darwin's Dangerous idea by Dan Dennett, for me reading it was rather "life-changing" experience. (I often wonder, why it was in your list - as it has nothing to do with technology ... maybe not)

Also, I interview for few jobs in NTAP (talked with about 20 people!) not very many were aware or knew a lot about your blog
:(

[Dave replies: Ed Kozel is on our board of directors, and he is one smart dude. He talks quietly, and not that often, but I've learned that it is worth listening very closely when he does.]