When talking to business executives and vis-à-vis recruiters working for them, often I find confusion about the roles of technology leadership positions. CIO and CTO titles are frequently used interchangeably. For the sake of clarity, I’ll offer my observation that Information Technology leaders tend toward one of two orientations: Internal business processes or external product development. Also, we deal with what the CIO or CTO is not which usually leads a company to hire the wrong person for the job.
I hope this post helps clarify those who are confused by the title CIO or CTO and what we do for companies. For the purpose of my sanity and maybe future trend for a new title let’s call the combined roll “CITO*.”
So the CITO summons together technology and moves the company’s IT forward.
An IT Leader is the most senior executive in an organization responsible for the information technology and computer systems that support team goals. The CITO most effectively reports directly to the Chief Executive Officer (CEO) and is a key contributor in formulating strategic goals and implementing immediate business plans.
Before we get too far down the path of what a CITO is let us ask:
Firstly, what the CITO is not.
- CITO is not an engineering / programmer role. CITO is not the top of the technical ladder, and it is not the natural progression for engineers or developers. It’s not the role most people who are in love with just coding, creating architecture, and deep technical design would enjoy doing.
- From 1, it follows that the CITO is not necessarily the best developer/engineer in the company, nor as I have seen the technical founder of a startup.
Now, with that out of the way, let me mention that far too many job description postings state they want the CITO to be hands on developer. So you want is a lead developer with project management skills, not a CITO, please fix your job description and you will find what you are looking for.
If CITO, if not the best writer of code and natural conclusion of the engineering ladder? Then the challenge with defining CITO is that if you look at the folks who hold that title, you will see many different manifestations.
More specifically, the real IT Leader is involved with analyzing and reworking existing business processes, with identifying and developing the capability to use new tools, with reshaping the enterprise’s physical infrastructure and network access, and with identifying and exploiting the enterprise’s knowledge resources.
CIO is primarily internally-facing
The CIO, or the Chief Information Officer, is a company’s top technology strategist who understands the business information needs of the company and the stakeholders of corporate operations. Maintains internal IT systems, including company information domains and business processes, typically reports to the CEO on business models and vision issues, and collaborates with other business executives to learn their needs and develop new concepts. The CIO is a business person with IT experience.
Focused on the company’s bottom line – how to improve internal communication, PMO management, and process control. Concentrating on improving the efficiency of internal processes to guarantee effective communication, maximize productivity, and keep the organization running efficiently. This is an operations role and since it is internally facing the CIO is typically responsible for Infrastructure, Service Delivery, PMO, etc.
CTO is primarily customer-facing
The CTO, or the Chief Technology Officer, is a company’s top techie who most understands what’s behind technology alternatives and frequently heads product research and development initiatives as they relate to the company’s current and future product offerings. Typically reports to the CFO or CEO (depending on corporate size and structure), and plans for technology evolution of the company systems. The CTO is a technology person having some familiarity with business models.
Focused on the company’s top line. The CTO ensures that the corporation is implementing technologies that enhance product development. Responsible for the engineering teams and employing a technical strategy to improve the end product (thus customer facing). This strategic role and the CTO is responsible for leveraging new technologies to enhance the product (which can include infrastructure as well but only as it relates to the product and not the internal IT operations).
Most companies will not rationalize a need for both roles unless they are enormous product creators like automotive or consumer goods companies. Given that these are “C” level positions the cost to employ both parts are not cheap.
In that scenario, a company should consider its primary goal. A new and well-backed start-up might be more interested in developing a technology strategy more so than improving efficiency while a growing mid-size company with a sound technological strategy already in place might be more focused on increasing efficiency to maximize its return.
Once a company begins to mature into a large corporation both roles are necessary – and more so if that company is attempting to leverage technology as part of its core business (in which case the CTO might also be more important up front). The fact is, for a small or medium sized company, either position likely has enough insight to fulfill both roles but should be complemented with strong supporting managers.
The key difference to remember is that a CIO (operations oriented) is internally facing, focused on information systems (communication workflow), with a target to increase efficiency thereby improving the bottom-line while a CTO (technology strategy oriented) is customer facing, focused on a technology strategy, with an aim to improve the end product.
As a company grows and roles have defined the responsibilities of these positions will tend to mesh together and become a little blurry. So, when defining roles and responsibilities within your Information Technology organization, ask yourself one thing – is this function / division necessary to support operations or are they part of the technology strategy to support product development?
Here’s my take. The CITO’s primary job is to make sure the company’s technology strategy serves its business plan. If that sounds either too simple or too generic, think for a second if any companies you know do the reverse. Have you ever heard a technology leader use technical mumbo-jumbo to make it sound like a business idea they didn’t like was impossible? That’s what we should be trying to avoid.
What the CITO needs to provide
- Seeing the big picture – the CITO should be the person in the room who can keep everything your technology can and can’t do clear and articulate it to others. That means knowing what is written and what’s not. What the infrastructure and architecture can and can’t support. Realist of the timeline, how long it would take to build something new or upgrade to the latest thing. That is more than just drawing architecture diagrams, and creating Gantt charts, though. Being able to see the macro and micro simultaneously is a hallmark of all of the great technology leader.
- Provide options – another mark of a great CITO is they never say “that’s impossible” or “we’d never do that.” Instead, they find options and can communicate them to everyone in the company. If the CEO wants to change the product completely to serve a new customer segment, you need someone in the room who can digest the needs of the new proposed business, then lay out the costs of each possible approach to serving the potential customers. Some techies have a tendency just to “decide for you” and give you the “best” option, but that’s dangerous. You can’t have an honest dialog if one party knows all the answers.Also why letting developers talk to customers too many times I have heard them say the system can’t do that. Then you sit with them and discuss all the option they even sometimes come up with we can do that. Unfortunately, you probably lost a potential client and got another black eye for the tech department.
- Find the 80/20 – this was my favorite part of the job. Sometimes, you’re in a meeting where someone wants to build a new feature. And in their mind, they’ve got it all specified out. It slices, it dices, and probably irons your shirts too. (ok because I hate ironing) Think about it, you can hear the Ka’ching, they’re racking up costs, uh oh. On a bad day, I would give them the real sobering news. A good day looked like this; once there is an understanding of what the objective was for customers. See a way to get 80% of the benefit for 20% of the cost. Would you be able to learn what you need to learn if that feature just sliced, but not diced? Because if we don’t have to add a dicing module, “we can repurpose the Phasers and set them to Stun…” I’m continually amazed by how often they answer “really? Dicing is what’s expensive?! I just threw that in there on a whim!”
- Own the methodology – in traditional project management and or product development, the VP Engineering or some other full-time manager would be responsible for making sure the engineers wrote adequate specs, interfaced well with QA, and also run the scheduling “trains” for releases. I will complain about pure “Agile” some other time, for now, if the team is going to use sprints, TDD or JIT scalability, for example, these choices have an enormous impact on what the architecture must look like. At a minimum, it is the CITO and Tech Leads that have to be responsible for five why’s style root cause analysis of defects. Otherwise, how can they find out what their blind spots are and make sure the team and the architecture are adjusting? That job calls for someone who sees the big picture.
I apologize for all the tech jargon about CIO, CTO, and CITO. How’s this…
- Be the Voice of Technology
- “IT Leader,” “Technology Guru” and “Value Generator.”
- Translation: “Head Geek with a Business and Operations Background.“
I’m touched by all the support I’ve received from family, friends, coworkers and recruiters who have no idea what I do.