All Posts in Office Politics

|In: Leadership|Last Updated:

According to just about every industry consultant I’ve ever known, businesses are supposed to have well-defined processes that move the work along in a series of orderly steps. Those who execute the various steps are fungible — interchangeable, except for the specific skills and knowledge they use to carry out their role in the grand process.

It’s actually more than that: Businesses, many assert, are nothing more than collections of processes — equivalent, perhaps, to a physicist asserting that the universe is nothing more than its energy flows. Matter, in this view, is only important as the stuff energy acts on to demonstrate its presence.

But matter does matter, and the universe, we’re starting to realize, consists of far more than matter and energy: There’s dark matter, dark energy, antigravity (Einstein’s cosmological constant), and virtual particles (which are matter, but only temporarily). Not to mention the additional 6 spatial dimensions beyond length, width, height and time that string theory requires. The universe is, clearly, far stranger than it appears. Not as strange as the average corporation, to be sure, but strange nonetheless.

But I digress.

Viewed from one, narrow angle, businesses are collections of processes. It’s a useful perspective for organizational engineering. It’s dreadfully incomplete, though, when your goal is to actually improve things. That’s because the starting point for an efficient business isn’t the design of efficient processes. That comes second.

What comes first? Trust among the parties who design the process, staff it, and use it. Relationships, to choose a word. Anyone who has been through a successful process redesign and implementation knows this, although many don’t know they know it.

Successful process redesigns involve all stakeholders, or at least representatives of all stakeholder groups. There are three reasons for doing so. The first, least important reason is that every stakeholder group knows something nobody else knows, and unless the process design takes that something into account, it won’t be able to accommodate all of the situations the world will throw at it.

The second, more important reason is to build confidence in the new process on the part of all stakeholders. Without that confidence, everyone will simply do things the old way, because they know it works and have no faith in the newly designed alternative.

The third, most important reason is to build relationships — to build trust on the part of everyone involved in each other. Those who make use of the process have to trust those who staff the process to do their work properly, just as those who staff the process need to trust that those who make use of it won’t bypass it the moment it appears the least bit inconvenient. Those who staff the process also have to trust each other — trust, that is, that all will play their parts properly.

That’s a whole lot of trust for a corporate environment. Is it any wonder one of the most important skills in many corporations is knowing how to bypass the formal processes and procedures, using relationships to “get things done”?

But every time someone bypasses the processes and procedures to get things done they damage the organization a bit. If the processes and procedures are badly designed that might be a good idea: Damaging a mindless bureaucracy is akin to damaging a logjam. Damage isn’t always a bad thing.

Most processes and procedures, however, are appropriate for the situation, simply inconvenient to those who, accustomed to privilege, are looking for inappropriate attention or importance. Each time one of them bypasses the process, it breaks the whole system a little more.

That brings up one of the most difficult challenges faced by any process engineer: Determining whether the existing process really is sufficiently broken that it should be replaced, or whether the problems aren’t with the process, but with the relationships among those who are supposed to use it.

If the problems are with the relationships, redesigning the process will only improve the situation by accident. If the problem does, on the other hand, involve an inefficient process, one of the first places to look when finding ways to streamline the workflow is to eliminate delays created by the need for multiple signatures and approvals — the result, ironically enough, of distrust.

Which is to say, many bad process designs are both the result of a lack of trust, and its cause.

Comments

|In: Leadership|Last Updated:

Take a cat and put it in a box. Add a vial of poison gas, with a valve controlled by the decay of a uranium atom. Close and lock the box. If the atom decays before some set period of time — a random event — the valve opens and the cat dies. Otherwise, it lives.

A physicist named Erwin Schroedinger used this “thought experiment” (the official term is gedankenexperiment if you care) to illustrate a consequence of Heisenberg’s Uncertainty Principle — that until an observer actually looks into the box, the cat is simultaneously alive and dead.

Instead of being locked away with his own poison gas and uranium atom so he could be simultaneously alive and dead until someone looked in on him, Schroedinger received the Nobel Prize. There’s a lesson to be found in this. Maybe it’s that physicists are allowed to be observers, but not cats. Or maybe this is where the its-original-meaning-has-been-forgotten phrase, “Perception is reality” came from.

Taken at face value, this phrase is right up there with “the exception proves the rule” as evidence that if utter nonsense is just repeated often enough, people will accept it anyway. (Ambrose Bierce pointed out that “the exception proves the rule” is simply a bad translation from the Latin, which actually says exceptions probe the rule.)

So for the record: Perception is not reality for at least two reasons. The first is that, as Schroedinger demonstrated, reality is far, far more preposterous than most of us can cope with. The second, more useful when dealing with everyday events, is that since the perceptions of untrained observers rarely have much to do with objective recordings of the same events, perception can only be reality if reality changes as you move from one pair of eyeballs to another. If the world really worked that way, the moment a scientist formulated a hypothesis, every experiment would automatically adjust to confirm it.

Thankfully, it doesn’t happen that way.

What the phrase actually means is that when people express their perceptions, those perceptions are real for them — they are, that is, real perceptions. To give a quasi-historical example, in Columbus’ day most of the world’s populace figured the world was flat, even though the Greeks had demonstrated its roundness long before. At least according to the tale as we learned it in school, Columbus had to deal with the reality that this was their perception as part of selling Queen Isabella on his venture.

Their perceptions, that is, were part of his reality. Luckily for the universe, and more to the point for Columbus and his crew, their perceptions affected objective reality not at all.

How does this affect you as an IT leader? A lot, that’s how.

For example, many CEOs report that IT projects cost too much and take too long. Some CIOs, upon learning that this is the case, immediately flog the project teams to speed things up and cost things down. No matter what anyone says next, our philosopher-CIO will respond, “Perception is reality and that’s the CEO’s perception.”

Talk about your persuasive arguments.

Wiser CIOs will understand the seemingly fine distinction between this and the alternative — that the CEO’s perception is part of IT’s reality. Rather than fixing project teams that aren’t broken, these CIOs will look for ways to adjust CEO perception to more closely match the situations faced by real project teams dealing with the challenging and difficult circumstances that are part of the daily life of an IT organization.

* * *

Speaking of mystifying perceptions, several readers have asked for the full lyrics to Tech Weenies in the Sky, which I find disturbing on several different levels. My initial reaction was to dial 911 to make sure they’re locked away where they can’t hurt themselves or anyone else — maybe in a box with Schroedinger and his cat. But instead I’ll handle this the democratic way (or if you live in a red state, the republican way since I’m an equal-time kind of guy): You get to vote on whether I waste the better part of a KJR with this foolishness.

Here are the rules: You only get to vote once (or at least only once per e-mail address); whichever side casts more votes by April 18th wins; and if the please-publish-the-lyrics contingent can’t muster at least 1% of the total KJR subscriber list, the nays have it by default.

If you’re among the naysaying contingent, for the sake of my professional reputation … Please! Get out the vote!

Comments