All Posts in Leadership

|In: Leadership|Last Updated:

Humans choose sides and hate the other. It’s built in. Ethnic groups deprived of outside disdain fragment into ethnic subgroups that insult each other. Religions deprived of religious persecution fragment into religious factions that persecute each other. Minnesotans tell Iowa jokes.

A business deprived of strong competition isn’t immune to this human tendency either – it fragments into departments whose members make snide comments about each other while their managers vie for budgets and other resources. If you want to see an example of this, chances are the only tool you’ll need is a mirror.

I received a bunch of mail following a recent column recommending that IS establish multiple PC standards based on different kinds of work habits. Most of my mail makes it clear that lots of IS professionals still view the rest of the business with disdain and classify end-users into three groups: Idiots, troublemakers, and what was your name again?

Before you accuse me of IS-bashing and throw aside your issue of InfoWorld in disgust, ask yourself this: Do you or your analysts tell dumb-user stories? If they snicker at white-out on the screen, photocopied diskettes, and mistaking an answering machine for a modem, you have a problem.

Do your end-users snicker at the “Helpless Desk,” call outside consultants instead of IS analysts, and sneer at your pocket-protector-wearing chip-heads? If so, you have a problem, and if you don’t know whether they do or not you have a bigger problem.

As an industry we tend to focus on technologies to solve our problems, and when technologies alone aren’t enough we apply new methodologies or write new policies and procedures. Throwing technologies, methodologies, and policies into an atmosphere of mutual distrust has a predictable result: Zilch.

The psychological cause of the mutual distrust between IS and the rest of the business is the same xenophobia that afflicts us socially and internationally. Fortunately, within a corporation it’s curable.

How? Glad you asked. Here are some concrete actions you can take to create a cooperative atmosphere between IS and the rest of the company:

Trust-builder No. 1: Don’t be part of the problem. It’s easy to instill loyalty and esprit de corps by fostering an us vs. them attitude. Often, the process is unconscious. Watch your own behavior. Never disparage other parts of the company.

Trust-builder No. 2: Stamp out the word they. Insist on we: “They haven’t told us what they need,” becomes “Let’s figure out what we need.” If you can’t use “we” you don’t have the right people in the room. Get them there, or at least put a name on whatever part of “they” doesn’t turn into “we.” “They won’t let us do what we need to do,” becomes “How do we persuade Jim Smith of what we need to do?”

Trust-builder No. 3: Foster mutual problem-solving. “You” becomes “we,” too. “You need to do this,” becomes “We need to do this.” Include both end-users and IS professionals in your teams so it’s always “we.” Working together builds trust.

Trust-builder No. 4: Don’t allow blame. Don’t allow its synonyms, either. “Who caused this mess?” is usually a waste of everyone’s time and energy. “How do we fix it?” takes care of problems and builds trust in the bargain.

Trust-builder No. 5: Replace requirements with design. When you determine requirements, you ask, “What do you need?” When you design you ask, “How can we make this work?” It’s a joint effort now. You’re a partner, not just taking dictation.

Trust-builder No. 6: Foster xenophobia. People distrust members of other groups. You can’t eliminate this very human tendency, so exploit it instead. “How can we make this work?” becomes “How can we turn this into something that helps us beat those schlemiels over at the XYZ Company?”

Distrust between IS and the rest of the business is bad and getting worse. Whose fault is it? See trust-builder #4 for the answer. What’s important is that you … sorry, we … need to fix it. It’s our job.

Comments

|In: Leadership|Last Updated:

Although it’s hard to believe, not everyone trusts consultants.

Just because we’re paid fault-finders … why would that engender distrust? And our practice of repackaging everyone’s good ideas as our own? Hey, nobody forced the company’s leaders to ignore their own employees, did they?

And is it our fault that you have to live with our advice but we don’t? If we wanted to live with our own advice, we’d be you, not us.

Suggestion: Next time you hire a consulting team, ask who on the team worked for a living before joining the Dark Side. While spending too many years in the trenches has its own hazards (like making headache-avoidance the top priority), real-world experience helps consultants balance theory and practicality.

(Full Disclosure: My own 20 years of experience include five in various programming and analyst roles, five as various kinds of business analyst (in manufacturing, marketing, and product development), five in various IS leadership positions, and five as a consultant. Five appears to be my lucky number.)

This week we wrap up a sixteen-part series on creating an integrated IS plan. Why an integrated plan instead of a strategic plan? My real-world experience is that IS strategic plans never happen. No matter how important they are, the urgency of day-to-day business invariably eclipses them. Strategy only happens when it’s built into the day-to-day business of IS so everything simultaneously furthers the strategy and provides immediate value.

The sixteen articles comprising the integrated IS plan are nothing more than a table of contents. They aren’t even a methodology, only a framework for organizing your thinking about what you need to do to move your organization forward. Worse than that, they set no priorities. If you try to do everything on the list, you’ll accomplish nothing on the list.

A hallmark of effective leadership is its ability to focus on a few key initiatives. FDR, I’ve read, never had his name and prestige tied to more than five at any one time. As you review the company goals, technical architecture evolution, process changes, and leadership goals that comprise your integrated plan, figure out what will need your personal attention and sponsorship, what you can safely delegate, and what is good enough for the time being.

What will need your personal attention? Anything that’s a dramatic departure from the past. Whether it’s a change in culture, adoption of object-oriented methodologies, better project management, or a new way of provisioning and supporting PCs, if it’s a radical change you need to personally either lead or sponsor the change.

When do you lead and when do you sponsor, and what’s the difference? If you’re leading a change, you personally manage it as a project, assigning tasks and defining milestones. As CIO the only projects you should personally lead are the ones your leadership team will execute. You’ll lose prestige and standing, and simultaneously signal a lack of faith in your leadership team if you personally lead any other kind of project.

You can sponsor anything that’s sufficiently important. Sponsorship means staying highly involved, asking and answering lots of questions about deliverables, scope, purpose, and progress. It also means putting your name on it, using your position to clear away obstacles, provide resources, and communicate to the rest of the company why the initiative is important.

In addition to leading and personally sponsoring specific goals, you have one more leadership role to play, and that’s making sure everyone works the plan. It’s awfully easy to let day-to-day demands take over again. You have to make the plan the roadmap, not an add-on activity, or next year will be just like last year.

* * *

Many readers have asked for an easy way to pull everything about the plan together, so InfoWorld Electric has built a link page for this purpose [insert link].

I’m also delighted to report that Bob Lewis’s IS Survival Guide (MacMillan Computer Publishing) is nearly done and should be in the bookstores by spring. It will cover the same subjects as this series, but in a lot more depth.

Comments