CIOs face many challenges in today’s ever changing technology landscape as we continue our ascent into a cloud first world. However, as with any times of change, those challenges offer many opportunities as well. In this blog post we’ll explore both while offering CIOs advice on “what to do if you find yourself stuck with no hope of rescue” — taking a page out of the Hitchhiker’s Guide to the Galaxy.

CIO vs CTO

Before we dive into our main content, let’s review the distinction between the role of a Chief Information Officer (CIO) and a Chief Technology Officer (CTO). And while we will focus most of this discussion on the CIO role, much of this is relevant to the CTOs out there as well. The biggest distinction between these two is who they are serving. The CIO generally serves the employees of the organization itself focusing on information technology processes, operations, internal services delivery, and productivity tooling. For example, CIOs would deliver services such as Microsoft Exchange or the Microsoft 365 application suite — which most people are probably familiar with. Meanwhile, the CTO generally serves the organization’s customers with product and services’ development and delivery to increase investments and revenue.

To bring these roles into further focus, let’s use a fictional company of Looney Tunes lore, the ACME Corporation. We’ll brand ACME as an entertainment company specializing in developing and delivering cartoons. The CTO of ACME might focus on building a platform to stream their catalogue to millions of users. They would also look at user-generated data to better understand what the company’s user base likes, such as what type of cartoons users are most interested in. Conversely, the CIO might determine what cloud provider and specific cloud services to run this platform and infrastructure on. They would manage all those costs and SLAs as well as any support issues that need to be fixed immediately while ensuring all this activity stays within their yearly budget.

Another angle to consider is from the perspective of building the product – the cartoons. The CTO might conduct extensive research on what graphic design software to leverage while the CIO would ensure designers using that software have the proper product licenses and that the workstations running this software are powerful enough for it to be effective. Anything surrounding the providing, decommissioning, refreshing, and support of these workstations would also fall under the purview of the CIO.

Building a Delivery Team

At their core, CIOs are people managers. They will generally manage larger teams that have more diverse skill sets to successfully manage and deliver employee productivity tools in a variety of ways across the various business units.

Let’s use the basic example of an employee who needs to create a document. There are several ways you can think about measuring this individual’s productivity in creating said document: how fast can the document be produced, how professional it is, is the document informative and relevant, how many words does it contain, etc. But consider the tooling that would need to be provided by the CIO to ultimately create this document. If all they had to work with was Notepad, it would be very difficult to produce almost any document. The limits of the “undo” and “redo” functions alone would hinder this individual’s productivity as Notepad only remembers the last undoable action. However, an application like Microsoft Word makes it possible to create, edit, and design this document quickly and easily and can remember the last 100 undoable actions.

Now consider the effort required to deliver a Notepad vs Microsoft Word application to your user base as a CIO. Notepad is essentially a no-effort, free delivery application. The CIO doesn’t need to do anything except provide users with laptops since almost every OS has Notepad on it in one form or another and there are no licenses or deployments to manage. Whereas, for Microsoft Word, you’d need to deploy the Microsoft 365 productivity suite which comes with Word or license and deploy a standalone version of Microsoft Word. It takes careful planning and execution at the CIO level to deliver something like this to your user base. Especially when you consider the scope of delivery for the Microsoft 365 suite. And this is just a basic example. Consider how much more complicated it would be to develop custom sales tooling that aims to provide targeted customer information to sales and product teams. Or to customize sales qualification and tracking tooling such as Salesforce.

When a CIO thinks about what they need to deliver to their customers – which is everybody who works for the company – they need to break down the individualized needs of each business unit and what skill sets their own team must possess to successfully meet these needs.  Teams that can deliver a Microsoft 365 solution are probably not able to deliver a custom data analysis application or sales tool.

Advice for CIOs

Keep in mind that CIOs have one of the highest levels of turnover within the C-Suite. According to Zippa,about 63% of CIOs will be at their company less than five years. All of this begs the question, how can CIOs build a fundamental bedrock for successful IT delivery within their organization? In my not-so-distant past as an IT consultant, I worked with many a CIO to help them deliver solutions to their customers — e.g., their organization’s employees. And I’ll boil down my more than a decade of consulting experience into the following points of advice:

  1. You’ll never have enough time to do it right, but you’ll always have enough time to do it again.This is the number one killer of CIOs in my experience. Every project comes with a certain level of panic and urgency (both real and imagined) to deliver. And teams can become focused on edge cases vs core functionality. The key here is to allow your team the necessary time to deliver and design for 80% of the functionality, not 20% of the edge cases (the 80/20 rule). This will require both mature strategic and tactical levels of execution including push back — especially when unrealistic timelines are presented by business units that take for granted the complexity of IT delivery.
  2. Leadership hiring. Rigid, top down and flat organizational structures where everyone operates in the same way is a mistake and relic of times long since past. Teams must have flexibility to operate as needed. Much like agile software development, principal design, delivery and support teams should be as autonomous as possible. CIOs should focus on hiring good leaders and managers who will build their teams as they see fit to deliver much-needed solutions in a way that will enable the business versus backing into a single one-size-fits-all type of team building approach.
  3. Review the data and consult the anecdotes. Just like with any external customer-facing product, internal systems will generate data about the users, and CIOs should strive to analyze and derive insights from them. However, user generated data isn’t all that should be consulted, and I want to pull a quote from Amazon founder, Jeff Bezos, to make my point: “The thing I have noticed is when the anecdotes and the data disagree, the anecdotes are usually right. There’s something wrong with the way you are measuring it.” And the best way to get these anecdotes leads to my next point…
  4. Be a CIO of the people, for the people. Everything I’ve talked about thus far has had the underlying assumption that the CIO knows what’s best for the employees of the company. But you need to get honest feedback from employees across all business units including leaders, managers, and individual contributors. To do that, CIOs must break the stereotype that executives are towering figures of power that we must always strive to impress. CIOs are people, just like you and me (unless you’re a bot reviewing this content!). The more you break this stereotype, the more employees will open themselves up to you and give you the honest anecdotal data you need to provide them with the tools essential to their success
  5. Do not overwork your teams regularly. There are always times where teams will need to go above and beyond the call of duty to execute. However, these situations must be rare and rewarded accordingly. Don’t push your employees to the brink. If your teams are working nights and weekends, constantly putting out fires, and maturity levels of technology and support delivery are not improving… the hour is getting late in your tenure. If a CIO allows this situation to continue unchecked or is unaware or uninterested in it, their days are numbered. And I will reiterate that CIOs have one of the highest rates of turnover in the entire C-suite. When people enjoy and want to work as part of your team, as a CIO, your shelf life is greatly increased.

Thanks for reading my blog post and check out the companion podcast for additional insights!