Over the past three years, we have redone almost everything about the technology at my company. We have migrated...
lots of services to the cloud, replaced our phone and network systems, and implemented software-as-a-service versions of CRM and of our contact center software.
We replaced our spinning disk with solid-state drive storage for all of our production systems. We implemented hyper-converged infrastructure, achieved our SOC certification and modernized our client-facing legacy applications by embracing a microservices architecture. We also have gotten really good at Agile and DevOps -- we have applied for three patents for our inventions around application-level security in DevOps -- and we have used this expertise and these up-to-the-minute technologies to develop a bunch of new applications and services.
All of this took time, money and people. Which 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 for three years. 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.
Three years ago, I felt strongly that this was a worthwhile investment, but would the rest of the organization see it the same way -- particularly my peers and my boss?
Art of communicating: The importance of '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 big tech ideas.
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. And when I finished my presentation, I expected immediate approval.
Instead, the only question anyone asked was, "So, why do we need to do this?"
That happened a few times before I realized that the audience can easily get lost among the data and technical facts. Lost and dazed.
In my quest to learn how to make my case, 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 that 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 direct reports, 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 that 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.
Art of communicating: How to collect stories
Where do the stories come from?
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 that? 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 asked us to put a new project on our list: He needed us to add a new supplier to our list of vendors.
The problem was that the supplier was based in a state in India that was not yet in our tax structure. In India, taxes vary wildly from state to state, and so it was going to take a team of two accountants and four IT people six weeks to add this Indian state to our tax structure. If we were using a standard chart of accounts and tax structure (instead of our wacky, highly customized version), it would have taken one a person part of a day to do the work. I added this information 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, since they can relate to and remember the stories, my audience can then explain the why of the project to the rest of the organization.
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.
A CTO makes his list: Five hot IT skills to go after
Humans will always sabotage security -- deal with it
Tech pros must master art of communicating to become leaders