Once, in a far away land filled with gray cubicles, I received a phone call from one of my customers. Now, customers were not supposed to call me directly, but this fellow knew I would be at my desk. He also knew I would not complain overly much; something about him holding signature authority over my contract with his company, or some such nonsense.
After letting the caller roll over to voice mail a few times, I set aside my nachos. Picking the hated black receiver up, I punched up a call back. With barely a single ring, the other end was snapped up.
"What took you so long?"
"Nothing sir, just fixing a problem." I fired up Tetris. "So, what can I do for you today?"
"The server ate my e-mail! This is a disaster!"
"Did you save it to your drafts folder again?"
The line went silent. "Um…"
I shifted out of my game and opened another window. "I'll mark it as an ID-10-T error on the ticket. Let the client know we apologize for the problem."
The above story is a work of fiction. Among other things, I don't like nachos that much. However, what it says about the relationship between computers, IT departments, and the user community sounds true. The "I" in the story acts as badly as our users expect us to; the executive "user" displays the incompetence that makes computer cartoons so funny to those of us in the industry.
Two sides of the story
In the interests of fairness, let's look at this situation from the two sides: mine and the user's.
I was working through yet another lunch, eating cold nacho cheese spread over stale chips. My flat diet cola was not helping matters. On three screens, I had routing diagrams; on my white board, an analysis of an intermittent network problem that kept cropping up at odd intervals.
Just as I was nearing the end of some note-taking, the phone rang. I ignored it. It rolled to voice mail, then rang again 30 seconds later. I let that one go for two minutes while I finished up my work.
Checking the phone, I saw it was one of my most important users—the manager for my company's outsourcing contract. I gave him an immediate call back.
He told me that one of his prospective customers had not received an e-mail he was absolutely certain he sent. With him on the phone, I fired up our administrative tools and traced mail usage. I could find no evidence at all that he sent any messages, let alone one to the customer, for at least 48 hours.
After much back and forth, I asked him what was in his drafts folder. The ensuing silence told me everything I thought I needed to know. I closed the trouble ticket I previously opened and bid him good day.
The user was in a panic. He was supposed to get back to a customer provided by the sales organization with a huge batch of spreadsheets about the company's internal capabilities. This was not something he usually did: He was a contract manager, not a salesperson. After a week of sweating bullets, he finally came up with something he thought would suit. He sent it, then tried to catch up with his own work—only to come under fire the next day for "not communicating with the customer."
In a panic, he called someone he hoped could help. When he hit my voice mail, he called me again, since he knew I was down there working on something or other.
When I did get back to him, our conversation wandered through a wide variety of, for him, esoteric fields. While I blathered on about routing information and message queues, his colleagues were preparing to burn him in effigy.
The final solution did nothing to ease his real problem. Yes, he got the e-mail to the client. However, it did not provide him with a plausible excuse for his lateness. In fact, it dumped the fire right back into his lap.
Solving a problem vs. saving face
In this case, there were two problems to solve:
- Determining why the e-mail did not make it to the customer
- Assisting my customer through a politically charged situation
The first problem did need some kind of resolution. From a technical standpoint, if e-mail is just vanishing into the ether, the server team really does need to know.
However, resolving the e-mail problem did nothing to alleviate the client's stress. Instead, he was left with an embarrassing incident and a professional problem. The underlying business issue—that the customer was dissatisfied with the situation—remained. Sending the message now got them the information, but did nothing to restore the failed trust.
As a senior resource, I could have worked with my client to come up with something more plausible than "the dog ate my homework." The black-box of IT can absorb quite a bit of abuse and outright slander without impacting our performance. Whether the client would have believed it or not, a face-saving half-truth like, "The server team told me the mail queues were a bit clogged last night. They apologize for the delay and will take steps to make sure it never happens again," would have saved face for the business users involved.
If I got a bit of egg on my face for the incident, what of it? I would always have my Tetris—and the knowledge that someone in the business world owed me a favor.