Implementing a great idea takes common sense and good marketing. It also requires knowing who to motivate to implement change. In this article, Clarke Ching writes about a time when he figured out a simple solution to a complex problem that would save his employer millions, but no one seemed to care. Clarke discovered that it is far easier to sell aspirin if your customer already has a headache.
The last time I did something truly clever was in late 1996. I solved a problem that previously had seemed impossible to solve. Yet I found the solution to the problem in thirty minutes, while working on another project. I was very pleased with myself. At the time I was the technical lead of a development team in a medium-sized bank, which had just been bought by a larger bank. The key motivation for the merger was the cost savings: Together we could serve the same number of customers using fewer branches and head office staff. Another major cost saving was that the smaller bank's IT systems could be switched off, the excess hardware sold, and many staff laid off as well. My team was working on one of the migration projects.
In the early stages of the migration, I discovered a major technical problem. During the period when the bank was planning to close branches, more than half a million customers would have to visit their local branches in order to key in new security PIN numbers. Because the customer's card number would change during the migration and the debit and credit card PINs were encrypted using the card number as one of the encryption keys, the new PINs would not work on the new cards. These "technical complications" were well known throughout the banking industry.
I discovered a very simple way of overcoming this problem, unexpectedly, while reading some very dense technical documentation for an unrelated project. It was one of those light bulb moments you see in cartoons. Within thirty minutes, I had documented the solution and "proved" it in theory with my colleagues, but it still needed to be proved with an experiment. I spent another hour or so polishing a memo describing my solution before sending it off to—well, that was my next problem. Who should I send the "solution" to?
Being in my mid-20s at the time and full of technical strength coupled with an unhealthy dose of confidence and naïvety, I sent my memo straight to the program manager of the IT migration project. I had been careful—as I'd been taught to do—to send him not only a problem but also a solution. I sat back and waited for my email to ricochet around the organization and for the plaudits to rain down on me. And, sure enough, a few minutes after hitting the send button my PC chimed, indicating a new email had arrived. The program manager replied with a simple "Thanks!"
Still, I waited for the plaudits. And waited. But nothing happened. After a week of pressing the refresh button on my email software every five minutes, I rang the program manager to check how things were going. He listened politely to my query, said he couldn't remember my email, but promised to look into it. I was stunned by his lack of interest. I knew he was a busy man, but my memo clearly indicated that this project had a small cost—less than a month's work for one person—and a big benefit. The branch closures could happen sooner, and the bank could save millions.
Three weeks later, after no response from the program manager, I called him again. He thanked me and told me that he looked into my memo but that the decision had been made not to pursue the issue any further. Hmm, I thought. So I fired up my email client, printed the original email, and headed toward the cards department. They, after all, were the people causing the problem. Somehow I managed to bump into the head of the cards division just as she was leaving the office for the day. I cornered her, explained the situation, and gave her a copy of my memo. She said, "That sounds very important," thanked me, and promised that one of her project managers would contact me. And one did, the very next day. He, too, agreed that this was a big problem, thanked me, and said he'd get onto it.
I left that day pleased that my perseverance had paid off. But nothing happened. A couple of weeks later I received an email from the credit cards project manager thanking me for my input and saying that for now they had decided to drop the project due to "resource issues."
By now I had grown weary of my little project. It was time to give up. Why should I care, I rationalized, when older and wiser people obviously don't. It isn't my problem, I consoled myself. The problem isn't causing me any pain. If they're idiots—well, so be it.
It was then, of course, that I realized that I was the idiot, not them. I had presented the problem and solution to people who—just like me—didn't suffer due to the problem. My email to the IT program manager just landed him with more work. It was the same with the head of credit cards. It slowly dawned on me that the people who should be informed were the ones in charge of the branch closures. They were the ones who would suffer from the problem. So I talked to them. Surely, I figured, it was easier to sell aspirin to someone with a headache.
The folks in charge of the branch closures were reluctant to talk to me at first. But once they got past the techie jargon and recognized that this was a serious problem that would hinder them from achieving their goals, they became enthusiastic. My idea—or a variation on it—was implemented quickly and seamlessly.
A decade later, I still remember the valuable lesson I learned from this event. We techies can achieve more if we apply a little common sense and basic marketing skills to our problem-solving approaches. And don't be discouraged if the only time anyone thanks you for your idea is when they're politely dismissing it.
