Role of a CTO

I have recently begun reading Werner Vogel's blog.  A post caught my eye -- it is a bit dated, but it asked a question, "The Different CTO Roles"  Werner asserts that a CTO in some combination of external, internal, vision, operational and "translation" expertise.  True.  But let me give you my observations in a technical company such as IBM.
    1.    IBM is a techie heavy company.  So in some ways, the CTO is the head techie.  But this is only approximate because effective CTO's do not even manage the key techies -- the key techies are off in the respective lines of businesses (especially development organizations), in order for them to be most effective.  And recursively so.  So what we get is a parallel organization that burrows deep into large organizations.  Effectiveness comes from influence, not control.
    2.    A CTO is different from a chief architect, but a CTO that cannot hack (or for that matter (god forbid) a chief architect that cannot) should have a short shelf life.
    3.    IBM is a big company.  Consequently a CTO can be fully preoccupied with internal issues, which are quite important.  But the question I ask myself and others in similar roles is -- "how often do we dial an 8 number (IBM's internal line) as opposed to a 9 number (external) line?"  A 50-50 might be desirable, but most of us are nowhere near it.  [And no cheating, because all of IBM's internal calls now us a 1-800 number, which of course starts with 9 from inside IBM :)]
    4.    Vision is important, but most visions are wrong.  It is the adaptability of the execution that is most important.  So a CTO that can operationalize just the right amount is the one that succeeds in IBM.

Comments

[Race Proffitt]

Anant,
I agree that CTOs must have a strategy that supports the business side of the organization; ensuring that technology keeps things running smoothly. Strategy seems to be the easy part though. Long term goals can be formed over a weekend business retreat where colleagues use team-building events to get the creative juices flowing and mission statements are forged. CTOs spend a small percentage of their time with these.

However, I see CTOs spending much of their time lately mitigating risks associated with the organization. Employees browsing the Internet, searching for who knows what, or even downloading possible infected files into the bounds of the corporate firewall. These are the things that keep these executives up at night.

All the hard work of implementing a secure network could be violated after an employee downloads a file off of craigslist. The next 48-72 hours could be spent with the SWAT team watching them restore email, content, databases, file servers, etc. The strategy is out the window at this point and it’s time to get the business back on its feet.

Strategy is good; don’t get me wrong. But they have a lot more to work on than just looking ahead. They need to watch out for those Mack trucks coming from the sides.

[Carl Kessler]

Anant, You hit on a really important notion. What are, after all, the roles of a CTO? One would be to look outside the box of current approach to understand both what others are doing and - importantly - what might be done differently - to help clients achieve their goals.

Yet just reading information is not sufficient. A good CTO can share insights as well about the practical application of new approaches, the ways in which they might be used, and their relevance to existing clients using existing products.

That means the CTO has to be able to mess around with the technology - hack it. She or he does not need to build a product, but needs to gain a gut feel about how things work to guide their intuition.

In my experience, CTO's who can engage with technical teams around their real experience hacking around gain enormous respect and their impact is amplified.

All this goes, with appropriate modulation of the "look far and wide" notions, equally to "chief architects."

Sometimes chief architects and CTOs see themselves as no longer coding, but rather thinking big thoughts all the time. Big mistake.

Beautiful code, by the way, is difficult to write, requires a mix of programming, computer science skill, and real life experience to do extraordinarily well. Folks who write beautiful code are woefully under-appreciated in many parts of our industry. Especially if they see their career path is to become a chief architect - when that title is associated with stopping this important part of the job content.

[Ganesh]

Anant,

Influential power is preferred for a CTO, architect or for that matter any leader up and down the management chain – first line to VP. Hacking does provide ammunition for this influential power – up and down the management chain. Sadly, very often a technical person who rises up the management stops hacking. How many directors and VPs in a big company have even tried installing their own line of products?

Beyond hacking, in a technological company, I believe it is important for such leaders to be able to articulate the direction/vision and elucidate why it makes sense for others to follow that vision – how does it benefit the company, its clients, how it ties into existing and new products.

Besides clients, this “vision/strategy/approach” needs to be explained in an adaptable fashion for employees within the company. Lots of times, we do not tie this vision/strategy to current set of product line or new ones in the pipeline. The leaders talk about the “big thoughts” as Carl calls it and leave it up to folks in the “trenches” to figure out what it means.

Ganesh

[Anant Jhingran]

Race, Carl, Ganesh, agreed. We all strive to be better (at least most of us do), therefore learning from your comments, and practicing them is the thing that I will continue to do.
Carl: BTW, when am I getting to see your blog my friend?

[Carl Kessler]

Anant, so glad you asked... Take a look at http://outside-in-development.blogspot.com/
- and be kind to me; I'm a newbie at this!

Carl