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
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
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?
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
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
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
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
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
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
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.
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
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.