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 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
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
Solving a problem vs. saving face
In this case, there were two problems to solve:
why the e-mail did not make it to the customer
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
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.