Short-term decision-making dominates modern executive decision-making.

It’s a common and frequent criticism. But as the success of Agile application development methodologies in IT has demonstrated, short-term decision-making, in and of itself, isn’t always a problem.

Assuming long-term outcomes, on the other hand … now that’s something that can cause immeasurable grief.

Take, for example, the popular pastime of reorganizing for success.

Before we get started, though, let’s clear out some common confusions, namely, the difference between reorganizations and restructurings, and between both of these and the increasingly popular notion of redefining an organization’s operating model.

Properly used (KJRSpeak for “the way I use these terms”), reorganizations are the legendary RMS Titanic deck chair rearrangements. Reorganizations keep existing workgroups and their responsibilities intact but change the organizational hierarchy they fit into.

The best that can be said for reorganizations is that they can remove or reduce the size of barriers to collaboration among workgroups. What’s usually left unsaid is that for every barrier a reorganization removes, it introduces other barriers that weren’t there before: Reorganizations fix what’s broken by breaking what’s fixed.

On top of which come the hidden costs of everyone keeping their heads down until they figure out the new collection of hidden rules that come with new management to replace the hidden rules imposed by the old management regime.

Even worse: Reorganizations can distress or outright kill the pursuit of important business opportunities, because a new organizational hierarchy often means the business sponsor for a given initiative, who cared deeply and profoundly about its success, has new responsibilities for which the initiative is utterly irrelevant.

Likewise, the newly logical sponsor for the initiative in question is likely to have very different ideas about what’s worth investing in and what isn’t.

Restructurings are more profound than reorganizations. At a minimum, in addition to changing the organizational hierarchy and the position of workgroups in it, they also reassign some responsibilities among the existing workgroups.

Restructurings can also eliminate some workgroups while introducing others, and in general try to change how work gets done, with the new workgroups and hierarchy designed to facilitate the process changes that are the point of the exercise.

But along the way to achieving the hoped for improvements to organizational effectiveness come all the short-term losses associated with reorganizations, along with the additional short-term losses that come from changing how work gets done: Everyone involved has to unlearn what they knew in order to learn how they’re supposed to do things now.

Operating model changes are even more thoroughgoing. They recognize that process changes take more than process and organizational designs. They include the entire internal business architecture — people, processes, technology, structure, and culture.

That’s a good thing, because all of these need to be consistent with each other for a new way of getting things done to work.

It’s a bad thing because the more that has to change, the more likely it is that, beyond the cumulative effectiveness losses that accompany restructurings, operating model changes include two major additional concerns: (1) we didn’t think of everything the new operating model has to address; and (2) one or more managers or employee groups involved in the change might get some of it wrong.

Understand, some situations do call for reorganizations, restructurings, or new operating models.

But … (you knew “but” was about to happen, didn’t you?)

In The Cognitive Enterprise, Scott Lee and I introduced the “Stay-the-same / change” ratio — a metric that compares how long an organization takes to make a change to the length of time the change will remain relevant, and the organization can accumulate its benefits.

The ratio matters whenever the time needed to achieve a change is incompressible, while the time available for harvesting their results, is shrinking. Reorganizations, restructurings, and new operating models fall into this category.

Now metrics have their limits, and that includes any and all attempts to quantify the overall costs and the business benefits to be had from any organizational change.

That doesn’t exempt managers from thinking in these terms. In the absence of quantification the management team planning the change should discuss these questions:

  • How disruptive will the change be to our current level of effectiveness?
  • How long will the organization need to recover from the change?
  • Will our long-term gain in overall effectiveness be an order or magnitude or more, or an increment?

And then there’s the most important question: Given our history, how long do we expect the change to last before we reorganize again?

A quick history of the United States:

If you’re running an IT organization, you’re probably coping and having a hard time doing it. IT has evolved from supporting core accounting, to all business functions, to PC-using autonomous end-users; to external, paying customers on the company’s website; to mobile apps, the company’s social media presence, its data warehouse, big-data storage and analytics … all while combatting an increasingly sophisticated and well-funded community of cyber attackers.

What hasn’t evolved is IT’s operating model — a description of the IT organization’s various moving parts and how they’re supposed to come together so the company gets the information technology it needs.

Your average, everyday CIO is trying to keep everything together applying disco-era “best practices” to the age of All of the Above.

Defining a complete IT All-of-the-Above operating model is beyond this week’s ambitions. Let’s start with something easier — just the piece that deals with the ever-accelerating flow of new technologies IT really ought to know about before any of its business collaborators within the enterprise take notice.

We’ve seen this movie before. PCs hit the enterprise and IT had no idea what to do about them. So it ignored them, which was probably best, as PCs unleashed a torrent of creativity throughout the world of business (assuming, of course, that torrents can be put on leashes in the first place). Had IT insisted on applying its disco-age governance practices, to PCs, all manner of newly automated business processes and practices would most probably still be managed using pencils and ledger sheets today.

Eventually, when PCs were sufficiently ubiquitous, IT got control of them, incorporating them into the enterprise technical architecture and developing the various administrative and security practices needed to keep the company’s various compliance enforcers happy, to the extent compliance enforcers are ever happy.

Then the World Wide Web made the Internet accessible to your average everyday corporate citizen, and IT had no idea what to do about it, either. So it did its best to ignore the web, resulting in another creativity torrent that had also presumably been subjected to IT’s leash laws.

It was a near point-for-point replay.

Now … make a list of every Digital and Gartner Hype Cycle technology you can think of, and ask yourself how IT has changed its operating model to prevent more ignore-and-coopt replays.

This is, it’s important to note, quite a different question from the ones that usually blindside CIOs: “What’s your x strategy?” where x is a specific currently hyped technology.

This is how most businesses and IT shops handle such things. But as COUNT(x) steadily increases, it’s understandable that your average CIO will acquire an increasingly bewildered visage, culminating in the entirely understandable decision to move the family to Vermont to grow cannabis in bulk while embracing a more bucolic lifestyle.

The view from here: Take a step back and solve the problem once instead of over and over. Establish a New Technologies Office. Its responsibilities:

  • Maintain a shortlist of promising new technologies — not promising in general, promising for your specific business.
  • Perform impact analyses for each shortlist technology and keep them current, taking into account your industry, marketplace and position in it, brand and customer communication strategy, products and product strategies, and so on. Include a forecast of when each technology will be ripe for use.
  • For each technology expected to be ripe within a year, develop an incubation and integration plan that includes first-business-use candidates and business cases, the logical IT (or, at times, non-IT) organizational home, and a TOWS impact analysis (threats, opportunities, weaknesses, strengths). Submit it to the project governance process.

Who should staff your new New Technologies Office? Make it for internal candidates only, and ask one question in your interviews: “What industry publications do you read on a regular basis?”

Qualified candidates will have an answer. Sadly, they’ll be in the minority. Most candidates don’t read.

They’re part of the problem you’re trying to solve.