The "Chief Technology Officer" (CTO) job title has been around the IT industry for a long time now, so it's had enough time to settle in. Unfortunately, it's far from settled; and that can be unsettling.

The title originated in technology vendors where the CTO was responsible for product research and development. It was quite popular in the dot-com companies of the 1990s, and is widely used in companies where the product or service is IT-based.

From there, it spread to internal IT departments.

In some companies, the CTO title is used in place of the CIO title, meaning the senior-most leader of the entire IT function. This is rather innocuous; after all, what's in a name? (This is generally the case in financial investment companies where "CIO" stands for Chief Investment Officer.)

In other companies, a CTO reports to the CIO. In these cases, the title may have any of a number of different meanings:

• A senior leader who manages both infrastructure engineering and infrastructure-based services.

• A senior leader who manages all the IT engineering functions, including applications, end-user computing (e.g., collaborative tools, data analytics), and infrastructure engineering (but not infrastructure services); or one who manages all engineering functions except applications development.

• A "chief operating officer" for all of IT, managing everything except perhaps client liaisons (sales), business-office support functions, and the CISO.

• An expensive individual contributor (or small group) who researches new technologies and makes strategic technology decisions.

With no single widely accepted definition, the CTO title has little meaning. It's handed out as an honorific -- a grandiose title used to attract, motivate, or retain executive talent.

But some of the organizational structures implied by the title can be problematic.

CTO in a Technology-based Company

In companies where IT is the product or the basis for the service, CTOs lead the engineering function that develops and supports the company's externally facing products and services.

Meanwhile, a CIO provides IT products and services to customers within the company.

With two IT groups -- one externally facing, and the other internally facing -- the challenge is to avoid replication of centers of excellence. Whenever an engineering specialty is divided in two (one for external, and one for internal customers), the depth of specialization is inevitably reduced. To illustrate this, compare two different ways you might utilize two people:

1. One person specializes in one technical discipline and the other in another, and both serve all customers (external and internal).

2. Both people cover both technical domains, but serve different customers.

Clearly, option 2 reduces technical depth (while optimizing customer knowledge, a sales function). With less specialization, every aspect of performance is reduced -- speed, quality, innovation, and cost.

To avoid this pitfall, the CTO should only manage engineering specialties specific to the company's products and services. All specialties which are shared between external and internal products and services should be put under the CIO as shared services to both the CTO and internal IT.

Leader of Both Infrastructure Engineering and Operations

Within some IT departments, a CTO manages both infrastructure engineering and operational services (many of which are infrastructure based).

This creates a fundamental conflict of interests:

• The operations function seeks to maintain safe, reliable, efficient ongoing services, like water from the tap. It's appropriately careful about innovation, moving forward only when technologies have matured to the point of being operationally stable and safe, and where the market (within the company) makes the investment economic.

• The engineering function's core mission is innovation. It's their job to continually bring new technical options to the table for consideration.

Keep things stable. And shake things up.

Conflict of interests built into people's jobs 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).

Tell me this: Would you bring innovative new technologies forward, knowing that their implementation will disrupt smooth operations, when your boss is accountable for operational stability and costs!? Generally, the answer is no. Most often, firefighting swamps innovation, and the pace of technology innovation slows as the infrastructure organization focuses on keeping things running reliably and on driving costs down.

If it goes the other way -- if the CTO has a preference for the engineering side of the house -- then operational stability and cost are at risk.

The balance between innovation and operations should be decided by a dialog between the two functions, not left to one manager's personal predilections. Their relationship is best described as customer-supplier. Engineers continually put innovative proposals on the table. Operators decide whether or not they'll buy those new technologies from the engineers 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.

Putting engineering and operations under the CTO also can create 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 infrastructure engineers report to the same boss as infrastructure operators, their tendency is to neglect these other customers who are outside the CTO's group.

Beyond that, engineers and service managers are two very different types of professionals. While operations staff may be great at service management, they're not typically skilled in project delivery. Meanwhile, engineers are (supposed to be) great at project management, but generally aren't interested in paying attention to day-to-day operational tasks.

It's unlikely that one person can mentor both types of professionals. Engineers should be led by someone who deeply understands the engineering profession; and operational services by someone who's dedicated his/her career to service management.

In a healthy IT organizational structure, engineers and service providers report through two different senior executives, not through one CTO. They are peers, just as Boeing and airlines who buy their planes, and car manufacturers and rental car companies, are peers in the real world.

Leader of All (or Most) of IT Engineering

Clustering all IT engineers under a CTO is not in itself bad. But the CTO title may reduce your degrees of freedom in designing your organizational structure, and may add an unnecessary layer of management.

Let's say there are seven different engineering domains reporting to a CTO. So far, so good.

But now let's say that the IT department expands, and the number of technology domains grows to 12 or more.

To manage span of control, those 12 groups could be divided between two executives. And it may be that adding another direct-report to the CIO is within the CIO's feasible span.

But to maintain the CTO title, the two executives would have to be put under the CTO. This adds a new and unnecessary layer. And the CTO doesn't have much of a job managing only two senior leaders.

This not only wastes money and precious executive headcount. Added layers slow and distort communications. And leaders with too-few direct reports often micro-manage their subordinates for lack of anything better to do.

It's specious to argue that the engineering community needs a common boss to collaborate effectively with one another, be it on today's projects or on an integrated vision of future technologies. If an organization fails to build cross-boundary teamwork and professional collaboration processes, then everybody will have to report directly to a single manager (the CIO), since everybody must work with everybody to produce today's complex technology solutions and services.

The CTO title may feel good to the incumbent. But this definition of it doesn't add business value, and it takes away options when designing an effective organization chart.

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 client liaisons (business relationship managers, i.e., sales), some support functions (PMO, IT finance, supplier management, etc.), and the Chief Information Security Officer).

I've seen IT organizations where the CIO had only two direct reports: a CTO, and a head of the IT finance and planning group.

Again, it's not a full-time job to manage just two people. This manifestation generally indicates a CIO who's turned over his/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. Or perhaps he/she is just "retired on the job."

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

Even if the CIO's job is reasonably secure, his/her ability to contribute is diminished when people realize that he/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 most of the IT organization, then why not add the few remaining funtions in and stick with the CIO title?

The Lone Genius

Another interpretation of the CTO title within IT departments is an individual (or small group) that does the strategic thinking for the organization. This may include standards, design patterns, technology research, and even high-level designs of complex solutions or leadership of tough technology projects. Such a CTO may be annointed with responsibility for the future of technology throughout the IT organization.

Why would such a function be necessary? Why isn't every group thinking about the future of technologies within their domains? There are at least three reasons:

• Other groups don't have the time.

  This is a red herring. If the organization as a whole can invest staff's hours in strategic thinking, then those hours can be fulfilled by the existing technology domains as well as by such a separate group.

  And if those other groups' time is fully absorbed trying to fulfill unmitigated client demands, then fencing off time for strategic thinking should be done through demand management, not by separating thinking from doing in the organizational structure.

  More on demand management....

• Other groups don't have the "big picture."

  This is another red herring. The big picture should be an amalgam of the perspective of all the various technical domains. The best answer is collaboration, not a single small group doing all the big-picture thinking.

  If a CTO conceives the job as a facilitator of consensus among all the stakeholders, the collective big picture will emerge. It will be a far better vision thanks to the contribution of all those bright minds in their respective fields. And due to their engagement, the staff who much implement the vision will understand and support it.

  In an empowered, entrepreneurial organization, big-picture plans are the result of a collaborative process, not a job for one person or group.

• Other groups don't know they should think strategically.

  Perhaps other groups think they're there to manage resources and projects, not run internal lines of business. As such, they don't know it's their job to keep their product and service offerings up to date.

  This can be addressed first through a structure that defines all jobs as businesses within the business, and second through a culture that teaches the behaviors of entrepreneurs.

A CTO function that does the strategic thinking for the entire organization disempowers everybody else. It forces on others directions that they must deliver (accountability without authority).

It's disempowering (and demotivating) in another way as well. It takes away from others the fun, career-enhancing thinking and planning, leaving them to just crank out work with today's technologies and skills.

This kind of CTO function also creates a bottleneck for innovation. I hope that no one believes that one person (or small group) is so much smarter than everybody else that he/she can do the research and planning in every discipline of IT better than all those professionals who have spent their careers studying specific domains of technology in depth. To me, this is utter arrogance.

This definition of the CTO function is an example of seeing symptoms (need for big picture, slow pace of innovation, etc.) and throwing a structural group at them, instead of addressing the underlying root causes of the problems.

Whenever you use a CTO to make up for deficiencies in the rest of the organization -- time to think, teamwork, and new technology competencies -- the consequences are costly. You haven't addressed the systemic root causes of the problems, and you've created new problems.

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 provider (e.g., 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 his/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. And IT might look a little silly when the leaders of this support function carry titles more gradiose than the managers of 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.

Abstracts Free library

Books Speech abstracts

NDMA coaching/consulting services

UP.... NEXT PAGE....