Our "What would you do?" column is a forum for sharing your knowledge and experience in dealing with the less tangible side of computer support: ethics. Every two weeks I’ll present a scenario that requires more than a technical solution. Each situation will be an accurate description of an actual event, with the names and other identifying factors changed to protect the innocent—and sometimes not so innocent. In four weeks, I’ll present feedback from the community members, along with the actual outcome.
For today’s column, I will first present the discussion that followed the previous week’s scenario. Then, we'll jump right in to the next problematic situation.
A tech wannabe goes too far
The previous column asked, “How would you handle a tech wannabe who wreaks havoc in your IT shop?” This situation centers around a person who was not a part of the IT department but who had just enough of an IT background to take over his division’s computers, often in such a way that the IT department had to waste time trying to work around his “fixes.”
This scenario generated a large quantity of detailed and often intense discussion threads and e-mails. In the space of this column, it is simply not possible to do justice to the quality of the ideas presented by many of the members, several of whom are in a position to speak from the vantage point of having successfully resolved similar situations of their own. That said, I would like to at least highlight the most frequently suggested methods for dealing with this tech wannabe—suggestions that ran the full gamut from the extremely diplomatic and politically correct to the downright criminal:
- Document, document, and document. In particular, document all the time you spent cleaning up after the wannabe. Present this documentation to his supervisor and the supervisor of the IT manager.
- Charge the wannabe’s department for the time spent fixing the problems he creates. Create a method for charging IT time to different departments, if one does not already exist.
- Lock the wannabe down by removing all his administrative rights to every system. “If you don't have a policy that covers who should/shouldn't have admin rights, create one and get your boss/VP to approve it,” says Basselgiaba.
- Arrange for the wannabe to work in the IT department for a few days. According to Gperrie, who has used this solution in the past, “After seeing what we did all day and being around us recounting user stories, [our wannabe] seemed to have a new respect for what we did. After this [experiment], he forwarded all requests to our department.”
And, finally, a tongue-in-cheek suggestion from Lee.Paxton:
“If politics fails, I have a taser.”
In addition to methods for dealing with a wannabe, the even more controversial issue of whether his mere existence may be an indication of an inefficient, unresponsive, under-skilled, or self-serving IT department was also discussed at great length. Member Oldefar most diplomatically expressed this view: “IT is that it isn't about us, it’s about the end users. Understand the work environment before creating the technical solution.
- Business objectives drive business requirements.
- Business requirements drive technical objectives.
- Technical objectives drive technical requirements.
- Technical requirements drive technical solutions.
The IT Strategic plan has to fit between steps 2 and 3, or it’s the wrong plan.”
Unfortunately, at the time of this writing, this particular situation still had not been resolved. But we hope to be able to report back to you in a few weeks with the actual—hopefully successful—outcome, based upon your ideas and advice.
The next ethical dilemma: The micromanaging CEO
The new dilemma for this week is a bleak scenario: What happens if the tech wannabe happens to be a micromanaging CEO who will not accept “no” for an answer? Here is this IT manager’s story:
“I am on the verge of despair. I have been the IT manager of a midsize manufacturing company for fifteen years. Over the past few years the demands on my department have increased at an alarming rate, in the space of just six years, we have grown from a one-person shop to a team of five—and still we are doing a poor job of meeting user needs. My primary problem is my boss, the CEO, who has adopted a management style we half-jokingly call ‘management by in-flight magazine.’ It seems that every time he takes a trip, he finds some great new technology in a magazine article that we must implement NOW. To make it even worse, we also have to implement it his way, as if he is now the company’s authority on that particular technology.
“Unfortunately, not only are his proposals completely irrelevant to our business, but they also absorb huge amounts of my department’s time and resources. I have tried to reason with him, but he simply calls me a dinosaur and pulls rank to get his way. I have tried to institute a technology steering committee comprised of the managers from each department, in the hope that together we can pressure him into seeing reason, but no one wants to contradict him in public. And, just to add to the problem, he has recently become intolerant of any downtime, even for routine maintenance. He is of the opinion, based upon some article he misunderstood, that we should be capable of keeping all computer systems available 24/7, even though nothing we run is mission-critical. We have been reduced to the level of actually faking server crashes just to gain some downtime to perform upgrades, install service patches, and so on.”
What would you do?
After reading this scenario, if you have ideas about how a satisfactory resolution might be achieved, send them to us. Don’t hold back, and don't be afraid to be creative. And if you've ever encountered a similar situation, we're particularly interested in hearing the steps you took to reach a resolution.
You can submit your ideas either by e-mail or by posting a discussion item at the end of each column. A week after the publication of a scenario, we'll pull together the most interesting solutions and common themes from the discussion. We will later present them with the situation's actual outcome in a follow-up article. You may continue to add discussion items after the week has elapsed, but to be eligible for inclusion in the follow-up article, your suggestions must be received within a week of the scenario's publication.
In addition to submitting your solutions, you may submit a scenario of your own by sending us e-mail.