All Posts in Policies and Procedures

|In: Career Management|Last Updated:

Once upon a time there was a queen bee.

She enjoyed talking to her beekeeper, who, fortunately enough, enjoyed listening to her. She was fortunate, that is, because the beekeeper considered himself a poor conversationalist, and so was happy not to have to share the burden of finding interesting topics to talk about.

Queen Bee

And besides, there are lots of talking beekeepers around, but not so many talking bees, so he figured he’d take advantage of the opportunity while it lasted.

The beekeeper was in this way wise, but he wasn’t very bright. The evidence: The queen’s favorite topic was the land of milk and honey, and how she was going to lead the beekeeper there.

Finally the day came when the beekeeper couldn’t stand it anymore. “Let’s go!” he said to the queen, flushed with the enthusiasm that comes from a vision of a better tomorrow. “I don’t want to wait another day!”

So off they went to find the land of milk and honey.

Leaving behind a hive full of honey. And full of the worker bees who made the honey. Also all of the ingredients needed to make a new queen for the hive.

The moral of the story is, don’t be a queen bee CIO.

I ran across one of these characters not all that long ago. I had four one-hour conversations with him over the span of a couple of months. He was a visionary, talking in glowing terms about how the brilliant information technology he’d recently brought in and the new and even more brilliant information technology he was going to bring in soon that would transform the company.

Remarkably, in all of the time we spent together he never once mentioned anything about the department he “led,” what his plans for it were, where it needed to improve, or where it already excelled.

Unremarkably, nobody in the entire IT department could make a decision of any kind, with the possible exception of where to have lunch.

What causes an IT manager to become a queen bee? That’s for psychologists to diagnose, not workaday IT commentators. Or perhaps for budding ethologists. We could, I suppose, get them together to resurrect the pointless nature vs nurture debate, even though it was long ago resolved.

Bee it nature, nurture, or a combination of the two really doesn’t matter. A queen bee sits at the top of your IT hive, and you have to cope with her. Or him; unlike honey bee queens, both male and female CIOs can wear an apian crown.

So what you do if you report up to a queen bee CIO?

You could feed her/him royal jelly (pushing the metaphor to its limits, this of course means mastering the fine art of sucking up). This can work in the short term … queen bees do love hearing how brilliant they are … but it’s a bad habit to develop. Once this becomes your normal you’ll lose the habit of initiative and decisiveness that help you succeed in healthier environments.

And so you’ll find yourself seeking out queen bees to work for.

No thanks.

Then there’s the obvious solution: Leave. It’s the best general-purpose advice there is no matter which sort of bad manager you report to, because bad managers aren’t going to change — the attitudes and behavior that make them a bad manager are what, in their eyes, got them to where they are today.

So by all means, explore the world of opportunities that surrounds you.

But as you do, consider a different sort of departure.

As has been pointed out in this space from time to time, wise CIOs are starting to encourage what’s commonly called shadow IT — information technology that happens outside IT’s organizational boundaries.

Unwise CIOs still try to stomp it out, but fail.

Therein lies an opening you can exploit.

If there’s one thing you can be certain of, it’s that your corporate beekeepers will soon tire of the queen bee CIO’s tales of milk and honey. They want their milk and honey right now.

And if IT can’t deliver it, well, maybe shadow IT can.

With your help.

You will, of course, need to tread cautiously. But there’s a good chance your company has a director or three who have the budget and don’t care about obeying the IT governance process that’s been stymying them as they try to turn their own visions into business reality.

You know IT. You know the business (you do, don’t you?).

With finesse, you can be the person who actually does make IT happen.

Not a bad place to be when the CEO kicks the queen bee CIO out of the hive.

Comments

|In: Industry Commentary|Last Updated:

We’ve been talking about market failure and how it applies to IT departments that are “run like a business” that sells information technology to its “internal customers.”

When it comes to causes of market failure, monopolies might be the most obvious, but the Tragedy of the Commons is the monster.

Discovered by William Forster Lloyd in 1833 and popularized by Garrett Hardin a century and a half later, the tragedy of the commons is what happens when someone with access to a shared resource gains an economic advantage by using as much of it as they can. It happens because everyone will do the same, collectively wreck the commons they all rely on.

Sadly, most of the easily recognized examples are political or politicized, as in the case of The Cuyahoga River, which runs through Cleveland. It was, in the 1960s, a waste disposal resource. Because it was both shared and unregulated … that is, everyone relied on market forces to allocate it fairly and efficiently … any company that wanted to could and did dump as much as they wanted into it.

Not only was there no economic incentive to avoid overusing the Cuyahoga, the opposite was true. For every industry in Cleveland, dumping their pollutants into the river was cheaper than any other waste disposal alternative.

As a result, the Cuyahoga River became flammable, leading to one of Randy Newman’s better songs and the birth of the Environmental Protection Agency.

Not to mention how the fire department probably responded when the call came in. I see Bob Newhart, or maybe Lily Tomlin plays the part of the fire chief: “What’s on fire?” A snort. “So what do you want us to do — aim our firehoses at it?”

But you’re leading IT, not the Cleveland fire department and your commons isn’t a river, it’s the collective IT architecture.

If you’re a monopoly provider, you can control access and use because it’s your commons. You own it. You don’t let anyone else make any changes to it. You rent its capabilities to your internal customers, with rent payments coming in the form of chargebacks.

But then you’re a monopoly provider, which makes you a cause of IT market failure — see “Market failures, volume 1,” KJR, 5/22/2017).

You could open the technical architecture to all comers, resulting in shadow IT gone wild. It would be like a housing development where someone buys a lot and erects a 20 story hotel there because land and property taxes are lower.

And then, because the one hotel is profitable, other hotel chains do the same thing, all connecting their buildings to water and sewer systems designed for a collection of single family houses.

This doesn’t happen in the suburbs because municipalities have zoning laws, regulating the use of their shared services.

But, as The Economist pointed out a long time ago, analogies aren’t the same thing as being the same thing. IT isn’t a municipality, so I’m not sure there’s a lot a CIO can learn by exploring the differences between how, say, Washington DC, Lake Forest, Illinois, and Beaver Bay, Minnesota manage their respective commons.

Instead: If you must run IT as a business, don’t want to be a monopoly, and still want to preserve the integrity of your company’s technical architecture, here are a three steps you can take that let the business gain the considerable advantages to be had from shadow IT, without it trashing the IT commons.

  1. Establish enterprise architecture governance: Returning to the urban metaphor, standards are IT’s zoning laws and enterprise architecture governance is how IT sets its standards. Shadow IT is just fine and dandy so long as it’s in the right zones.
  2. Culture is the new governance: As pointed out in this space and in The Cognitive Enterprise, there’s nothing in an organization so slow that a committee can’t brake it even more. So while you need zoning laws and zones, their enforcement should be 90% cultural — defined as “how we do things around here” — and only 10% through formal committee-driven reviews.
  3. Create a Superfund: If you’re running IT as a business and some shadow-IT-based application messes up your technical architecture, whoever made the mess should pay you to clean it up. You’re already charging back. This is just another line item.

Not that I’m advocating running IT like a business. But if you’re going to do it, you might as well prevent market failures as you do.

Comments