The four most common definitions for the CTO title are unhealthy for the broader IT function.
The chief technology officer (CTO) job title has been floating aroundthe IT industry for at least a decade now, so it’s had enough time tosettle in. And the places that it’s settled are rather unsettling.
The title originated in technology vendors where the CTO was responsiblefor product research and development. It was quite popular in thedotcom companies of the 1990s, and from there spread to internal ITdepartments. And that’s where the trouble began.
Of course, the exact meaning of the title is as diverse as theorganizations that use it. But the four most common definitions allviolate fundamental organizational principles and are unhealthy for thebroader IT function.
IT’s Chief Operating Officer
In some IT departments, the CTO runs the whole show. Virtually theentire IT staff report through the CTO (except perhaps for some supportfunctions like the IT business office and the chief security officer).I’ve seen a number of IT shared services organizations where the CIO hadonly two direct reports: the CTO, and the head of the IT finance andplanning group.
This manifestation generally indicates a CIO who’s turned over his or herjob to a subordinate. Perhaps the CIO is busy with corporate politics,with public relations (aka “golf”), or with meddling in (sorry, I shouldbe diplomatic and say “coordinating”) business-unit IT decisions viapolicies, IT staff career plans and “strategies.” Or perhaps he or she isjust retired on the job.
Whatever the CIO is doing, he is not delivering much value to thebusiness. The CTO is.
A typical and proper span of control for a C-level executive is eight to12 direct reports (presuming a capable leadership team at the nextlevel). A span of two or three raises the question, do we need the CIO atall?
Even if the CIO’s job is reasonably secure, her ability tocontribute to strategic issues is diminished when people realize thatshe 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-servicesorganization, then a chief technology officer obviates the need for aCIO. 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” whomakes all technology decisions for the entire IT organization. In theseorganizations, the CTO manages all the IT engineers—generally,although not always, including applications engineers as well as desktopplatforms, end-user computing and infrastructure engineers.
To make a case for such a concentration of power, people cite the needfor an integrated vision of future technologies, one that overcomes anexisting 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 andefficiently. 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 tofail. 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 andgreatest… at any cost. And when the engineers in the CTO group decideto try out some bleeding-edge product, you’ll take the fall when itproves unreliable.
This structure is like allowing Hewlett-Packard to decide what computingplatforms are used at America Online. How can we hold IT operationsaccountable for the performance of the infrastructure when they have nosay over what that infrastructure looks like!?
The answer is, we can’t. Authority must match accountability, in everypart of the organization, all the time. This is the “golden rule” oforganizational design.
When the CTO title is interpreted as a technology czar, the operationsgroup becomes a passive dumping ground and cannot deliver or be heldaccountable for the cost or quality of its services. This is absolutelycounter to my vision of a healthy organization where everybody is aninternal entrepreneur empowered to run a business within thebusiness.
The Lone Genius
OK, so maybe your CTO isn’t a czar. Another form this role takes isthe “genius” reporting to the CIO who is annointed with responsibilityfor the future of technology throughout the IT organization.
This interpretation gives the CTO three roles: The CTO tracks emergingtechnologies and plans technology directions for the entire ITdepartment; the CTO coordinates all the various IT engineers (who may report toothers) to ensure integration; and the CTO takes on the really toughnew-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 everybodyelse that he can do the technology research in every branch of ITbetter than all those who have dedicated their careers to a specialtywithin IT. To me, this is utter arrogance.
This structure is symptomatic of an organization that can’t figure outhow to set aside a portion of everybody’s time for learning andinnovation, and instead partitions off an entire group that doeseverybody’s thinking for them. The rest of the staff are denied theexciting part of their jobs—researching new technologies—and aredisempowered as entrepreneurs since they cannot plan their futureproduct lines.
Second, the CTO tells everybody else how to design their systems in thename of integration. I guess this role must be needed because the restof the staff refuses to team with one another on projects, or tocollaborate on standards decisions and a vision of future systems.
Again, it’s using a CTO to make up for a fundamental fault in the restof the IT organization—the lack of teamwork.
And third, whenever the going gets tough (or really interesting), theCTO takes the project away from the rest of the staff. Everybody else isdenied those career-growth opportunities. As a result, they aren’t giventhe chance to gain experiences that will help them with their moremundane 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 asproject management support or time for professional development) to takeon stretch assignments.
When you use a CTO to make up for deficiencies in the rest of theorganization—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 stillfar from ideal. It assigns the CTO title to the head of bothinfrastructure engineering and operations. This doesn’t disempower peers in the way that the first threedefinitions do. But it’s still a poor structural design. Essentially, itputs Hewlett-Packard and AOL under the same boss.
So what are the incentives in this structure? The CTO must keep theinfrastructure running smoothly. And the CTO is expected to be thesource 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 inevitablyinduces a bias one way or the other (depending on the bent of the CTO).Most often, firefighting swamps innovation, and the pace of technologyinnovation slows as the entire infrastructure organization is focused onkeeping things running reliably and keeping costs down.
It also creates problems with teamwork. Note that infrastructureengineers serve infrastructure operators, but they also joinapplications engineers on project teams and sometimes they deliverproducts directly to clients. When the engineers report to the same bossas the infrastructure operators, their tendency is to neglect theseother 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, notboss-subordinate. Engineers continually put innovative proposals on thetable. Operators decide whether or not they’ll buy new technologiesbased on the needs of the market and their ability to operate themreliably and cost-effectively. This balance of power leads to the idealbalance of innovation and operations.
All Chiefs?
In a healthy organization, every group is fully empowered to run itsline of business, be that an applications or infrastructure engineeringbusiness, or an infrastructure-based service bureau (computer andnetwork operations). Nobody does the thinking or decision making for anybusiness but their own.
Furthermore, in a healthy organization, lines of business are notcombined in such a way as to create conflicts of interests—likecombining engineering and operations.
Perhaps the CTO title could be given to the head of one line ofbusiness, such as infrastructure engineering. But wouldn’t that implythat one of the CIO’s direct reports has a status greater than herpeers? To be fair, all the tier-one leaders should then be called “chiefsomething-or-other.”
Of course, when you do that, the title loses meaning (like vicepresidents in a bank). And IT might look a little silly when the leadersof this support function carry titles more gradiose than the managers ofline functions like manufacturing and sales.
Personally, I’d leave this fad title behind, and instead focus on titlesthat 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.
