All Posts in Policies and Procedures

|In: Policies and Procedures|Last Updated:

Including Keep the Joint Running and its predecessors – InfoWorld’s IS Survival Guide and Advice Line – I’ve been sharing thoughts and opinions for more than 26 years.

When I started, I wanted people to read what I had to say and think, “Wow!” Now, I’m gratified if they think, “A column a week for 26 years? Wow!”

Quantity seems to have gradually overtaken excellence as my most crucial KPI.

Meanwhile, I’m more likely to remember having written about a subject than you’re likely to remember having read about it for, I think, obvious reasons. As a result I sometimes obsess about avoiding repetition – that if I’d written about a subject in 1998 you’ll feel cheated if I write about the same subject here in 2023.

Which brings us to this week’s subject: “Shadow IT,” also known as “Rogue IT,” “DYI IT,” and, if you want to encourage Gartner in its perennial game of claiming concept ownership by attaching snappy new names to unoriginal concepts, “Citizen Developer.”

Or, you could use the handle my co-author Dave Kaiser and I introduced in There’s No Such Thing as an IT Project, as a contrast to Shadow IT, namely, “Illuminated IT.”

As with so many ideas in life, illuminated IT comes with trade-offs, making it sadly easy to succumb to confirmation bias when deciding whether to encourage it or try to stamp it out.

The stamp-it-out logic

End-users aren’t trained developers. They might fall short when it comes to application architecture, testing, or security. And if or when something goes wrong, IT will have to pick up the pieces.

Not only that, but when the end-user developer “calls in rich,” IT will be called in to support the mess the end-user developer left behind.

The philately-free logic (okay, it’s a stretch)

DIY development increases IT’s bandwidth – not once, but in two complementary ways.

The first is the obvious one: a DIY developer still counts as a developer. Maybe not an ideal developer, but I’ll bet not all of the developers housed within the IT organization are ideal ones either.

The less obvious one? For the most part, IT development, along with IT “development” (when IT configures and integrates commercial off-the-shelf software), involves a business analyst here and there. DIY IT does not.

Related: No more arguments about whether what IT delivers is what the business needs.

The best of both worlds

Once IT jettisons its protectionist instincts, and once business users jettison their IT-distrust instincts, getting the best of both worlds isn’t particularly complicated:

1. Encourage using what you already have. It isn’t uncommon that an application suite you already license provides the additional functionality the business needs. The formula for success: Inform, train, follow up.

2. Encourage COTS. If some application provider licenses a solution that does what business users need, it reduces the risk of losing support due to the end-user developer finding something else to do.

3. Establish platform standards. Whether it’s Excel, Access, or a “no-code/low-code” cloud-based alternative, setting one of these as the supported and recommended development environment reduces IT’s support burden. Once you’ve established the standard, offer training and support as needed.

4. Inventory. Ask business users to provide three layers of documentation for anything they develop. Layer 1 is the application’s title (“MS Word” is an application title). Layer 2 is the application’s headline (“General-purpose word-processing application” is an application headline. Layer 3 is a no-more-than-three sentence explanation of what the application does. With this inventory, should IT have to swoop in to save the day there’s a good starting point to swoop from.

5. Establish a Mentor Program, aka a Power Users Cool Kids Club. How to do this? See “Mentors are your friends. Be nice to your friends,” which first appeared in InfoWorld September 23, 1996.

Bob’s last word: For far too long, IT’s “best practice” on DIY development has been “We won’t do it for you and won’t let you do it for yourself.

Without a doubt, DIY development comes with some risks attached. But then, DIY prevention comes with risks of its own, namely, that various parts of the business will forgo important opportunities for technology-enabled improvements in effectiveness, all because a focus on what might go wrong blinds decision-makers to what might go right.

Now on CIO.com: “The 7 venial sins of IT management.” What it’s about: Seven mistakes to worry about that probably aren’t on your to-don’t list already.

Comments

|In: Business Ethics|Last Updated:

Mostly, when you work with someone for any length of time at all you can figure out if they were born with the Sense-o’-Humor gene.

Except for one person I worked with who had a sense of humor some days but not all days. We tried to get him to wear a badge – red on one side, green on the other – but he didn’t get the joke.

I rarely mind if someone doesn’t laugh when I crack wise. When they don’t know I’m cracking wise? That’s more of a challenge, especially as “I was just kidding!” has become the go-to excuse for anyone and everyone who’s been just plain offensive.

Meanwhile, a long-time subscriber writes of his recent trip to HR, the result of his having shown, at a company social event, the usual string of photos of attendees having fun and goofing around. What triggered the trip to HR: A slide showing one of the male attendees engaging in a minor bit of what he considered to be a harmless display of cross-dressing (women’s lingerie worn outside his clothing), which another attendee found offensive. To which, a few thoughts, musings, and concerns, starting with:

What offended the complainer? If they were offended by the cross-dressing itself, they’re the one who needs some HR coaching about tolerance. The “T” in “LGBTQ” might not stand for “transvestite,” but intolerance toward transvestites shouldn’t be acceptable.

The complaint might have been that the offender’s fashion statement ridiculed transvestites. That might hold water if this had been a repeat offense coupled with his having made derogatory statements about transvestites in general, or about a specific transvestite in particular. That wasn’t the case here.

My best guess is that HR decided to play it as safe as possible. Asking “What specifically did you find offensive about this?” could be counted as failing to deal with a harassing environment, and extracting a promise from the offender to never cross-dress at a company function again would seem to be a harmless way to close the matter and get on with business.

Except that extracting that same promise from anyone and everyone who cross-dresses at a company event would create an unwelcoming and harassing environment to transvestite employees.

Do all complaints require HR action? We are, to mix metaphors so badly you might want to complain to HR, on the knife edge of a pendulum you might think has swung too far. If businesses can only work when joking, joshing, and goofing around are banned because someone might find a way to take offense, that’s one more step in the evolution of employee/employee relationships, from interpersonal trust-based collaboration to interacting purely on the transactional basis of inputs and outputs.

On the other hand, as we’ve been discovering over the past several years, there’s no shortage of bigotry here in the U.S. of A. Should HR tell everyone who’s been offended by an overtly and expressively bigoted colleague to grow a thicker skin? That’s one more step on a different slippery slope – the one in which anger and hostility become the dominant characteristics of the business culture.

Bob’s last word: The problem managers find themselves dealing with when it comes to workplace harassment is that offensiveness, like its polar opposite, beauty, is in the eye (or ears) of the beholder.

My personal preference, which goes nowhere because it can’t, would be for the company policies and procedures manual to prescribe the process to be followed by anyone who’s been offended by anyone else:

Step 1: Inform the offender that you were offended, explain why, and ask that the offender not become a repeat offender.

Step 2a: If the offender acknowledges the legitimacy of the complaint and agrees to not engage in similar behavior in the future, case closed.

Step 2b: If the offender fails to acknowledge the legitimacy of the complaint, and repeats the offense, that’s when the person who’s been offended should contact HR, which would lay out the company’s you’re-way-beyond-our-zero-tolerance-for-bigotry-and-harassment policy.

But this isn’t going to happen – it would result in too much tangible risk, for rewards that are too intangible to warrant the risk.

The unsatisfactory alternative, which I unhappily recommend, is that we all need to be patient as the pendulum swings back and forth a few more times.

Bob’s sales pitch: Did you like what you read this week? Consider forwarding it to your HR director with my compliments. HR can’t be any happier about the numbification of the workforce than we are, and the more companies that are willing to try out alternative solutions the better.

If you do, let me know how it goes.

Now on CIO.com: Now on CIO.com: “Bad metrics are worse than no metrics,” and especially why SMART goals just might be worse than no goals at all.

Comments