Perhaps if I'd been using my fourth-generation Executive Time Management software package, the mistake never would have happened. But I couldn't even get the darn thing loaded, so I put the manual in my bottom drawer and fell back to my zeroth generation paper and pencil calendar. And somehow I managed to schedule, two lunch appointments for the same day.
Jake, who was IT manager at Ninth National Bank, suggested that we all have lunch together. And that, because of my mistake, I should pay for the lunch. My stupidity had left me with no good alternative.
I called Lorene at the IT section of Glittering Mines. She agreed to the lunch å trois—at an appropriately expensive French restaurant. It was going to be an expensive mistake.
After lunch, emboldened by a stomach full of lemon sole, I decided to talk about the software difficulties that engendered this situation.
Jake was immediately sympathetic: "You're not the only one who has trouble with so-called fourth generation software. I've spent $75,000 for a 'user-friendly' financial analysis package. It's so unfriendly that all the users cursed me for buying it."
"You obviously bought the wrong package," Lorene said. "For the same price, we got a financial analysis package that really is user-friendly. Our users love it, and they love us for buying it for them."
"What package is it, Lorene? Perhaps Jake could get a trade-in."
"It's called MONEYPENNY—"
"...but that's the stupid package we-bought!" Jake roared. "Your users must be a lot smarter than ours."
Lorene looked puzzled. "If you knew our users, you wouldn't say that. Maybe you got a different version of the system."
"Ours is version 3.12."
"So is ours. I don't understand it."
While Jake and Lorene ran through several other possible differences, I looked for loophole in the lunch bill. I couldn't see any way out of the bill, but I did see an opportunity to earn it back.
"I have an idea," I volunteered. "Perhaps there's something different in the way you two managed the introduction of the package. If you're interested, I can tackle the question as an add-on to my consulting contracts."
After a short negotiation, we agreed that I would interview a few users in each organization, as long as it didn't add anything to their costs. If I found anything interesting, then it night lead to future contracts.
At Ninth National, however, the users taught me nothing except a few new swear words. At Glittering Metals, the users were less emotional, but I didn't learn anything at all.
I decided I must have been mistaken. Something about MONEYPENNY made it more usable at one place than another. I asked Cliff, the last user I interviewed, if he'd let me watch him use MONEYPENNY. I promised to sit next to him and say nothing, regardless of what happened.
It seemed MONEYPENNY was an average "fourth generation" package. It had some nice features, but it didn't meet my human engineering standards. Still, Cliff seemed to be getting along all right... until the screen flashed this ominous message:
ILLEGAL ENTRY... COMMAND REJECTED
Cliff pondered the message for a few moments, then hit a few keys. Another message:
RECURSION ATTEMPTED IN PARAMETER
"What's recursion?" Cliff asked.
"It would be better if I remained an observer," I said, a bit cowardly. Just do whatever you would do naturally."
"Well, at least tell me what's parameter."
"Don't be angry, but I promised not to say anything."
"Okay, then call the Hot Line. Scott or Leatrice should still be there. They usually work late."
"Who are Scott and Leatrice?"
"They're the Hot Line Programmers for MONEYPENNY. Who did you think I would call?"
Being a good consultant, I played it cool. "Oh, the Hot Line Programmers, of course. I just didn't know their names."
Cliff talked to Leatrice, who gave him a magic formula to put the hex on his unwanted recursion. The hex worked, unlocking the screen and sending Cliff merrily on his way. After the session, I asked him if he ever had any trouble with MONEYPENNY.
"Trouble? No, nothing that I couldn't handle. It's a real user-friendly system. "
Cliff never mentioned Scott or Leatrice, but I thought I'd pay a visit to the other end of the Hot Line.
It turned out that the Hot Line is an institution at Glittering Metals, dating back to the dawn of punched card tabulating equipment.
"Programmers serve on the Hot Line mostly when they're between projects," Leatrice told me. "It's good experience—you never know what you'll get into."
"What kinds of things?"
"Everything and anything, I suppose."
"That's not very helpful. Don't you have a job description?"
"Not really. It's kind of a temporary assignment, so you just keep your old job category. I'm a Senior Programmer, but we have Systems Analysts, too. And one Systems Programmer."
Later, Lorene told me that the job of people on the Hot Line is to do whatever is necessary to make users happy. In the old days that might have meant running off an extra copy of some report they had lost and carrying it upstairs to them. Now it frequently meant figuring out how to get their user-friendly systems talking to them again. •
"It sounds to me like a Hot Seat, rather than a Hot Line. What kind of people do you put in that job?"
Lorene pondered my question for a few minutes before answering. "I guess I look for generalists—people who can do a little bit of everything. They've got to be technical enough not to be snowed by systems problems, but they've got to be good communicators—good listeners especially—above all else. Not many of our technical people are good listeners."
"What else?"
"Well, they're problem-solvers. They don't get stuck. Somehow they get things going."
Having concluded my investigation, I went back to Ninth National. I explored the question with Jake, but he said they had nothing like the Hot Line. I then asked him if they had any user-friendly packages that had worked well.
"Sure," he said without hesitation. "There's a statistical analysis package that they use in Personnel They've never had a moment's trouble with it—but they certainly don't have a Hot Line."
I arranged to visit Personnel, where I soon discovered that their "Hot Line" was Arlo, a Senior Records Clerk who had learned to use the statistical package when he did a Master's thesis in Personnel Management. Arlo was the one who had suggested the package in the first place, and he was a gold mine of miscellaneous information about how to make it work.
Arlo wasn't part of the IT department, so Jake didn't even know of his existence. All the same, Arlo seemed to be the critical difference between success and failure of the statistical package.
When I returned from the trip, I discussed these events with Dani, my life partner and resident anthropologist. "What you seem to have discovered," she said, "Is what anthropologists call a cultural broker."
"Tell me more."
"Cultural brokers exist whenever two different cultures must interact in spite of their different languages, value systems, customs, and other barriers to communication. The cultural broker is a person who happens to have one foot in each culture, so can act as a go-between whenever the need arises."
I was impressed with the aptness of this description. Users often say that IT is a "different culture." IT-ers, on the other hand, certainly feel the same way about their customers and users.
A series of visits to other clients convinced me that behind every successful "user-friendly" system there were cultural brokers. Sometimes they were right out in the open. Sometimes they were so well hidden they almost blended into the wallpaper. But they were always there.
Once I became aware of this hidden function, I discovered cultural brokers under such titles as Customer Service Representative, User Service Specialist, Technical Specialist (with a variety of subtitles), Consultant (again with subtitles), and Systems Engineer.
And, since the advent of the Agile movement, I've found them operating openly as Customer Surrogates. The problem with this title, in my opinion, is that it suggests a one-way communication, ignoring the function of communicating with the customer about the culture of the Agile team. But such a hidden function is not exceptional. Most of the cultural brokers I've found are masquerading under conventional titles, including Programmer, Analyst, Systems Analyst, Systems Programmer, Trainer, Database Administrator, and Business Analyst.
Throughout my consulting career, whenever I find a successful system, I've hunted for the cultural brokers. Though they were called by different names, attached to different departments, and had different job descriptions, there were cultural brokers everywhere software systems were successful.
Here are just a few examples.
A large bank has a department staffed with "Technical Specialists." Organizationally, Information Center reports to the IT manager, but physically it is in a separate office close to the two major user groups.
The Technical Specialists support whatever packages are purchased for users with such activities as training new users, consulting on immediate problems, helping users write specs for add-ons, and negotiating fixes with vendors.
The IT manager says that the title "Technical Specialist" was purposely vague, so as not to prejudice anyone against doing anything necessary to get the users what they want. He says: "Sometimes they come over here and convince us to do things for the users that I can't believe I'm agreeing to. And I hold their pay checks!"
In the actuarial department of one insurance firm, buying software packages is an established practice. Whenever a new package is contemplated, one of the younger actuaries is assigned the job of making the selection, or deciding to build their own. Once a package is selected or built, the chooser becomes the cultural broker for that system—under the informal title of Technical Specialist for the XYZ System.
Glittering Metals had their Hot Line system, in which the cultural brokers were any technical people who happened to be under-loaded. In several other installations, essentially the same system was in place with no formal recognition from management. Users simply learned the name of someone in IT who "knew the answers," and that person's name got passed from user to user.
In another bank, the investment analysts were happily using a new system without any outside help. In fact, they were so happy with the system that they started to swamp the bank's on-line database. A database specialist who was sent upstairs to investigate discovered that their "programming" not only consumed their time but also produced many subtle bugs that invalidated their analyses.
The investment manager requested that the database specialist be permanently assigned to assist the analysts, thus creating a new cultural broker.
In the marketing department of an electronics manufacturer, their informal hot line system changed when the informal cultural broker departed for greener pastures, leaving the users with no effective cultural broker. Without too much trouble, one of the heaviest users of the program generator acquired the cultural broker role. The job moved out of IT entirely, but management hadn't known it was there in the first place, so it didn't cause a ripple at the upper levels.
Some of the marketing users, however, thought that they were probably not employing the full power of the package, because without technical support from IT, they shied away from some of the more "technical" features. In one specific example, someone tried to use a formatting feature but didn't succeed. When the cultural broker couldn't figure out what was wrong, the user decided to use a less convenient format.
The situation in this electronics firm suggested that I might be able to find places where some potentially useful software wasn't being used because no cultural broker was available or forthcoming. It's a bit difficult, though, to attribute causes to events that didn't happen, so I had to make some inferences. For instance, I noticed that the larger the group of potential users of a system, the more likely one of the users was to become a cultural broker.
In the case of Ninth National Bank, only three potential users had actually seen a need to try the system. None of the three evidently had sufficient motivation or technical bent to get it going, and it withered away on a shelf.
In a situation like that, the IT department could have increased the chances of success by supplying a cultural broker, at least during the early stages. Or they might have tried to create a larger user community.
Even though a small group of users is less likely to create its own cultural broker, there will always be some individuals who have just the right combination of skill and motivation to succeed with a new system without assistance. Some of these individuals become missionaries for the new system, recruiting other users with such enthusiasm you begin to suspect they're receiving a finder's fee for each convert. Actually, their biggest payoff seems to be acquiring the role of cultural broker, with concomitant respect and attention from their colleagues.
And the future for programmers and analysts? Commercial applications are supposed to "eliminate the need for programmers." But the simple truth is that they're not that well designed or well implemented and won't be for a long time. And, the more important information systems become to their users, the more critical the programmer's role becomes.
No, I think both programmers and analysts will still be around for a long time. But their roles will change. One such role is that of systems programmer. Installing and maintaining individually programmed systems is straining the supply of competent systems programmers. As a result, some applications programmers are moving in an even more technical direction.
Another changing role is system designer. If systems are to become truly user-friendly, we're going to need ten times as much work on their designs before they even reach their users.
But the greatest new demand is for programmers and analysts to move in the other direction—not so much further from the technical side as closer to the users' side.
The culture brokers I have encountered have retained or acquired the basic technical skills of programming, but also have more than the typical programmer's share of "people skills." These culture brokers, whatever they are called, are first of all good listeners.
Secondly, they tend to be generalists—interested in more than one thing and capable of learning new things quickly. And this includes a strong interest in people—they like people and enjoy helping them.
Good culture brokers are good problem solvers they get the job done, regardless of what it takes. If software is going to continue to succeed, we'll need a lot more such people. It would pay us to start finding them and training them straight away.
For more on "people-skills," see my People Skills Bundle at https://leanpub.com/b/peopleskillssoftbutdifficult .
