CTO: A Dangerous Title

The chief technology officer (CTO) job title has been floating around the IT industry for at least a decade now, so it’s had enough time to settle in. And the places that it’s settled are rather unsettling.

The title originated in technology vendors where the CTO was responsible for product research and development. It was quite popular in the dotcom companies of the 1990s, and from there spread to internal IT departments. And that’s where the trouble began.

Of course, the exact meaning of the title is as diverse as the organizations that use it. But the four most common definitions all violate fundamental organizational principles and are unhealthy for the broader IT function.

IT’s Chief Operating Officer

In some IT departments, the CTO runs the whole show. Virtually the entire IT staff report through the CTO (except perhaps for some support functions like the IT business office and the chief security officer). I’ve seen a number of IT shared services organizations where the CIO had only two direct reports: the CTO, and the head of the IT finance and planning group.

This manifestation generally indicates a CIO who’s turned over his or her job to a subordinate. Perhaps the CIO is busy with corporate politics, with public relations (aka “golf”), or with meddling in (sorry, I should be diplomatic and say “coordinating”) business-unit IT decisions via policies, IT staff career plans and “strategies.” Or perhaps he or she is just retired on the job.

Whatever the CIO is doing, he is not delivering much value to the business. The CTO is.

A typical and proper span of control for a C-level executive is eight to 12 direct reports (presuming a capable leadership team at the next level). A span of two or three raises the question, do we need the CIO at all?

Even if the CIO’s job is reasonably secure, her ability to contribute to strategic issues is diminished when people realize that she is effete. If you want to get something done in this company, you’ll quickly figure out that you have to go to the CTO, not the CIO.

If the CTO title means running the entire IT shared-services organization, then a chief technology officer obviates the need for a CIO. Why not combine the two jobs and stick with the CIO title?

Engineering Czar

Another use of the CTO title is to describe a technology “czar” who makes all technology decisions for the entire IT organization. In these organizations, the CTO manages all the IT engineers—generally, although not always, including applications engineers as well as desktop platforms, end-user computing and infrastructure engineers.

To make a case for such a concentration of power, people cite the need for an integrated vision of future technologies, one that overcomes an existing mess of fragmented systems.

So let’s say you’re the IT operations executive in this organization. Your job is delivering infrastructure-based services reliably and efficiently. But you have no say over what goes on your raised floor. The CTO decides for you. How would you feel?

Disempowered, to be sure. You probably realize that you’re set up to fail. Look at the incentives built into the organization.

Engineers love innovation and are rewarded for their technology designs, but they aren’t held accountable for cost-effective, stable operations. In pursuit of the “right” technologies, you’ll be given the latest and greatest… at any cost. And when the engineers in the CTO group decide to try out some bleeding-edge product, you’ll take the fall when it proves unreliable.

This structure is like allowing Hewlett-Packard to decide what computing platforms are used at America Online. How can we hold IT operations accountable for the performance of the infrastructure when they have no say over what that infrastructure looks like!?

The answer is, we can’t. Authority must match accountability, in every part of the organization, all the time. This is the “golden rule” of organizational design.

When the CTO title is interpreted as a technology czar, the operations group becomes a passive dumping ground and cannot deliver or be held accountable for the cost or quality of its services. This is absolutely counter to my vision of a healthy organization where everybody is an internal entrepreneur empowered to run a business within the business.

The Lone Genius

OK, so maybe your CTO isn’t a czar. Another form this role takes is the “genius” reporting to the CIO who is annointed with responsibility for the future of technology throughout the IT organization.

This interpretation gives the CTO three roles: The CTO tracks emerging technologies and plans technology directions for the entire IT department; the CTO coordinates all the various IT engineers (who may report to others) to ensure integration; and the CTO takes on the really tough new-technology projects like major infrastructure revamps.

Let me restate those three roles with brutal honesty:

First, one person (or small group) is so much smarter than everybody else that he can do the technology research in every branch of IT better than all those who have dedicated their careers to a specialty within IT. To me, this is utter arrogance.

This structure is symptomatic of an organization that can’t figure out how to set aside a portion of everybody’s time for learning and innovation, and instead partitions off an entire group that does everybody’s thinking for them. The rest of the staff are denied the exciting part of their jobs—researching new technologies—and are disempowered as entrepreneurs since they cannot plan their future product lines.

Second, the CTO tells everybody else how to design their systems in the name of integration. I guess this role must be needed because the rest of the staff refuses to team with one another on projects, or to collaborate on standards decisions and a vision of future systems.

Again, it’s using a CTO to make up for a fundamental fault in the rest of the IT organization—the lack of teamwork.

And third, whenever the going gets tough (or really interesting), the CTO takes the project away from the rest of the staff. Everybody else is denied those career-growth opportunities. As a result, they aren’t given the chance to gain experiences that will help them with their more mundane everyday work. And, of course, this is highly demotivational.

This, too, is using a group to make up for an organizational breakdown: The organization doesn’t give all staff the support they need (such as project management support or time for professional development) to take on stretch assignments.

When you use a CTO to make up for deficiencies in the rest of the organization—time to think, teamwork and project-management or new-technology competencies—the consequences are dire. On one hand, you create a bottleneck for innovation within the CTO group. On the other hand, you deny the rest of the staff the learning opportunities they need to do their jobs and the career-growth opportunities they need to remain motivated and loyal.

Head of Infrastructure

A fourth incarnation of the CTO title is somewhat more benign, but still far from ideal. It assigns the CTO title to the head of both infrastructure engineering and operations. This doesn’t disempower peers in the way that the first three definitions do. But it’s still a poor structural design. Essentially, it puts Hewlett-Packard and AOL under the same boss.

So what are the incentives in this structure? The CTO must keep the infrastructure running smoothly. And the CTO is expected to be the source of innovation. Keep things stable. Shake things up.

This fundamental conflict of interests is unhealthy for those involved, and causes a lot of job-related stress. Furthermore, it inevitably induces a bias one way or the other (depending on the bent of the CTO). Most often, firefighting swamps innovation, and the pace of technology innovation slows as the entire infrastructure organization is focused on keeping things running reliably and keeping costs down.

It also creates problems with teamwork. Note that infrastructure engineers serve infrastructure operators, but they also join applications engineers on project teams and sometimes they deliver products directly to clients. When the engineers report to the same boss as the infrastructure operators, their tendency is to neglect these other customers.

Infrastructure engineering and operations are best positioned as peers, just as Hewlett-Packard and AOL are peers in the real world. Their relationship is best described as customer-supplier, not boss-subordinate. Engineers continually put innovative proposals on the table. Operators decide whether or not they’ll buy new technologies based on the needs of the market and their ability to operate them reliably and cost-effectively. This balance of power leads to the ideal balance of innovation and operations.

All Chiefs?

In a healthy organization, every group is fully empowered to run its line of business, be that an applications or infrastructure engineering business, or an infrastructure-based service bureau (computer and network operations). Nobody does the thinking or decision making for any business but their own.

Furthermore, in a healthy organization, lines of business are not combined in such a way as to create conflicts of interests—like combining engineering and operations.

Perhaps the CTO title could be given to the head of one line of business, such as infrastructure engineering. But wouldn’t that imply that one of the CIO’s direct reports has a status greater than her peers? To be fair, all the tier-one leaders should then be called “chief something-or-other.”

Of course, when you do that, the title loses meaning (like vice presidents in a bank). And IT might look a little silly when the leaders of this support function carry titles more gradiose than the managers of line functions like manufacturing and sales.

Personally, I’d leave this fad title behind, and instead focus on titles that clearly describe the line of business within each tier-one group.

You can read a version of this article on the author’s website, with links to other columns, relevant white papers, books and other resources.