All Posts in Policies and Procedures

|In: Office Politics|Last Updated:

“We ought to start a mentor program,” said one of the four Jim’s reporting to me several years ago.

“Great idea,” I replied. “One question: what’s a mentor program?”

A mentor program, Jim explained, recognizes the expert-in-the-next-cubicle, providing support, prestige (or at least respect), and a role in influencing how IS deals with LAN and desktop technology and support.

“I like it,” I told him. “You’re in charge.”

At this juncture all four Jim’s (and the rest of the room too, except for the other Bob who sat sketching the meeting notes) explained that this would prevent the proposal of any more good ideas. Suggesting doesn’t automatically mean volunteering.

Eventually we found two volunteers and started the program. We won a national award for it, too. And here’s the greatest part: I got some of the credit, when all I did was pop for lunch, books, and a few trinkets. Total budget variance: 0.0113%. Non-money.

Last week’s column started a series on the interaction between IS and the end-user community. As you may remember, the column discussed three insights that form the backdrop for these interactions: (1) Visibility = Dissatisfaction; (2) You need to provide stealth end-user support; and (3) IS isn’t the expert when it comes to personal computers.

Mentor programs build on all three of these insights at the operational level. By improving “next-cube” support, fewer problems reach any manager’s radar screen. If you’re really persuasive, get your mentors to buddy-up with new users, so neophytes have someone to say, “I don’t remember what they said about this,” to without feeling embarrassed.

Mentors require a small but real support effort on the part of IS, but reduce the total time expended by IS analysts supporting end-users greatly. Let’s look at how to organize a program like this.

1. Find a compatible and enthusiastic pair of individuals to head this up. Two is a great number of people for a program like this. Two people bounce ideas off each other where one just mutters. Two load-balance where one burns out or lets the program slide. Two keep each other’s enthusiasm going.

2. Qualifications: you need party planners and social directors, not techies. Business happens over lunch and participation is voluntary. Your mentors gotta wanna. That means planning lunches that are entertaining as well as useful. (Yeah I know: making work fun isn’t in fashion this year, but I’ve never had much fashion sense.)

3. Monthly Lunch Programs: have contests with prizes, (give the group a list of obscure features and see which one knows the most) drawings for door prizes, and guest speakers (every vendor in town will drool over the chance to talk to a group like this). Ask mentors to submit “Tip ‘o the Month” ideas for your company to include in its employee newsletter, and give a special prize each month to the mentor supplying the tip.

4. Giveaways: give every mentor aftermarket books on your applications – the ones for sophisticated users, not beginners. Also give them a plaque, clock, t-shirt, sweatshirt … something that both identifies them as a mentor and that they’ll like.

5. Influence: involve mentors in product decisions, configuration defaults, training-course content … everything that directly affects the end-user community. Give them access to a test server housing new software releases as soon as each new release appears on the market. Invite them to stress-test the new releases and give them prizes for major bugs.

This isn’t a strategic program – heck, it isn’t even tactical. It just helps everyone out with their day-to-day grind, at very low cost. You may not be a hero for putting together a mentor program. The mentors will be the heroes if anyone is, and that’s as it should be.

But you’ll have done your good deed for the day.

Comments

|In: Organizational Effectiveness|Last Updated:

The collapse of world communism means we no longer get to hear political candidates refer to one another as “commie pinkos”, “communist dupes”, or the ever-popular “Marxist”. Now, we get to hear about the character issue, the term “liberal” is bandied about as an epithet, anyone we don’t like becomes a Nazi, and everyone involved seems to be searching for issues worthy of an attack on their opponents.

I miss the old days.

One of the principle differences between Marxism and Capitalism is their theory of value. Karl Marx proposed the Labor Theory of Value, while Capitalism promotes the Market Theory of Value.

The Labor Theory of Value, typical of Marxist economics, has a curiously ethical flavor to it. Value, says Marx, comes from the effort needed to transform raw materials into finished product – that is, it’s the workers who create value.

Capitalism, pragmatic as always, says that the market, through the dynamics of supply and demand, establishes value. The market, of course, is nothing more or less than the aggregate behavior of all actual and possible customers. Customers define value in a capitalist economic system.

Customers define value, which irritates movie critics (who usually sneer at anything lacking subtitles or including an explosion and car chase), computerphobes (who complain about feature bloat, claiming nobody uses program options I use every other day), and software engineers who deride those who care more about features than internal architecture.

The idea that customers … real paying customers, not “internal customers” … define value is one of the three great rules of management. (The other two? Form Follows Function and Align Everyone to a Common Purpose.)

I’m not a big fan of the internal customer concept. It strikes me as a metaphor that’s been extended past its useful purpose.

When you’re redesigning a process, you need to look at who sends work in and who receives the work you send out. Why? You define the specifications for the work that comes in to you, and the recipient of the work you create defines the specifications you use to define your product. In that sense, whoever receives the work you create is your customer, whether it’s an employee in your company, a department in your company, or an external customer.

So far, so good. “Internal Customer” is a useful shorthand for whoever creates the specifications. Unfortunately, nobody can ever seems to limit the application of a metaphor, so in short order, people started to believe that internal customers are always right, just like external customers. Some people in accounts-payable departments even believe vendors are their customers, since vendors receive the work they create.

Internal customers lack the defining characteristic of real customers. They don’t pay you. That means they don’t define value, nor does a transaction with an internal customer give you the wherewithal (money) to provide the service they ask for. And that, in turn, means they’re not always right.

The internal customer metaphor also violates the third great rule of management: align everyone to a common purpose. It takes companies to the opposite extreme, inducing severe myopia. When employees believe in internal customers, they look no further than the needs of the next person in line. Only a few employees worry about the needs of real paying customers.

Here’s what I recommend as an alternative: everyone in the organization should understand their role in providing value to real paying customers – the big picture. If you’re in Accounts Payable, you’re trying to minimize overhead while maximizing cash flow, thereby helping sell products and services at an affordable price. Human Resources? Help managers develop a motivated, skilled, high-morale workforce.

Information Systems? How does Information Systems provide value to real, paying customers? Traditionally, we do so by helping everyone else in the company be more effective in their roles. That, in turns, helps the company increase the value it can deliver.

The world, however, has changed. Now we have a more direct role to play. Have you started to play that role?

Comments