All Posts in Policies and Procedures

|In: Organizational Effectiveness|Last Updated:

George Will is catching up to me.

Two weeks ago he caught on to something I covered 21 years prior — that the average American is more affluent by most measures than the wealthiest of historical figures.

Then, last week he wrote about Baumol’s disease a mere 16 years after yours truly wrote about it in this space.

Do you think Mr. Will is mining the KJR archives? Are you? Please do. There’s good stuff in there, if I do say so myself.

In any event, Baumol’s disease is why sometimes you can’t increase productivity no matter what you try. It’s because, to use the classic example, the number of musicians Beethoven needed to play one of his string quartets back when he was composing is exactly the same as the number needed today, when he’s decomposing.

Baumol’s disease is an example of “market failure” — situations where a marketplace fails to efficiently allocate goods and services.

Which has what to do with managing IT?

I’m glad you asked. The answer is, nothing at all, if you’re among the enlightened IT leaders who have rejected what used to be considered best practice: Running an IT organization like a business — like an independent supplier delivering goods and services to its “internal customers.”

But like it or not, sometimes IT is stuck in the role of internal supplier. If you’re among the stuckees, and don’t have a clear path to unsticking yourself, you have little choice but to treat the rest of the enterprise as the market you trade in.

If that’s your situation, it’s worth a bit of your time and attention learning some of the better-known causes of market failure, figuring out whether they might apply to your internal market, and if they do, what you can do to mitigate the effects.

Market Failure Cause #1: Baumol

Since I brought up Dr. Baumol and his disease, it’s worth thinking through how it might apply to IT. It probably doesn’t have much impact on application development, or at least, not yet — most app dev shops have a number of opportunities for improving productivity.

It probably doesn’t apply to IT operations, either: Few have taken full advantage of all opportunities to automate infrastructure management and administration, and that’s before the cloud comes into play.

But business analysts and relationship managers are a different story. A lot of this work is person-to-person, and there’s a limit to how much you can compress conversations without losing the point.

Market Failure Cause #2: Monopolies

Market economies rely on the effects of competition to achieve efficient allocation of goods and services.

But internal IT isn’t supposed to have competitors. In this it’s like modern-day power companies, or perhaps urban cable service providers.

In the world at large, society deals with monopolies by establishing regulatory bodies such as public utilities commissions, which establish rules, regulations, and rates that give consumers roughly the same prices and quality of service they’d get if it was possible to avoid having monopoly providers.

Traditional IT has used much the same approach, setting up IT steering committees to allocate IT services.

It’s possible to avoid this path to unpopularity through the use of charge-backs, also known as transfer pricing. Whoever has budget can use it to buy IT services from the IT service catalog. Which seems much better, except that all this really does is move responsibility for IT resource allocation upstream to the corporate budgeting process, which achieves the near-impossible feat of being even less popular than IT’s governance processes.

IT can de-monopolize itself, though, by encouraging what’s usually called “shadow IT” — information technology implemented without engaging IT’s services at all. This increases the number of information technology providers in the company, creating true competition.

This doesn’t have to become a free-for-all, either, although this characterization comes up just about always when I recommend promoting shadow IT.

What’s needed is what happens in non-monopolized marketplaces. Take, for example, the construction business. There’s plenty of competition, but it isn’t a free-for-all at all. What keeps it all in check is a regulatory apparatus that establishes the rules all builders must adhere to.

IT already has an equivalent regulatory apparatus — its technical architecture function, which establishes the standards to which all production information technology must adhere.

Baumol’s disease and monopolies are only two of many market failures. Email me with your favorites (or, even better, leave a Comment) and next week we’ll pick up where we’re leaving off.

Comments

|In: Leadership|Last Updated:

Business managers who don’t understand the point of diminishing returns quickly become former business managers, discredited by their failure to recognize when its time to stop throwing good money after good.

The point of diminishing returns, also known as the 80/20 rule and, in this space, as the exalted state of good enough, is backed by a significant body of theory built around Vilfredo Federico Damaso Pareto’s century-old insight that many cost/benefit curves are asymptotic, not linear.

Pareto’s critical insight: Just because some of something is good, that doesn’t mean more of it is better.

But sometimes, Pareto’s law turns out to be horribly optimistic. Many cases are like vitamin A, where some is good, but more is highly toxic.

It’s the sweet spot, less-explored but probably more important than Pareto analysis. It’s where the point of diminishing returns turns into the point of impending deterioration. Where Pareto’s investment/benefit curve is asymptotic, the sweet spot sits atop a bell-shaped curve, where stability is to be found at the two extremes but the best results are delivered from the midpoint.

The poster child for sweet spot violation was Neutron Jack Welch’s policy of terminating the bottom 10% of General Electric’s workforce every year.

For the first few years this policy made sense. GE was complacent, and many employees had “retired in place.”

But if we also assume GE did a good job of deciding who its worst performers were, it’s a statistical certainty that after a few years GE’s recruiters found it nearly impossible to track down replacements in sufficient numbers who were (1) as good or better than the employees remaining in GE’s workforce; and (2) willing to work in such a chilling atmosphere.

Second example: process management. Take a cowboy organization — one in which fierce independence reigns and each employee figures out the best way of handling things each and every time situations arise, no matter how common the situations are.

There’s little doubt that figuring out how to handle a situation once and then perfecting how the organization handles it over time will lead to better results than constantly starting from scratch. Which is to say, standardizing the processes and procedures used to deal with common situations generally makes sense.

When starting with chaos, a focus on process leads to performance improvements.

Some organizations, seeing these improvements, figure investing even more in process will deliver even more improvement.

And so they do, but what they end up with instead is a stifling choking bureaucracy in which employees, terrified of the consequences of failing to follow standard operating procedure (SOP), use what little initiative they have left to find the SOP that’s close enough to get by. Does it, or any of the other documented SOPs make even a tiny bit of sense for the situation at hand?

Asking this question is a mode of thinking that’s been excised from the corporate culture. And so, customers, frustrated by such evident unwillingness to do what makes obvious sense, depart for friendlier competitors.

Eventually, sadder but wiser, these organizations will sometimes bring in “bureaucracy busters” to restore at least a semblance of life to things. But sadly, while sadder but wiser, they don’t reach wise enough: They overshoot the sweet spot in the opposite direction, returning to the state of chaos from whence they came. (If you’re interested, see “A matter of gravity,” 4/16/2007 for a more complete account.)

Want another example? Of course you do. Good things come in threes, after all.

Oh, wait. We already explored our third example last week (see “In praise of slack,” KJR, 4/24/2017). It’s the importance of not trying to achieve 100% staff utilization, instead building slack into the company’s project master schedule so that minor delays in completing one project don’t throw the entire schedule into chaos.

The moral of this story goes beyond the importance of recognizing when you’ve reached the point of diminishing returns or a sweet spot, and what to do when you have: for Pareto situations, stop pushing; for a sweet spot, start nudging in the opposite direction.

Most important: When it comes to identifying things to improve and figuring out ways to improve them, have a bag of tricks to draw on, not just a single technique you’ve perfected.

That’s because those whose bag only contains one trick will keep repeating the one trick they have, because of what the cliché doesn’t say but should:

When all you have are thumbs, every hammer looks like a problem.

Comments