All truth lies buried in paradox.—George Bernard Shaw
The Right Endeavor is along the path of people and cultural enlightenment. So this chapter speaks of people, and includes cultural impacts of systems. Culture is affected by Karma. Karma is the concept that actions set off reactions that affect future events. This is very true in analysis, where slight misperceptions can ripple back as a tsunami. The best illustration of Karma I’ve ever seen was a filmstrip I saw in Driver Ed in High School. The filmmakers had no idea they were illustrating Karma when they showed an example of an impatient man on his way to work discourteously cutting off another driver. The man went on his way, but the driver who was cut off seethed, and went on to cut another driver off in his anger. That driver then went on to cut another motorist off, who cut another off, and so on. The cycle continued throughout the workday as the first driver obliviously worked away. At the end of the day the man left work and was crashed into by, you guessed it, the latest angry driver caused by his transgression of that morning. The film ended with the man protesting: “Why do these bad things always happen to me, the good driver!”
Whether or not you accept Karma as a cosmic force, there is no question actions reverberate in systems development. Lack of care in the early stages of the life cycle to clarify goals and requirements will come back to haunt you in the next life, namely the next phase of the project. As the Beatles said: “In the end, the love you take is equal to the love you make”.
This chapter of the book will concentrate on the interpersonal aspects of analysis. Drawn from my UC Berkeley Extension class, The Systems Analyst as Information Systems Catalyst, this portion focuses on the people and cultural problems you’ll encounter doing analysis. I almost called this chapter The People Path, because it talks a lot about people problems, as a group and in groups. We’ll look at rules, aphorisms and guidelines for discovery and harmony to help you start and finish your present analysis assignment with enough good Karma left over to get you through the next one. Incidentally, my book based on the course, The Systems Analyst as I.S. Catalyst, has more material on this topic.
The good news is that the worst problems associated with analysis are not technical—they’re people problems. The bad news is that all the problems turn out to be people problems once you analyze them. Perhaps expectations were too high, requirements or capabilities were misunderstood, or someone didn’t make the connection. And despite the fact that systems analysts are first and foremost problem solvers, we tend to lose all our problem-solving skills when confronted with a people problem. With any other problem, we’ll go through the proven cycle: analyze the problem; design a solution; test it, and if it works; implement it. And then maintain it. But it never occurs to us that exactly these same steps can be used with people problems. So if you have a problem employee, coworker or user, try to solve it like you would any other problem, using the problem-solving skills you’ve developed as an analyst
Sometimes using a little Judo psychology on a difficult person can turn the situation around. Jūdō is literally “the gentle way”, and suggests you should try to turn anger away, not with force, but by rolling with the attack. And if Judo doesn’t work, there is always Karate.
C.P. Snow delivered his lecture on The Two Cultures in 1959. He suggested that intellectual life divided into two isolated cultures, with Science on one side, versus the Arts and Humanities— ‘the literary Intellectuals’—on the other. We are likewise faced with two cultures in developing a computer system. Guy Kawasaki in The Macintosh Way calls them “T-Shirts” and “Ties” for their sartorial preferences: T-Shirts are commonly worn by Technologists such as programmers; Ties are de rigueur in the business departments in typical companies and marketing departments in high-tech firms. Various terms are used to describe the business side, the people we systems analysts build computer systems for: business, client, subject matter experts. User is probably the most common term, but it has bad connotations: “Users are losers,” according to the US Government, although referring to drug users. So we often call them the “business” in this book.
As a systems analyst, a critical part of your job is to provide a bridge between these two cultures; you must be bicultural to bring the two disciplines together. My consulting firm’s slogan is “Zen & Analysis: Business Art and Systems Science”. In this day of the indispensable computer, you must be able to think from both a business and a technical perspective if you are to design effective business solutions.
Is analysis more an art, or a science? At this stage of history, I could not have named this book Zen and the Science of Systems Analysis, Robert Pirsig aside. In fact, even programming has a lot of Art to it. Donald Knuth, the Stanford professor emeritus, recipient of numerous awards and honors, including the ACM Turing Award, and the President's Medal of Science, named his monumental opus, called “the definitive description of classical computer science”, you guessed it: The ART of Computer Programming. I once attended a talk at Cisco Systems in Silicon Valley. The lecturer gave a “here’s how it’s done at Cisco” perspective. He entitled his talk “Requirements Analysis: the Art and the Science”. His first slide was Webster’s definitions of Art and of Science. He then said: “Of course, Systems development is more an Art than a Science. I’ll go over the Science quickly first, because that’s the easy part”.
If your experience and background make you lean to one side, try to become a little of the other. Systems development requires both programming and analysis. Moving from a programmer to an analyst, or from business to IT, involves becoming and artful scientist or a scientific artist. Developing a system is not a science! The system’s success lies not with scientific algorithms, but the artsy heuristics.
What’s the best way to gain deep insight into the culture of any IT organization? Ask about how (or if) they conduct feasibility studies. The feasibility study is the first step in developing a system, and indeed the first phase of many SDLCs. It may be called something else, perhaps the concept or planning phase, but what I mean by feasibility study is the method, formal or informal, by which projects are selected for approval and funding—so call it project approval if you prefer. Whatever else the deliverable of a feasibility study is, its primary product is funding for the project. A feasibility study can be a months-long inquiry into new technology including the meaning of life and the nature of time and space, and produce a tome spanning several volumes; or it might consist of the CEO tossing you an article from an in-flight magazine and saying “Do it!” (In fact, the wise CIO has a team of people who sole job it is to surreptitiously sweep any aircraft the CEO will be boarding and remove all in-flight magazines.) In some organizations the feasibility study is actually conducted as part of an ISP, a formal Information Systems Plan of ponderous proportions.
The attitude toward feasibility studies can give great insight to the culture of an organization. When I worked for the State of California, we were required to do a feasibility study for any project over a certain amount; I think it was $25,000. We were planning a new system that would involve on-line access from dozens of State offices to a huge database. Needless to say, this project would exceed the $25,000 threshold so we had to do a feasibility study. But wait, the feasibility study required considerable research, and a cost benefit analysis with return on investment (ROI) calculated over the life of the project. You guessed it, the feasibility study itself would cost more than $25,000, so we needed to do a feasibility study for the feasibility study. And guess what? That feasibility study would exceed the threshold. And on and on. So the culture at the State was to study things.
After the State, I went to work for American President Lines (APL). At the time, it was a very nimble and fast growing company. One of my early assignments was to check out an old computer system that was being used in the ship terminal. I looked it over, and reported to my boss we should just scrap the old system and buy new computers at a cost of some hundreds of thousands of dollars. “Okay, go buy them”, she said without hesitation. I was taken aback, assuming I would have had to spend weeks on feasibility studies. “Well, umm, won’t someone have to sign for them?” I stammered. “Oh, don’t you have a pen? Here, borrow mine.” And that was it.
Culture can change over time, and that is often first reflected in the feasibility study. American President Lines has changed since my days there, in fact the official name is now “APL”, not American President Lines, as the firm isn’t American, having been acquired by a Singapore firm. It became less entrepreneurial, and not nearly as fast as before: they began to study things more.
This is a story about a project conducted by the Highway Transportation Division of an anonymous banana-shaped State on the West Coast of the United States that has a city we’ll call “San Francisco” in it. It seems they were interested in determining the commute patterns in this mythical San Francisco area so as to design the best freeways. And so they set up some video cameras at some strategic points and taped the cars driving past. A small army of data entry clerks watched the videos, typed the license plate numbers in, and a survey was mailed to the registered owner of each vehicle asking where they were coming from and going to. Quite a feat of information processing.
The survey’s major conclusion: At any given time, a great many people are not supposed to be where they are! Spouses who were supposed to be at home and workers in company cars who were supposed to be home sick called, desperately seeking help because their sins were discovered when the wrong person opened the survey. The authorities hastily sent out a vaguely enough worded letter to the affect of: “You might have received a survey in error” (although of course there was no error) to let the wanderers off the hook.
So the lesson:
Think about the impact of your actions.
In the Programming classes I teach at the College of Alameda, I give the students the option of completing the all-important project as a team. The project is heavily weighted such that it pretty much determines the grade for the course. The rule is: the team receives a single grade; and each team member gets the same grade. For example, ten points are awarded for presenting the project to the class. All members receive the ten points, even if those that don’t participate in the demo, in fact they get the ten points even if they are absent on the day of the presentation. This is because the major learning goal from the exercise is teamwork, and I learned something about teamwork in the Army.
Whatever else you want to say about it, there is probably no more successful team building organization than the Army. The Army consistently takes a group of unrelated individuals from different backgrounds and molds a group of soldiers literally willing to die for one another. In a RAND Corporation study conducted for the US Army entitled The “Virtual Corporation” and Army Organization, Fukuyama & Shulsky discuss organizational trends in the commercial sector. Surprisingly, despite the stereotype of an army as the ultimate in C&C (Command & Control), many of the commercial-sector initiatives of the Nineties first appeared in the military, shown by examples from Napoleon, to Blitzkrieg, to the US Army.
One policy I observed in the Army is to always treat the team as a team. The team will be rewarded and punished together, as a team. If everyone does well, everyone does well; if anyone fails, everyone fails. Remember that an army travels at the speed of the slowest marcher, and so with teams. So if teambuilding is your goal, recognition and rewards should be given to the group, not to individuals. Takeuchi & Nonaka say Japanese companies establish evaluation and reward systems based on group performance. They are a subtle way to exercise control over new product development teams. For example, Canon (named, incidentally, after the Buddhist goddess of Mercy, not for artillery) applies for patents in the name of a group.
[ [ [
A team is not a team unless the team is greater than the sum of its members. One time I had two young men in the class who were your typical nerds. They were doing a very impressive project; I saw them in the lab at all hours, and most of the questions they asked me were beyond even my experience, as they were getting into some pretty advanced stuff. So I was quite pleased when I received their project package: excellent technically, and professionally presented.
Only one surprise. There were three names on the cover. Strange. I hadn’t seen this third person working in the lab with them at all. So I asked them about it, and the two nerds earnestly insisted the third team member was absolutely vital to the success of this project; in fact I could flunk them if I wanted but their teammate absolutely deserved an A+. Pretty strange, huh?
Oh, one small detail I neglected to mention. The third team member was a strikingly attractive young woman.
So what to do? In the end, I decided to follow the stated rule, and give all the team members, including the young woman, the A+ the project deserved. There were several reasons for this, one being that I feel I must respect my students, even to the extent of believing what they say even when there is strong evidence to the contrary. But from a managerial perspective, the young lady did contribute significantly to the success of the project, in that it certainly would not have been as impressive had she not been on the team. A lot of the nerds’ motivation was to get her an A+. These two guys would gladly have jumped off the Golden Gate Bridge for her, so working extra hard on a class project was easy enough for them.
[ [ [
I’ve seen other team dynamics at work, although not as blatant. Sometimes a person who is only an average performer contributes to team morale in such a way as to enhance the entire effort. Take care when you disturb a well functioning team; even the least performer by objective criteria might be essential to the success. Team spirit is a fragile commodity and you best not tamper with it unnecessarily.
Sometimes you can effectively enforce rules without enforcing them at all. Another War story: When I was drafted into the army, a large number of us were taken to a large room and lined up with our bags and suitcases and told to dump out our bags into small squares painted on the floor about three feet square. Several MPs (Military Police) with dogs were standing by, and there were several 55-gallon barrels located around the room.
The officer in charge came to the microphone and said, “We’re about to conduct a search of your belongings. If we find any contraband, you can be sure you’ll be severely punished. But before we conduct the search, we will leave the room for five minutes. He pointed to the barrels. While we’re out, you can drop anything you’d like into the barrels. You will not be punished for any contraband you drop in there, but if, on our return, we find any drugs, alcohol or weapons, you’ll be doing hard labor at Fort Leavenworth before you know what happened to you.”
The officer, MP’s and dogs then left the room. As the minutes passed, one by one some of my fellow inductees went to the barrels and dropped something in. All the barrels were overflowing with drugs, booze, guns, knives, and brass knuckles by the time the officer returned, without the escort. He went to the microphone and announced: “Thank you, you can pack up your bags and leave now” and we were allowed to leave without any search.
So the strategy was that once you make everyone believe they can’t get away with something, it isn’t necessary to actually implement a plan to stop them. Sometimes security on computers works this way. Like a “Speed Limit Enforced by Radar” sign in town with no radar, if everyone thinks the computer is secure, it is. If you can’t afford a surveillance camera, put up a fake camera: Make them think they’re being watched.
After graduating from Cal State Sacramento (CSUS) with a degree in Economics, I went to work as an economist for the State of California, in which capacity I was a user of computer systems. I got into programming after I was told that the computer work for my survey, which would require about three weeks effort, would probably reach the top of the queue in about two years! I figured: “Maybe I could get the three weeks’ work done in less than two years by doing it myself”, and managed to do so. As the other economists took advantage of my growing skill I gradually found myself programming full time. I was a good enough economist to see programmers were more in demand than economists so I changed careers and became a programmer. Now that I’m on the other side, whenever I’m dealing with clients I try to remember my own experiences as a poor little frustrated user, just trying to get a little help from the computer department. This empathy with my users and clients often helps me understand the situation better than others who do not have the benefit of the user’s perspective.
[ [ [
Years later, after I’d been in systems for a while, I was teaching a group of users how to use computers and was absolutely astounded at how stupid they were. Dumb as dirt! They did not even know the most basic concepts about computers. Amazing, since some of them were college graduates, and held well paying positions. That weekend I happened to be cleaning out a closet and came across a booklet I’d received way back when I was a junior economist from a class called something like “Computers for Nontechnical People”. As I flipped through the book and noticed the notes I had made a few years before, I realized I had been even dumber than those users I was teaching. After years of working with technology you forget that you weren’t born knowing this stuff.
Some years after desktop computers became commonplace on users’ desks, the company I was working for began giving PCs to the programming staff (IT is always the last to automate). I came back to my desk to find a new PC there. I turned it on, but it didn’t seem to work, so I figured it hadn’t been connected yet. I called the helpdesk, and after trying some things, one of the technicians came down. To make a long story short, I had turned on the CPU, but not the monitor. I only saw one of the switches, and I didn’t realize the CPU and monitor were separate pieces. The monitor was sitting on top of the CPU, and I thought it was permanently attached. In fact, when I tried to move it to a better location, I almost dropped the monitor when it slid off the CPU. In my defense, I have to argue that that design is not that obvious. The Macintosh and iMac, for example, are designed with integrated CPU and monitor, so it could have been designed that way.
As with many technological things, it’s intuitively obvious, once you’ve seen it. Someone trying to set up their first home computer faces a daunting task. Once you know how the plugs are designed, it’s obvious where they go, but the first time you try to plug in one of those plugs can be gut wrenching. You can see all those little pins, which are obviously fragile. How hard should you push? After you’ve done it a few times, you know immediately when you’re pushing too hard, so you have it in the wrong slot or have it upside down. But the first time you have no idea. So remember how helpless you felt at first and temper your arrogance with empathy.
The Macintosh Group at Apple Computer was special. And special people get special treatment. Steve Jobs had assumed personal command over this group and separated them from the rest of Apple Computer. They had their own special building, with a pirate flag flying over it. And the Mac people were very pleased. When they traveled, unlike the rest of the company, they traveled first class. First class people travel first class. And the Mac people were very pleased. And their soft drinks were free, provided by the company, and the Mac people were very pleased. And they knew they were better than anyone, because their leader, Steve Jobs, told them so. So the Macintosh people were very pleased with themselves, and very happy with Apple Computer.
One day it was decided to integrate the Macintosh Group back into the company. And since the Mac people were special, Steve decreed no Mac person would report to any non-Mac person after the merger. If two groups merged, the Mac Group leader would become the leader of the combined group. If a Mac person was alone in a group, he’d be the group leader. Many of them were elevated to managerial and supervisory roles because of this rule. And the Mac people were very pleased.
Until they began to look through the personnel folders of their new charges. It became obvious the salary scales in the Mac group had been significantly lower than the rest of the company. The new leader of a group of non-Mac people discovered he was the lowest paid person in the group! All of his subordinates made more than he did.
And the Mac people were not very pleased. Some formerly loyal and enthusiastic workers actually left the company. So the lesson is that, logically or not, people usually measure satisfaction based on their relative standing, not their absolute standing. Often someone who is very pleased with the current situation will become very dissatisfied upon discovering someone else in a similar situation is getting a better deal. Keep this in mind when planning new systems and the reward structures associated with them.
People Judge their Situation not Absolutely,
But Relative to Other People
In most American companies it is considered bad form to discuss salaries. In some companies, it’s even a disciplinary offense. HR Departments want rigid security to protect salary information. In several database courses I’ve taken, the example used to explain database views, that restrict access to certain fields, was the obvious need to have a view of personnel information that excluded salary to avoid enquiring minds. Salaries are kept secret to preserve “employee’s privacy”. Yeah, and so there won’t be grumbling about inequitable treatment.
I’ve worked in private industry where there was a secret-salary policy. But I’ve also worked for a State government, where the salary for each position was established by law, and so a matter public record. Morale did not collapse based on the knowledge of one another’s salary. In fact, it had clear benefits. You knew you wanted to work for that next promotion because you knew exactly how much more you’d make when promoted.
And there was probably less dissension, given that people were not disgruntled in the mistaken belief they were underpaid. When I was at American President Lines, an employee survey revealed every identifiable group of employees in the company thought they were underpaid relative to other groups! That’s mathematically impossible! So at an absolute minimum, 50% of the employees incorrectly felt they were being treated unfairly, which would have been impossible if they knew the true salaries.
It seems to me that if you are running a fair and equitable compensation system you should have no problem with revealing salaries.
Many of you probably have experienced, and those of you that haven’t surely will, the user Forest/Tree problem. Imagine an analyst conducting a JAD (Joint Application Development) session, when the following exchange occurs:
Analyst: “Let’s assume we’re selling widgets”
User: “What are widgets?”
“Just some arbitrary product.”
“We don’t sell any arbitrated products.”
“Okay, what do you sell?”
The user begins a long litany of items describing the product line in numbing detail. The analyst picks one out, and manages to stop him. “Okay let’s say we’re selling frabistats. So here we’ll put the quantity, say 2 or 3.”
“We only sell frabistats by the pair!”
Someone else: “No, the size 8 frabistats can be sold individually.”
You: “Okay a pair frabistats, say they cost $5.”
“Don’t be crazy, frabistats are more like $50.”
“Okay, $50.”
“But none of our frabistats are $50. Some are $45, some $55, but none are $50.”
“Okay, $45 then.”
“No, the $45 frabistats are on sale for $39.99 this week.”
“Okay, to simplify the math in our example, let’s say $40.”
“But they’re not $40, they’re 39.99!”
Etc.
Etc.
Etc.
[ [ [
The users in this case were being very precise, which was actually causing a problem, and interfering with analysis. Take our familiar kotowaza, “Sen Ri no Michi mo Ippo kara”, which you recall means “Even a Journey of a Thousand Miles starts from One Step”. To be precise, the distance referred to was in Ri, the Olde Japanese measure of distance, about 2½ miles. So precision would require that we translate the kotowaza “Even a Journey of 2,443.1398 Miles starts from One Step”. Or perhaps “Even a Journey of a Thousand Miles starts from 0.409332787556283 Step”. But that would obviously ruin the poetry. This is the kind of judgment translators, as well as analysts, must face, and the Zen they need to strike the balance between precision and clarity. For an in-depth discussion of the questions faced in translating one language to another, read Douglas Hofstadter’s Le Ton beau de Marot. It uses an Olde French poem to explore the problems of translation. The various renditions can become a bit tedious, so you might want to scan over them, but anyone interested in representations of languages, including systems analysts, should read this book. Hofstadter was one of the first Computer Scientists in the World, so his work relates directly to computing.
Don’t Let
Precision Prevent Clarity
Or consider another example, this time trying to state a rule, from Marvin Minsky’s The Society of Mind. We all know birds fly. But to be more precise: “Birds can fly, unless they are penguins and ostriches, or if they happen to be dead, or have broken wings, or are confined to cages, or have their feet stuck in cement, or have undergone experiences so dreadful as to render them psychologically incapable of flight.” This is another case where we walk a line between two sides of Yin and Yang, where Zen Analysis skills can help us make the right decision.
There’s an old anthropological canard to the effect that the Hottentots of Africa only have three numbers in their language: 1, 2, and “more than two”, or “many”. On investigation, they are in fact able to communicate large numbers by repeating and stressing their word for many. It turns out that Hottentots actually have a better number sense than Westerners, or at least Oxford undergraduates, since when shown a certain picture of a group of antelopes all Hottentots agree there are “many, many”, not “many, many” or “many, many”. Show the same picture to a group of English college students and the estimates range from “a dozen” to “several hundred”.
[ [ [
So the Hottentots were the victim of a misunderstanding, but extensive anthropological field research has led to the astounding conclusion: Even if they had only the three numbers, the Hottentots would be more advanced than computer programmers. It seems programmers have only two numbers: one and many. That’s because to a programmer, a routine will either execute once, or it will execute more than once. If more than once, it needs a control structure or loop around it, if once, it doesn’t. To a programmer, once the loop is in place, the routine can execute once, or execute a million times—it makes no difference to the programmer. And of course the range of estimates you’ll receive from programmers for a given task can be phenomenal, so they clearly can’t estimate as well as the Hottentots, or even the Oxonians.
Analysts, on the other hand, are a bit more advanced than programmers, although they only come up to the level of the mythical Hottentots. They have three numbers, assuming you will accept that zero is a number. For example, for an ERD relationship they need to know, like the programmer, whether there are one or many. But then they need to figure out if it could be zero, that is, if the relationship is mandatory. So analysts count: zero, one, many.
I know someone who escorts bus tours through Europe, accompanying a group for two or three weeks, handling the logistics, and lecturing on the sights along the way. Every trip it takes some diplomacy to handle the problem of who gets to sit in which seat. Of course there are exceptions, but she noticed this pattern in the opinions as to how the seats should be allocated.
Americans feel that seats are reserved for the duration of the trip. If you get up early the first day, you can claim the best seat, and it should be yours for the entire trip. Like a land claim in the Old West, once you’ve staked your claim you have squatter’s rights.
Europeans think each day is a new day: Each day the seats are up for grabs, first come first served. You claim a seat for the entire day, but not the entire trip.
Asians believe in sharing. Whoever had the best seat yesterday should certainly not get it today, and certainly no person should suffer in the worst seat two days in a row. Over the course of the trip everyone should have had the best and the worst seats at various times.
Check your cultural assumptions. There are obviously advantages and disadvantages to each way, and each is fair by some reckonings. Make sure your solutions consider national, local and even corporate cultures. Here are a few stories that illustrate how cultural perspective can vary:
When I was living in Japan a group of my friends and I had planned for several weeks to have a picnic in Meiji Park in Tokyo. When the day came for the picnic it was pouring down rain. When my Japanese friend told me the picnic was cancelled, I looked at him and said: “Oh, why did it have to rain today!?!”
My friend scratched his head, then began looking up words in his dictionary. I was surprised by this because his English was quite good. Finally, he had the words he needed: “There’s a high pressure cell over Korea that’s drawing moist air up from the south, meeting cold air from the north, causing the precipitation over Japan.”
Since he was always interested in learning about the English language and American culture, I explained to him that “Why did it have to rain today” was a rhetorical question, and in fact, its true meaning was “I really feel bad we can’t have our picnic today!”
This astounded my friend. He opened a guidebook written for Americans in Japan and quoted: “Japanese are inscrutable, and make an art of hiding their emotions. They often find it difficult to express their true feelings.” He then asked me: “How can this be, since as a Japanese, I have no trouble at all saying ‘I really feel bad we can’t have our picnic today!’, and yet you find it hard to say so directly”. I could only offer sheepishly: “I guess Americans are inscrutable, and make an art of hiding their emotions. They often find it difficult to express their true feelings.”
The meaning of a word can change based on its cultural context. I was on call for the Accounts Payable System one night when I got a call from the Helpdesk telling me there was some problem in Japan. When I was connected to the Tokyo office I asked about the problem.
“Oh, no, Patrick-san, we have no problem with the Accounts Payable System.” he told me.
“The helpdesk seems to think you have a problem.”
“Oh, no, we have no problem with the Accounts Payable System. It is a very good system. We like it very much.”
I was tempted to go back to sleep, but on a hunch I probed further: “Tell me, how many invoices have you processed today?”
“Well, uh, we have been able to process no invoices today.”
“And how many payments have you made?”
“We have been able to make no payments today.”
“”Takesako-san, if you have been unable to process invoices and make payments, I assure you: You have a problem with the Accounts Payable System!”
Be aware of culture and its influence, both national culture and corporate culture. In this case, the polite Japanese manager did not wish to criticize the system to someone he knew had worked on developing it, for fear I might lose face. If I had asked about a “situation” instead of a problem, things would have gone smoother.
I trained a group of users in Seoul, Korea how to use the same Accounts Payable System when it was first installed. The students were very attentive, and carefully took notes. When I told them how to enter a payable, they all carefully wrote it down. Then I told them how to make a payment, and they all carefully wrote it down. And I told them how to cancel an invoice, and they all carefully wrote it down.
And then I told them a little joke. And they all carefully wrote it down.
So I said: “No, don’t write that down!”
And they all carefully wrote that down.
The realization struck: “They don’t understand a single word I’m saying!” So it was time to try something else. I set aside the training material that had been carefully prepared, at great expense, by my boss. This was a serious decision, since my boss had invested a great deal of time in the material, and was very proud of it. She was of course asleep in the US at the time and so it was not logical to contact her.
Instead of using the training material, for the next four days we had the students bring examples of their work and demonstrated how to do each task. Things seemed to go well enough, and I returned to the US without further incident, or reference to the training material.
When I returned, my boss asked me about the trip. Obviously fishing for a compliment, she honed in on the training material. And so I had a tremendous battle with my conscience: do I lie, or tell her the truth. After a tremendous struggle, my conscience won: I decided to lie. “Your training material was invaluable.”
And so that incident was over, or so I thought. About six months later, however, the company decided to do an audit of the new system. Managers would travel to each country where the system was now being used, and assess how well the training and installation had gone. I thought all hope was lost when it turned out my boss would be auditing Korea. So I spent a little time updating my résumé just in case I couldn’t make her see the humor, or at least the logic, of the situation when she returned.
Sure enough, when I came into the office the day of her return, I had a message from my boss: “Come see me right away, I need to talk to you about the training in Seoul.”
To make a long story short, she wanted to see me because on every measure, Korea had scored the best of all the sites! They were processing more invoices with fewer errors than any other site, by a significant margin. So I told her: “Wow, and I never could have done it without your training material!”
Research leads to a puzzling contradiction. None of the books or articles you’ll read suggest humiliating employees as a management style. Yet several important projects were led this way. Consider Steve Jobs: Steven Levy tells us in Insanely Great that Steve often humiliated his subordinates, even when he himself was unqualified to judge the work.
Or consider Bill Gates, whose favorite phrase is said to be “That’s the Stupidest Thing I ever Heard”: Fred Moody recounts in I Sing the Body Electronic how Bill Gates might explode into a tantrum at a meeting. The expectation that the workplace will be a safe and pleasant environment, not a fearful place, is misplaced. As former Intel CEO Andy Grove said in Only the Paranoid Survive:
“The quality guru W. Edwards Deming advocated stamping out fear in corporations. I have trouble with the simple-mindedness of this dictum. The most important role of managers is to create an environment in which people are passionately dedicated to winning in the marketplace. Fear plays an important role in creating and maintaining such passion.”
Mike Wilson called his book The Difference Between God and Larry Ellison: God Doesn't Think He's Larry Ellison.
So the puzzlement is this: it seems that despite what we might think about management styles, it appears there is no correlation between humanity and success in projects!
Babe Ruth was the home-run king. He held the Major League record for home runs until Hank Aaron passed him. But many people don’t realize he was also the strikeout king. He held the Major League record for strikeouts—until Hank Aaron passed him. The point is you will never achieve greatness if you won’t take a chance. This same point is made in Hagakure: The Book of the Samurai, by Yamamoto Tsunetomo (translated by William Scott Wilson):
One who has never erred is dangerous.
Copyright ©2003, 2008 Patrick McDermott