CIO as technology evangelist: Build your case for transformation
Technology change is hard -- and, these days, it's constant. Here's how one CIO learned to become a technology evangelist and got the time, money and buy-in for IT transformation.
Someone once accused me of being a bulldozer and only interested in tearing down the processes and systems this person had built. I replied that I only wanted to tear down the things that did not work -- sadly, nothing this person had designed worked, so, in their case, we did have to tear it all down.
If we, as IT leaders, are doing our jobs well, it means we are changing things -- technologies, processes, tools, systems and attitudes. I cannot think of a single legacy system or process that we have not changed in my five years with my current company. We have touched it all. We excel at DevOps. We have containerized -- and are now service-meshing -- everything. We have rearchitected around microservices. We have replaced our major systems. We have gotten good at analytics and reporting. We have changed our IT processes. And we have accepted that we will need to continue to change.
All of this took time, money and people. This begs the question: How did I convince the rest of the organization to approve the investments we needed to make in these areas? The question is not rhetorical.
While we modernized and refactored our client-facing applications, we slowed down our product and service innovation. And we have paid a price in the marketplace, as we sacrificed the here and now for a more nimble future on our modernized, updated product platform.
I feel strongly this was the correct decision -- an investment that would define our future. But, would the rest of the organization see it the same way, particularly my peers and my boss?
CIO as technology evangelist: Focus on the 'why'
I am no silver-tongued devil. I would starve if I had to make a living as a salesperson. I have no sense of messaging. I am not a great communicator. Yet, in my role, I have to make compelling business cases on a regular basis. Given my lack of selling skills, I had to figure out how to convince others to do what I thought we should. I was forced by circumstances to think about the art of communicating.
The first few times I tried to make the case for a project, I spent days collecting data and technical facts. I detailed server capacities, throughput metrics and cycle time reductions. I practiced my presentation. I anticipated every question. When it was time, everything went as I had planned, my role as technology evangelist fulfilled. And when I finished my presentation, I expected immediate approval.
Instead, the only question anyone asked was, "So, why are you telling us this?"
That happened a few times before I realized the audience can easily get lost among the data and technical facts -- lost and dazed.
In my quest to become the technology evangelist I needed to be, I read a book called Made to Stick: Why Some Ideas Survive and Others Die. The most important lesson I learned from Made to Stick is people relate to and remember stories.
I changed my approach and worked to master the art of storytelling. When I was making the case for a zero-customizations redo of our legacy ERP, I told stories about how long it takes us to create a new item, how many people it takes for us to add a new taxing district and how difficult it is for us to get answers to simple questions like product profitability.
My audience related to these stories because they were the ones who owned the item creation, accounting and profitability reporting processes. With those stories in their minds, it was simply a matter of my connecting the project to the solutions to those process pain points.
I never talked about server capacity, throughput metrics or cycle time reductions. Why not? Because these technical metrics, while meaningful to my IT teams, have nothing to say to my business peers and boss.
In becoming a storyteller, I also had to learn that the most important element of the story is the why. In fact, I now believe the why of the story is much more important than the what. And I almost never need to talk about the how -- how is an implementation detail that should never be part of the business case.
CIO as technology evangelist: How to collect stories
Where do the stories come from?
I now believe the 'why' of the story is much more important than the 'what.' And I almost never need to talk about the 'how' --'how' is an implementation detail that should never be part of the business case.
As I go about my business, I collect the microstories that, at some point, will build the business case. For example, for our zero-customizations redo of our ERP, I had to overcome a foundational belief that our processes were so unique that standard ERP functionality wouldn't just not work for us, but actually put us at risk.
How did I overcome this fervently held belief? By gathering -- for months -- examples of how our highly customized ERP put us more at risk than replacing it would. For instance, in one meeting, our corporate controller said we needed to put a new project on our list: The company had to implement the new tax structure in India.
Given the custom nature of our ERP system, it took a high-quality team of IT and business people about eight months to revise our systems for the new Indian tax structure. If, instead, we were using a standard chart of accounts and tax structure -- instead of our wacky, highly customized version -- it would have taken a couple of people, in their spare time, a couple of weeks to do the work. I added this story to my "let's redo ERP" evidence, along with scores of other such examples. When it was time to make the case for our ERP redo, I had dozens of stories that made the case for me.
Collecting stories takes patience. With some technology proposals, it takes me months to gather enough evidence to make my case, but I am fine with that. When I stand up in front of that audience, I want it to be a foregone conclusion that they will not just approve, but embrace the project. Even better, because they can relate to and remember the stories, my audience can then explain the why of the project to the rest of the organization. That's the mark of an effective technology evangelist.
Making a business case via storytelling has worked so well for me that I cannot remember the last time I talked about mundane things like return on investment, server speeds and throughput.
Next Steps
Read our in-depth guide for details of how the role of the CIO has evolved and learn what is required of them today.
Tech pros must master art of communicating to become leaders
