IT-Averse Senior Management? There's a Workaround for That

Last week, I was talking to someone, and - totally unexpectedly - two situations I had completely forgotten about resurfaced in my memory.


Situation #1

Quite a few years ago.

I am sitting in the office of an old friend of mine, who owns and runs a successful business. His company is larger than what in Europe they call a "medium-sized enterprise", but not huge. As a person, he is, quite possibly, the nicest businessman I've ever met. You should see how courteous he is with the cleaning lady... but I digress...

So, we are sitting in his office chatting about his business. He is telling me about some of his challenges, and I am throwing ideas (naturally, the IT kind) back at him - just to keep the conversation going. Even though I am careful enough not to get too technical, I can tell by the look on his face that he does not understand much of what I am saying. Then, looking a little embarrassed, he confesses that all of it is totally over his head, that he "hardly knows anything about computers", and that he only occasionally uses his "obscenely expensive, but mostly useless, laptop to send personal e-mails".

As tactfully as I only can, I inquire if this (I can barely stop myself from using the word "disability") complicates his professional life. "Not at all," he replies cheerfully. "At work, I have a girl for that," he adds pointing at the door behind which is the office of his administrative assistant.

This was before AMC's Mad Men. Otherwise, I would have thought I was at Sterling Cooper.

Image from The Watcher, a Chicago Tribune TV blog by Maureen Ryan

Image from AMC Blogs

Note: In order to be completely objective, I have to explain that, in the country where this conversation took place, the word "girl", although not entirely appropriate in workplace context, did not sound as terribly politically incorrect as it would have in the U.S.

Situation #2

A couple of years later.

I am in the final stage of gathering functional requirements for a custom enterprise system at an organization of about the same (as above) size. There are only a few things left to elicit: (1) what data can be changed exclusively by the top executives, (2) what data the senior-level executives need to view most frequently and (3) what the most frequent questions they want answered, based on the data, are.

One of the top managers I am talking to is very cooperative. We identify what decisions only he and the other C-level guys can make (i.e., what records only they should be allowed to edit - that is what I really want to know). Then, he explains to me what kinds of reports they usually need. He also tells me how very excited they are about the prospect of being able to "sink their teeth" into real-time data. Just to be on the safe side, I still interview those who prepare all those reports now. The "report generators" appear even more excited than their bosses because the reports are very time-consuming and prevent them from performing their day-to-day tasks. So, they can't wait for the new system to be implemented and for the burden of generating the reports to come off their shoulders. I am somewhat overwhelmed by this universal outpour of excitement, but, nonetheless, feel good about being able to help these people get more productive.

Fast-forward another six months or so.

The new system has just been deployed, but the old one is still running because nobody has been trained to use the new one yet. The first training session is about to begin. It's an introductory session the objectives of which are just to give everybody an idea of what the system does, to show them the UI, and teach them how to create their accounts. The only C*O present announces that the new system is up and running, and that, after a few training sessions, the company will make the switch. He then talks about how excited they are (again!) and... leaves.

Two days later, the only ones without accounts are, not surprisingly, the top executives. I quickly write up step-by-step instructions how to create an account, add a few screenshots to make the page more visually appealing, and e-mail the link to them. No reaction. A few days later, another try. The same result.

Toward the end of the two weeks allocated for employee training, I did manage to meet with them briefly once. I told them the story about my friend (see above) and even alluded to Mad Men implying that the way businesses operate had changed since the early 1960-ies. That didn't go extremely well, I must admit. Finally, I gave up and created accounts for them myself. To the best of my knowledge, they never logged in to those accounts.

I will spare you my story of trials and tribulations and will just say that, in the end, company-wide, everything worked out just fine. How? - See the next section below.

Note: A few years later, this organization ceased to exist. I am not implying anything. I am simply explaining why now I can tell you this story, which, were they still in business, I would, of course, keep to myself.

Workarounds/Conclusions

1. When a user states that certain functionality is needed, it does not necessarily mean that he or she is going to be the one using it, even if that seems (to you) to be the most logical and productive way of doing things. In the second "case study" above, after the new system was implemented, the employees who used to prepare reports before the switch continued to do so after the switch, even though the top executives had the option to run reports themselves very easily and quickly (generating a report required less typing and about the same amount of time as e-mailing report parameters to an employee who then generated it). The employees who generated the reports were not required to view the report data (some of which, by the way, was considered sensitive) in order to perform their day-to-day tasks. So, they had to be granted additional, otherwise unnecessary, permissions just to be able to run the reports.

2. A business application must not have single points of failure, even if client's business practices have them (the latter often is beyond our control). In the second "case study" above, there were some decisions that only certain senior executives were allowed to make. In terms of application design, it meant that only one user should have had the permissions to update certain types of records. I don't need to tell you that, given the obvious reluctance of the top managers to actually use the software, literal translation of those business practices into the application business logic would have led to producing a piece of software that, contrary to its objective, would hinder the business. So, mid-level managers, even though they were not the decision makers, were also given the permissions to update those specific types of records.

3. Top managers must fully understand the security implications of the above workarounds and explicitly state that they are comfortable with such "erosion of security" caused by granting users permissions that are less restrictive than necessary. Also, top managers should have an option to revoke those additional permissions should they, at some future point, decide to change their modus operandi.



P.S. While writing this post, I stumbled upon quite a number of articles, research papers, and even full-blown books that deal specifically with how and why senior managers use (or do not use) information technology. One of them, Computers in Top-Level Decision Making by R. H. Brady, was published back in 1967. Since then, many researchers have taken a close look at the subject. Quite a few acknowledge that there is certain reluctance among senior executives to use information technology. Some of the reasons cited are pretty interesting. I am not going to elaborate here as this is beyond the scope of this post. For a quick overview, you may take a look at Use of Computers and Applications by Senior Executives by J. L. Cano Giner published in 2011 in the Journal of Industrial Engineering and Management.