All Posts in Office Politics

|In: Career Management|Last Updated:

News flash!

In another case of psychologists proving what we’ve long suspected, Justin Kruger and David Dunning, publishing in the Journal of Personality and Social Psychology, demonstrated the inverse correlation between actual ability and self-assessment.

The better employees think they are, the worse they actually are and vice versa.

Armed with this little factoid, I expect battalions of mediocre programmers to immediately try to improve their ability to write good code by adding humility to their conversation. While the humility, however insincere, will be a welcome change, it will start a tiresome variant of the decrepit “You only thought I knew that you knew that I knew that you knew” gag.

But I digress.

I just read another version of the “CIOs need to know the business” article. I think there’s just one article on the subject, and when a writer is feeling tired he pulls it out, shuffles some paragraphs around, e-mails it in, and goes back to sleep. They’re all the same, really. They make the hoary point that businesses don’t want technology for technology’s sake — technology must serve a business need, and successful CIOs will embrace this concept.

Some insights are more startling than others, I guess. But before we go on, let’s all hold hands and chant together: “Yes, CIOs must know the business, and never propose technology for technology’s sake.” Maybe if we say it loud and proud a few times, everyone in earshot will understand that we’ve fully grasped this concept, and we can all move on to the next one.

The next one, made many times in this space, is that “knowing the business” doesn’t begin and end with abstract notions like strategies and business models. The most important part of knowing the business is knowing the interests, hot-buttons (and cold-buttons), pet programs and pet peeves of every important decision-maker in the company. At least half of an average CIO’s time is spent selling. It’s internal selling … to the board of directors, CEO, senior executives, middle managers … but selling nonetheless.

If you don’t like the idea of having to sell internally, find a different word that describes the process of persuading others to adopt your concepts, in the process adding money to your budget.

If it looks, waddles, and quacks like a duck, it’s a duck. If it looks, smells, and tastes like selling, it’s selling.

To sell effectively, you need to understand your prospects on an empathic level. You need to understand the business, formally, politically, and personally.

Why, oh why do so many seemingly sensible people jump from here to the ridiculous notion that the CIO can delegate the “understanding technology” part of running IS to subordinates? Would anyone reach a similar conclusion down the hall a few doors, and figure the CFO doesn’t need to understand accounting, just “the business”?

Of course not. Of course, they’d probably reach the right conclusion for the wrong reason, explaining that at the end of the day … or at least the fiscal year … the money is the business. Robert McNamara, overconfident of his ability (sound familiar?) due to his business resume, used a similar thought process in pursuit of victory in Vietnam, running a metrics-driven war in which relative body counts (profits) mattered more than the formulation and execution of strategy and tactics.

CFOs need to understand finance and accounting because they run that part of the business and they need to understand the discipline. CIOs need to understand information technology because that’s what they’re responsible for. This isn’t a complex concept, nor should it be controversial.

Go back to the idea that CIOs spend a lot of their time selling. What do really great sales people do? They paint a persuasive vision of how great your world will be once you’ve incorporated what they’re selling into it.

What’s the first step? Understand what you’re selling. In the case of a CIOs, that’s information technology. Without that knowledge, no matter how good you are at step two — understanding your prospects’ world — you’ll have no way of progressing to step three: Putting that knowledge and your product together.

Comments

|In: Industry Commentary|Last Updated:

Definitions get me into a lot of trouble.

Early in my career, I was asked to perform a “feasibility study.”

“What’s the subject?” I asked.

“An inventory system,” my boss answered.

“OK, it’s feasible,” I told him. “I guarantee it. Lots of other companies keep track of their inventories on computers, so it must be.”

More patient than most of the managers I’ve reported to in my career, he explained to me that in IS, a feasibility study doesn’t determine whether something is feasible. It determines whether it’s a good idea or not.

It turned out to be a good idea (a tremendous surprise), so next we analyzed requirements. You know what’s coming: A senior analyst asked me if the requirements were before or after the negotiation.

“What negotiation?” I asked. “These are requirements. They’re required.”

This is how I learned that we do feasibility studies and requirements analyses in part to test the validity of the requests we receive. The process would be unnecessary if we believed end-users were our customers.

At the supermarket, nobody says to a customer, “Those fried pork rinds aren’t an acceptable part of your diet!” or, “Prove you need that ice cream!” At the supermarket, wanting something and being able to pay for it are all that matter.

In IS we used to view end-users as our (internal) customers, and we figured the relationship followed from the role: If they’re our customers, our job is (as Tom Peters would say) to delight them.

End-users aren’t our customers, though. They’re our consumers – they consume our products and services but don’t make buying decisions about them. But does that really change anything, or is it just a useless distinction?

It does change things. “Customer” defines both a role and a relationship. What does “consumer” say about a relationship? Nothing. Or at best, very little.

“Consumer” defines only a role, and in the context of organizational design, role is a process concept, whereas relationship is a cultural one. (Definitions: Processes describe the steps employees follow to accomplish a result. Culture describes their attitudes and the behavior they exhibit in response to their environment.)

What should the relationship between IS and the rest of the business look like? This is one of the most continuously controversial issues in our industry. When you view it as a clash between process design and cultural cues, the reason our discussions are jumbled is more clear.

Defining the rest of the business as our consumers frees us to define whatever relationship works the best. As with my inventory system, every highly successful result I’ve ever seen in IS has been the result of an open collaboration between IS and end-users, with authority shared and the dividing line between the two groups obliterated.

Yet many of my colleagues and much of the correspondence I receive on the subject still advocate a hard dividing line between the two groups, with formally documented “requirements” defined by a small group of end-users and the authority for “technical” decisions reserved for IS.

Of course, purely technical decisions are few and far between these days. What brand of NIC should you buy? OK, that’s a technical decision, but even something as seemingly technical as choosing a server OS places constraints on business choice. Or, looking at the opposite end of the process, selecting a business application limits IS’s choice of operating system, sometimes to a single one.

Trying to partition responsibilities to preserve the prerogatives of one group or the other leads to nothing but bad results. “You have to do this for me because I’m your customer,” and “You can’t do that because it violates our standards,” are two sides of the same counterfeit coin.

There are few purely technical or purely business decisions anymore. Since form follows function, you should strive for a relationship that recognizes this fact. What kind of relationship should you have with your consumers? One that emphasizes joint problem-solving and decision-making, and working together in a collaborative environment.

Or, in a word, “partnership.”

Comments