The primary function of a responsible IT shop isn’t to make people happy – it’s to help the company do business. Business Technology’s resident U.S. blogger Keil Hubert shares an American preacher’s column that fits this idea exactly, if you substitute the word ‘user’ for ‘parishioner’.
My mate Michael [1] sent me a link this morning to a priest’s blog post that I’d swear was originally posted as an IT column. The author, Dr Derek Penwell, is (according to his online bio) an ‘author, editor, speaker and activist. … [and] the senior minister of Douglass Boulevard Christian Church (Disciples of Christ) in Louisville, Ky., and [also] a lecturer at the University of Louisville in Religious Studies and Humanities.’ He certainly sounds like a priest, and I have no reason to doubt his credentials. Still, after reading his piece, I submit that he was (consciously or not) channeling every IT manager ever when he quipped that the old adage of ‘The Parishioner Is Always Right’ is dead wrong, and is also bad for business. The good doctor clearly meant church business in his essay, but his arguments are every bit as relevant for us business and tech management types.
Take a moment and go read Dr Penwell’s piece. It won’t take long. I’ll wait.
* * *
See what I mean? I enjoyed it, too. Right. Moving on:
I’ve run headlong into that ‘angry user’ dynamic more times than I can count, and darned near every iteration of the phenomena has run (for me) about the same as the good doctor’s ‘really REALLY upset’ parishioner story. One of the users decides to take umbrage with a technology standard, business process, or security protocol that I put into effect in my role as head-of-systems-and-networks, and demanded that I roll it back. As per the good doctor’s example, I usually told the complainer to get bent and get the hell out of my building. Not always, mind, but often enough that word got around: don’t try and bully the techs. They’re not tolerating any of your guff, especially if you’re yelling or grandstanding.
Here’s a fine example: many years ago, I decided to change our standard company laptop from a Dell Inspirion (my predecessor’s preferred brand and model) to a Sony VAIO. My systems lifecycle folks spent a few months running experiments and crafting the business case, and I approved the change recommendation for the next mass purchase of replacement laptops. We had about a hundred machines deployed throughout the organization when one of the junior department managers threw his toys out of the allegorical pram when I denied his exceptional request to go buy a batch of Dells instead of what we’d standardized on.
This insolent git – we’ll call him ‘Bob’ [2] – came by my office and petulantly demanded that I waive the company’s laptop purchasing standard so that he could get what he wanted. First off, he made an awful decision in his choice of interpersonal approach (I don’t tolerate threats, and I absolutely loathe bullies). Second off, this fellow had no actual business justification for his request; he just wanted his Dells. I asked Bob why he felt that he couldn’t get his job done with the company standard, and his only response was ‘I’ve always had good luck with Dells.’ Whoop-ti-freaking-do.
What Bob didn’t know was that the change in standards had been a long and contentious process inside the department. The lifecycle management team and the PC maintenance team were at each other’s throats over it. As the director, I had to make a decision that balanced all of the operational, economic, and logistical factors that the users couldn’t see, like Mean-Time-Between-Failures, availability of tech support from the vendor, response times for parts, and so on. For example, Dell was going through a bad patch at the time, and had a problem with shipping laptops that had been built with defective parts. Yes, it was a supplier problem and not an assembler problem, but we had to replace a laptop with a bad hard drive about every three weeks.
It was painfully clear after a frustrating year that we had to get off of Dell as a laptop supplier for a while, at least until their quality control got back up to par. It wasn’t desirable, but we couldn’t afford to have 10% or more of our company’s laptops sitting idle on a shelf in the repair bay for months on end. So, we needed a new provider. The lifecycle team looked at a half-dozen competing brands, and chose the Sony based on common factors like standard features, weight, sturdiness, and so on, as well as really obscure factors like the availability of easily swap-able hard drives. [3]
To be clear, there were disadvantages to our selection that we (rightly) suspected would cause us problems over the systems’ lifecycle. In the USA, the VAIOs were sold as consumer products rather than business machines, so repair parts were bloody difficult to acquire. Some could only be ordered from Japan, and only after you manually translated some Katakana to get the right part numbers.
On the balance, though, the new standard was a good decision for the company. Was it perfect? No it wasn’t, but it achieved the IT department’s operational objectives at the time. The Sonys lasted longer and needed less technical support than the models that they replaced. That mitigated our repair shop’s inherent defects, and reduced the Help Desk’s workload as well so that more users could be serviced with the same resources. The program exceeded its lifespan projections, and, in the end, that counted as a ‘win’ for an IT group. [4]
None of these factors were evident to Bob, who wasn’t part of our department and never made any effort to understand what we were dealing with. Despite that gulf, Bob was incensed that he hadn’t been consulted on our decision – and that we didn’t twist ourselves into pretzels to satisfy his whims when he wanted something different. What Bob never understood was that we did consult with our more technologically savvy users, and we did go out of our way to accommodate special requests from the users that worked with us (unlike Bob, who worked against us out of sheer spite). Bob was neither savvy nor cooperative. If he’d at least come to us with a legitimate business need, we would have gritted our teeth and tried to work something out. But … that wasn’t Bob’s way.
As IT people, we have to strike a difficult balance between what we can afford, what we can support, and what people want. Even back then, our IT folks were happy to ‘pull back the curtain’ and educate our users on what we did and why we did it. Our project management grid was tacked up on the wall where every user could review it at their leisure, as was our tech support budget plan. We offered users the opportunity to come spend a day interning with the department so that they could see how everything worked up close and personal. Anyone with half an ounce of sense came into alignment with our corporate decisions once they understood the decision making process that we’d had to slog through to get there. More importantly, when someone brought us a better way of doing things, we embraced it.
Those factors never mattered to Bob, since his motives had nothing whatsoever to do with the good of the company. We found out (after buying Bob’s secretary a few rounds at the local) that Bob’s hidden objective was to make a name for himself in his division. He’d concocted a plan to bully the various user support agencies (e.g., IT, HR, payroll, et al) into granting him special concessions that weren’t available to anyone else. Once he could go back to his bosses and show them that he could get the results that they couldn’t, they’d give him a big pay rise and a promotion. It was a purely selfish plot, and it started an interdepartmental row that carried on for years. Bob was a prat, no two ways about it. His quest for glory wound up souring the working relationships of dozens of people for a very, very long time.
Some of my staff members at the time were concerned about the conflict we’d had with Bob and his machinations. I told my folks much of what the good doctor pointed out in his recent column. To paraphrase:
- Adopting a policy of giving unhappy users whatever they want just to make them happy sours the IT staff. Why have standards and practices if you’re going to abandon them?
- Giving in to uncooperative users emboldens and legitimizes all of the self-absorbed users.
- The bad attitude of a few users sours the relationship between all of the users and most everyone in the IT department.
- When you roll over and give in to an obnoxious user, it reduces the quality of services for all users – usually because service staff members become demoralized.
- Often, the obnoxious user is just plain wrong and should be dismissed as such.
I’d like to add one additional element that the good doctor probably should have mentioned:
- When you’re wrong, ‘fess up about it immediately and take your licks. You live and die by your credibility.
To be clear, I’m not suggesting that IT professionals should adopt a sociopathic BOFHs approach as a customer service policy. Being a bully is wrong no matter where you are in the enterprise.Instead, what I’m saying is that it’s both wrong and dangerously counterproductive to declare that ‘the user is always right’ and then act on that ludicrous assumption. I think that’s a silly notion that needs to be expunged from the workplace.
Instead, let’s try this: any given user at any given might have something useful to contribute. Therefore, it’s a prudent idea to politely hear out every user that approaches you with a polite and respectful demeanor, so long as they’re willing to discuss their ideas in an adult fashion. That’s the general policy that I implemented as an IT director, and it worked wonderfully for my crew. The users that knew what they were talking about and behaved well were warmly incorporated into the IT fold and were regularly consulted. People that didn’t know what they were talking about, but who were courteous and willing to learn, were likewise brought aboard – where we then trained them so that they could better contribute to the discussion. At the same time, we had zero tolerance for bullies, no matter how well educated they might have been, or how much power they wielded by virtue of their position in the hierarchy.
The approach that made us successful over the long run was to treat each encounter as a fresh start: if you came at us with a sack full of bad attitude, on Tuesday, we’d throw you out with a drubbing on Tuesday. If you came back on Wednesday with newfound courtesy and a willingness to discuss things rationally, we’d welcome you in and cheerfully address your concerns. The user was not always right. The user was, however, always treated in the manner that they deserved to be treated on a case-by-case basis. When they were right and courteous, they were treasured.
I learned to always adopt that same approach when dealing with other service providers, whether inside the company or out. Start off treating people the way you’d prefer to be treated yourself, and they’ll usually do right by you in return. I’d swear that I’ve heard that ideasuggested somewhere before …
The other half of our interdepartmental collaborative strategy came down to avoid taking strong positions on topics when we didn’t actually know what we were talking about. It’s quite all right to ask questions about why things are done and to make suggestions – provided you listen to what the more educated or more experienced person in the conversation has to say on the subject and then factor that into your evolving mental model. That concept works in both directions: I don’t know how to fix a transmission, so I’m not about to tell a tranny tech what spanners she needs to fix fourth gear on a combine harvester. Likewise, I’ll be happy to leverage my industrial computing experience to improve the tranny tech’s daily workflow, but I’m not about to let her dictate how my shop supports her part of the larger operation. A little mutual respect makes for a strong, productive, trouble-free working relationship.
[1] Michael’s a real name. Yes, I normally anonymize everyone in my column as ‘Bob.’ I make a few exceptions for people that don’t mind being identified.
[2] Were you concerned about having no ‘Bob’ in this column? Gotcha covered. I know a lot of Bobs.
[3] The Sony VAIOs had removable hard drive bays, which allowed us to keep a small stock of imaged hard drives at the Help Desk. When a customer had a drive corruption problem, it took less than a minute to turn the user’s machine into a ‘new’ computer. That greatly reduced down time for customers, and freed up techs to work on other problem machines.
[4] Over the years, we used large quantities of Apples, Dells, Compaqs, HPs, IBMs, Sonys, Toshibas, and a bunch of third-party brands. Looking back, I can say with confidence that none of the models that we bought could ever be considered ‘perfect’ for the business. Each had their strengths and weaknesses. Every procurement decision involved a trade-off, and we were always left disappointed by something. That’s why good lifecycle managers tend to be tetchy fellows – they can’t please everyone, ever.
POC is Keil Hubert, keil.hubert@gmail.com
Follow him on twitter at @keilhubert.
You can buy his books on IT leadership and IT interviewing at the Amazon Kindle Store.
Keil Hubert is a retired U.S. Air Force ‘Cyberspace Operations’ officer, with over ten years of military command experience. He currently consults on business, security and technology issues in Texas. He’s built dot-com start-ups for KPMG Consulting, created an in-house consulting practice for Yahoo!, and helped to launch four small businesses (including his own).
Keil’s experience creating and leading IT teams in the defense, healthcare, media, government and non-profit sectors has afforded him an eclectic perspective on the integration of business needs, technical services and creative employee development… This serves him well as Business Technology’s resident U.S. blogger.
