In 1977, Tom Gilb and I published a book called Humanized Input: Techniques for Reliable Keyed Input. We hoped to improve the pitiful state of input design for computer systems, and ten years later, we imagined we were beginning to see some improvement. On-line systems were coming into vogue, and we expected their use could only improve the interface between humans and computers.

Alas, though some systems improved, there’s been a steady decline, especially in those parts of systems where the average user has to communicate something exceptional to a computer. Clueless developers of the computer system “design” whatever sort of interaction pops into their minds, while the poor user of their system has to conform to these designs, or else. It’s like arrogant nobles assigning tasks to powerless peasants. It’s a one-sided conflict?the developer side side has all the weapons. while the users have to take their lumps and just grin and bear it.

But the Medieval world had its checks and balances, something we need in modern computing. In ancient Denmark, the laws of chivalry required that if a noble should ever duel with the peasant, the peasant had the right to choose the weapon. The nobles were trained in fancy weapons such as swords and dueling pistols, but the peasants had a preference for pitchforks and cudgels. As a result, any sensible noble went to great pains to settle disputes graciously with any peasant, no matter how gross and crude they might seem.

We need something like a cudgel to redress the balance between ordinary people and poorly crafted systems produced by thoughtless designers. Cudgels and pitchforks, however, could be found around any peasant household. Furthermore, there was a legitimate reason for them to be there. If the nobles wanted to eat, they could hardly outlaw pitchforks.

One way to fight the arrogance and insensitivity of computers is to use your own computer as your cudgel, but you don’t have to own a computer to be arrogant and insensitive. For those readers who lack a peasant’s pitchfork experience, I have catalogued a number of specific thrusts and countermoves. I’ve learned these tactics from the enemy, from the online and paper forms I’ve had to navigate to request support, report bugs, reconcile billing disputes, claim rebates, or register products.

1. Insist that any communication with you will have to go through your computer, and thus conform to the computer’s requirements, because “everyone knows that computers cannot be made to change in response to every trivial problem that people are having.”

2. The required information will have to go on a form, one copy of which you’ll supply upon written request on another form.

3. They will have to use the original form?no copies, please. If they should make a mistake in following the simple and convenient rules, they may write another letter and request another form. Without the original form, “our computer might not be able to read it.”

4. Every piece of information requested on the form must be supplied. Nothing must be left blank, even when you already have that information recorded accurately in your computer’s files. To leave something blank would “require our computer to spend extra time accessing the information.”

5. Where information requested duplicates information already in our computer files it must be identical, character for character, including spaces. If someone asks you why it must be identical, you say that “our computer will be confused if it checks the information and finds differences.” If they ask why the information is needed, inasmuch as our computer is going to access the original in order to check, you reply that “the computer may decide not to check, and we can’t tell in advance which cases it might check.” (This is true by default because you don’t really have a computer.)

6. Every item you fill in on the form must adhere strictly to our specified format, otherwise reject the form. Don’t accept alternatives that might be clear to human beings, because “they will require extra coding steps.”

7. The specified formats must be chosen to be unfamiliar to people, such as,
a. Last name first, first name last
b. Fill in all leading zeros, the more the better
c. Year, day, month
d. Local phone exchange, number, then area code
e. Zip code, followed by street address, then state and city
f. Numbers in scientific notation
g. Binary coded numbers
(And, yes, believe it or not, I’ve encountered each of these cases.)

8. Because you can’t be certain that the formats in [7] are unnatural to people accustomed to working with computers, require that each time a similar item is needed, a different format is requested. For instance here are some variations in the dates I have had inflicted on me:
a. 2009 July 17
b. 17/7/09
c. 17/07/09
d. 17 VII 2009
e. 17-JUL-09
f. 7,17,09
g. July 17, 2009?but be careful of this one, it’s almost understandable.

9. When numbers are needed, it’s best to have them be as long as possible. If they don’t have any long numbers, make up some. Since human memory is pretty reliable up to seven digits, it’s best to require at least 10 digits, but do not allow any internal punctuation. If you ask for 234-789-4001, they might get it right half the time, but 2347894001 will cut that percentage down to size. Also, every extra digit beyond 10 will pay huge dividends in erroneous forms, which can then be returned with rude notes implying inferior intellectual development. An effective technique is to pad out the number with large numbers of leading zeros, as in 00000002347894001. (How many zeros is that, anyway?)

10. If you can get away with it, use at least two pages, back-to-back, for paper forms. A second page gives lots of special possibilities, such as,
a. Information on the back that has to be copied onto the front, and vice versa.
b. Information on the back that’s needed to understand the items on the front, and vice versa. For instance the set of codes that are to be used on page 1 can be listed on page 2. This technique works well with pages on websites, too.
c. Consecutive pages should be printed on opposite sides of one very porous and translucent sheet of paper. This technique guarantees that material from the other side will show through when copying. It also allows ink to flow through from one side to the other. Naturally, you don’t allow pencil, and require both sides to be clear of extraneous material.

11. Because multipage forms allow copying from page to page, you have the opportunity to impose difficult copying tasks. For instance, on page 2 you can require copying the form number from page 1, just to make sure that “the two sides of the paper don’t get separated.” An appropriate form number is 1783562812354678-1A.

12. Limit names and addresses to 20 characters each?or 18 if you dare?but do not allow truncation. If Daniela Schimmelpfennig complains, tell her she has no right to have a name that confuses computers. Suggest that she change her name to something more reasonable. Or, simply truncate her name in any way you like? Daniel Schimmelp, for example.

13. When a limited field is required, allow far more space on the form than is allowed in the computer. For instance, if a number is limited to 12 digits, use a 13-digit space on the form. If possible, make no comment, but if your conscience bothers you, write an instruction saying, “For type A use leftmost 12 digits. For type B, use rightmost 12 digits.” Be sure there are several A’s and B’s on the form, thus creating doubt as to which is meant. This technique ensures that at least half of the forms will be wrong just as if you had given no instructions.

14. Where the required information is essentially unlimited in length, use a space that is patently too small. An excellent example is these instructions:
“Please explain your problem in your own words, giving all relevant information that might bear on our providing you with better service in the future.” Then limit the response to 40 characters and/or follow this instruction with a space no longer than three quarters of an inch.

15. If you can’t make the instructions actually contradictory, as suggested in [12], at least use sufficient jargon to ensure that they can’t be understood, as in [13]. If you do this well, the people using the form will feel like fools.

16. Jargon from [13] can be combined effectively with instructions given in the form of computer programs as in
“If the audit interval is greater than the contemplated discount, then enter the appropriate rate code from the conversion table on page 2 in place of the discount code, unless the audit interval falls within the operating system recovery. Or line 17 of page 2 will be left blank when following the instructions on that page under item 2.1.7.3.9.2.4/a.”

17. When giving programmatic instructions, it is best to have at least one backward reference, such as (on line 5-1 on page 2), “If this figure is negative, change the value in line 17B., page 2 to zero.” Working in ink, this is sure to confuse, but just in case they have the sense to make a trial copy, include at least one cyclic reference. For instance, back on line 17B on page 2, you could say, “if this value is zero, change any negative value online 5.1, page 2, to positive.” (Notice the inconsistent notation: 5-1 in one place, 5.1 in another. Inconsistency always helps increase confusion.)

18. Set rigid deadlines for receipt of the form, and indicate that if the deadlines are missed, you cannot guarantee any particular date for a response. Then mail the blank forms so they arrive on the deadline date. (The next day is not as good as some people just give up in despair. It’s better if they try to meet impossible deadlines and spend much money on special postage.)

19. Naturally, the forms may not be folded, spindled, or mutilated in any way.

20. Following these rules when responding to cyber crud ought to equalize the odds a bit in the never ending battle of peasants against the nobles. But just in case the above 19 rules don’t quite convince them that you actually have a computer, here’s one more that’s sure to crush all the remaining resistance:
Make sure your form is 1 mm wider than the handy return envelope you provide.

A Word to Designers

Maybe next time you design one of these interfaces, you’ll take off your cloak of nobility and, for a few minutes at least, don the shabby rags of us poor peasants who are forced to use your product. You can do that, because, like me, you’ve also been on the peasant’s side more than you’d like.

convert this post to pdf.

The Technology of Cooperation

convert this post to pdf.

IT professionals must be good team players, but what does that mean?

For one thing, it means they must know how to come into a situation and quickly cooperate and gain cooperation, but cooperation takes many forms. It’s not sufficient to want to cooperate. You must also know how. This column is about the technology of cooperation.

People
Most people, when they think of cooperating, think of everybody doing the same thing?like all pulling on the same rope in a tug-of-war or rowing in the same Roman galley, perhaps chained to the oar. When you consider cooperating by sharing people’s direct labor, first try to categorize the situation into one of these two:

1. The job is well understood and easy to communicate to a newcomer.

2. The job is fuzzy, or not understood at all, or complicated.

In the first situation, as in a tug-of-war, it is relatively easy to move people about from one work group to another. The amount of productivity in this situation is roughly the sum of the individual productivities. Ten people can tug ten times as hard as one. Many managers think that adding IT professionals is just like adding bodies to a tug-of-war team.

But even a tug-of-war is not so simple, for those who are experts at it. Given roughly equal weights on both sides, the team that understands and uses technique will win every time – and can even overcome substantial weight deficits. Adding a new member to a skilled tug-of-war team will not add proportionately to their success. Indeed, unless the new member understands their technology and system of communication, the addition of another body is likely to reduce their total tugging effectiveness.

When the job is fuzzy, and ideas are needed more than simple tugging power, the addition of a new member can be helpful if the team is ready to accept new viewpoints imported by the new member. Experienced IT professionals, however, know how hard it can be to have their better ideas heard when they’ve just started a new assignment. It can be horribly difficult to integrate a new person. Time and “wasted” effort must be allowed for in such additions, especially as the job grows more complex.

Thus, if quick addition is needed, adding people willy-nilly is not the answer. This observation was the essence of Brooks’s Law – adding people late in a project makes the project take even longer. Adding them early, however, which allows time for this “wasted” effort of integrating the new people, can, in the end, make a project go faster.

Any IT professional who is thrown into a project late and expected to make things go faster needs to be aware of Brooks’s Law and needs to communicate to the management what kinds of delays are to be expected. Moreover, each of us IT professionals needs to master the arts of quickly learning what the job is about and how the existing team communicates.

Programs
When we import a program or a piece of hardware to a project, we import technology in a form that may seem more acceptable than a new team member might be. This is the dream of reusable software. But when the team members feel that their own technology is an extension of their own egos, programs may not be portable at all. Instead, they run into the “not-invented-here” brick wall.

Of course, even when a team is willing or even eager to import software or hardware, it may prove poorly designed for portability. In general, portability of complex technology doesn’t come by accident, but by design and by testing of the design. Even for well-designed technology, there is a break-in period which may or may not be shorter than the time taken to add a new member to a team. Of course, the payoff for an imported technology can be huge, but only if it’s adopted and used.

Some IT professionals come on the job with their own tools, not anticipating the amount of difficulty they will experience getting the existing team to adopt their “superior” tools. If you feel that your tools add to your value as a IT professional, you must master the art of introducing tools – especially to people who may be insulted by the very idea that you might know something better than what they already know.

Perceptions
Ideas or ways of thinking can be the most portable of all kinds of technology, as long as the ideas or perceptions are not labeled too clearly as “belonging” to someone. The rule here is perhaps the most important that a technically-oriented IT professional can learn:

There’s nothing you can’t accomplish if you aren’t concerned who gets the credit.
If a project is successful, there’s always enough credit to pass around.

Points or Perceptions
Much of what we do on a job is to win the approval of the management, or of the customer. We call this “scoring points.” Success on a job depends very much on the ability to score points, in whatever game management happens to be playing. If they are playing a good management game, then the more points you score, the better the job you must actually be doing.

But bad managers give points for the wrong things, and if you work under such a point system, you soon become a poor performer. In any case, though, in work as in life:

Points can never be passed directly from one person to another.
To pass points, you must pass people, programs, or perceptions.

In general, sharing perceptions may be the easiest way to cooperate. Moreover, if you don’t share perceptions, it may be almost impossible to cooperate. So, when you enter a new group and want to cooperate, it’s best to start by listening?and learning how other people perceive the world.

convert this post to pdf.

“Finally! A book about software testing written by someone who actually understands software testing. I consider Jerry to be the greatest living tester. Jerry tests everything. Jerry tests me. . . . It’s been forty-seven years since Weinberg first wrote on software testing, and his ideas today are still ahead of their time. Read this and get your head straight about testing.”
?James Bach, consulting software tester, author of Lessons Learned in Software Testing

“This concise and cogent book?a gift to testers?explodes myths about what testing can and can’t do.  We’ll each want at least two copies?one for our own bookshelves, and another to hand to our clients so that they can better understand precisely how we can help them.”
?Michael Bolton, tester, trainer, and consultant, DevelopSense

“If the wiring in your brain needs a better programming and testing, read this.”
?Pradeep Soundararajan, consulting tester, author of Tester Tested! blog

“Perfect Software will be a tremendous asset to anyone who tests software and keeps having to explain what testing can and cannot do. Engagingly as always, Jerry Weinberg explains the essence of testing for anyone to understand. He makes a compelling case for doing enough testing?but not too much. I can’t wait to give Perfect Software to all my clients!
?Fiona Charles, test consultant and columnist

convert this post to pdf.

“1,073,741,823 lines of correct code, but one unknown bug is going to send us into that Sun.”

“Do not panic.” Peri said, using Calming Voice. “We have adequate time to find it.”

“Peri is correct,” echoed Setho. “Remain logical. We must divide the code in half and allow the simulator to find which half contains the defect. Once we repeat this process 30 times, we are guaranteed to find the culprit.”

“I know I couldn’t have designed this ship,” I said, “and you’re absolutely right about the process. But you have no concept of time. Each test will cost us 10 minutes, and in 4 hours we’ll pass the point of no return. Yes, an hour after that, we’ll be able to unlock the controls, but it will be too late. Perhaps you Zaard will be satisfied to choose your personal sunspot for cremation, but it doesn’t do much for me.”

“We will remember our ancestors,” said Peri, twisting into the Zaard meditation posture.

“Yes,” Setho agreed, in posture as in words. “Termination of existence is the only logical conclusion, so remembrance of ancestors is the only logical action.”

“Don’t go to sleep on me. There is a way, if we’re lucky.”

“Luck is a human concept,” Peri said, his voice slowing and sinking. “Do you really think you can find one out of a billion lines of code by luck?”

“Peri,” said Setho’s Chastizing Voice. “Please be respectful. We must not interfere with his religious beliefs, no matter how preposterous they are to us. Proceed with your foolishness, John, if you wish. We shall watch, and pray for your soul.”

“I could use more help than that. I figure that if I can guess a division of the code that puts the bug in the smaller half, I can accelerate the process.”

“Your assumptions are incorrect. Though you name it ‘code,’ we know it is Leethaa, not some simple computer instruction.”

“Doesn’t matter what you call it. If we find the Leethaa, or code, that’s wrong, we can change it through the console.”

“True. We can change it, but if we merely know it is wrong Leethaa, that still does not mean we know what is right Leethaa.”

“Of course you’ll know. You built it.” Peri and Setho exchanged another look, and the odor in the compartment changed. “I’m just a passenger, remember, like any human, taking advantage of your intergalactic freight service. You’re the designers.”

Setho turned several of his eye to me, but spoke to Peri. “Since we are all to end our existence, in a few hours, can there be harm in telling him?”

No, the memories of our ancestors will not be harmed.”

“Tell him what? And don’t talk about me like I’m not here.”

“We Zaard are not the designers of these ships. We, too, are passengers, enjoying these gifts from our ancestors, countless time in the past. We do not know how the Leethaa operate, but only how to repair them when they fail.”

I was quickly rearranging all I thought I knew about the Zaard. Too bad I wasn’t going to be able to tell anyone. “Then how can you repair it?”

Setho was about to reply, but Peri raised an appendage and used the Interrupting Voice. “We use the binary search, using the simulation logic, as I explained. When we locate the offending Leethaa, we alter its state – le to eth; eth to aa; aa to esu; esu to culara; culara to le. Those are the five possible states, as I believe you well know from observing us through these months we have flown together.”

I didn’t know they had been watching me watching them, but what did it matter now. “Fine,” I said. “So once I locate the right Leetha through my guessing, you can make it right.”

“True, but guessing depends on luck, and we do not believe in luck. You will not find it.”

“Moreover,” said Setho, “even if we were to assume your false premise about the existence of luck, then we would logically have to accept the existence of bad luck as well.”

“And with bad luck, your guessing process would actually take longer.”

“Hey, we’re going to fry anyway, so what more do we lose if it takes longer? Besides, I need your help.”

“We cannot help with luck. We can only remember our ancestors.”

I swept my gaze over the full circle of consoles. “Then call it ‘intuition,’ if you don’t like luck. You two know a lot more about this vehicle than I do, and your guesses may actually be better than mine.”

“But we already told you, we don’t believe in guessing.”

“Well, one thing for sure you do believe in is arguing, and arguing for sure isn’t going to save our skins. While we’ve been having this lovely philosophical discussion, I’ve been running my first guess. It should be done in 30 seconds.”

“We noticed,” said Setho, who seemed the more alert of the two. “… And there it is. You see, it seems that the flaw is in the larger of your two parts – not the smaller one chosen by your guess – and now the process will take even longer.”

“Okay, so it was bad luck. But if my luck turns better, we can make up the lost time.”

The two Zaard merely exchanged more glances that I couldn’t interpret, so I made my second guess. “I think the transporter code is the most likely place, so I’ll make that one of the halves.” I entered the cutting point and restarted to testing process. “If it’s in there, we’ll be down to less than a million lines of code.”

But it wasn’t there, and by the time we found out, I had already lost 20 precious minutes without reducing the problem significantly. Setho and Peri didn’t seem to mind, lost as they were “remembering their ancestors.”

I started feeling warm, even though I knew that the sun’s heat would not be affecting our interior temperature for another couple of hours. Setho must have noticed.

“Do not be distressed, John. Having remembered our ancestors, we are now at peace. Do you not have ancestors to remember?”

“Most of my ancestors aren’t worth remembering.”

“How sad. No wonder you solve problems by guessing. But surely your ancestors must leave you some worthy memories.”

I paused to enter my third guess. It was even more risky, but I had to make up time. I felt it was more of a gesture than anything useful. Three hours and thirty minutes – 21 guesses – was all that was left.

“None of them ever knew the Zaard even existed, so none of them ever toured effortlessly around the galaxy. What memories could they leave that would do us any good?”

“True. Your history is so strange to us that I never thought that you might not have useful memories. How unfortunate that we know each other better only now.”

“But your ancestors’ memories don’t seem any more useful than no memories at all, if they can’t help fix a failure.”

“Oh, but they can. We have memories of all ship failures in the past, and how to repair them.”

“Then why aren’t you fixing this one?”

Setho gave me a look that even on his/her strange face seemed to say, “Don’t be a stupid Human.” What s/he actually said was, “Because our ancestors never encountered a bi-quinary star system such as this one, so there is no memory of this particular failure.”

“But there were failures before?”

“Of course, but not this failure.”

“And how often do you have these failures?”

“Among the entire fleet, perhaps once every thousand of your years. Would you like to know exactly?”

“You mean you have a record of them?”

Peri now joined the conversation. “Of course. We told you that we remember our ancestors.”

“All of them?”

“Yes, of course. What would be the logic of forgetting errors. We have a saying, ‘A Zaard who forgets his/her ancestors forgets how to stay alive.”

My mind was racing, but my mouth was having a hard time keeping up because I was trying to keep my chest from swelling with hope. “Okay, how many have there been, since the beginning? Or is that too hard?”

“Why should it be difficult? Approximating the time, in the past 180,000 years, there have been 674 distinct ship errors.”

I did the arithmetic in my head. “That’s a mean time between failures of about 250 years.”

“267,” Peri corrected.

“Not bad, but not perfect, either. Maybe your ancestors weren’t as perfect as you thought.”

“We do not think our ancestors are perfect. If they were perfect, we would not have to remember them. But, to their credit, these failures are in a fleet of more than a million ships, so the mean time between failures on any one ship is greater than 267 million years. They are not perfect, but they are very, very consistent.”

I was impressed, but I wasn’t going to show it. “Sure, that’s great. But we’re on one ship, and it’s failing right now.”

“Fortunately,” said Setho, “the signals have already been broadcast, so we will be remembered. You will have the honor of becoming the first Human Zaard ancestor.”

“Oh, thanks, I hadn’t thought about that. But I’d rather live and be forgotten, so what else can you tell me about these errors?”

“What else would you like to know?”

“I’d like to know the distribution of errors across the various Leethaa components – like, which component has had the most errors per element?”

Peri paused for a moment, then announced, “That would be the Nisoog-arthl component, with 402 of the 674 errors, if I have remembered our ancestors honorably.”

“You have,” said Setho, “Most honorably.”

Now my heart was beating audibly, and fast. “And how large is the Nisoog-arthl?” I’m not superstitious, but I crossed all my fingers as I waited for their reply.

They replied in unision, in the Data Voice, “The Nisoog-arthl comprises Eight-hundred seventy-seven thousand nine-hundred and twelve Leethaa.”
As they spoke, my pad displayed the number: 877,912. I could do the necessary calculation in my head. “That’s it, then. One more guess and we’re done!”

I stopped the current simulation, now useless, and entered the boundaries of the Nisoog-arthl as my fourth guess. Now all I had to generate the patience to wait ten minutes to know whether I would live or die. Since Peri and Setho showed utter disbelief, I explained.

“You told me that your ancestors were very, very consistent, but not perfect. When they built these ships they didn’t make many mistakes, but they did make some. And if they were as consistent as you say, then their mistakes would be consistent, too. They would consistently make most of their mistakes in the same parts of the Leethaa. And the one part they most consistently made mistakes in was the Nisoog-arthl – so I’m guessing that’s where this mistake will be found. We’ll know in seven more minutes.”

“Yes, that’s quite logical, in a strange sort of logic, but what good will it do?”

“Yes,” said Peri, also using the Query Voice. “That was a logical guess, but that only narrows the problem down to the Nisoog-arthl. We have no more refined data, so what logic can you use for your next guess?”

“But if the error is indeed in the Nisoog-arthl, I won’t need any more guesses. I can switch to a pure binary search and be sure of narrowing the search to a single Leethaa in the remaining divisions.”

“Aaah,” they said in the Simultaneous Voice, “so in the end you can be logical.”

“And in two more minutes,” Setha continued alone, “we will all know logically whether or not we will visit that sun.”

convert this post to pdf.

“England, though at present enjoying a very high state of prosperity, still shows some symptoms of a decaying nation. Propose to an Englishman any principle, or any instrument, however admirable, and you will observe that the whole effort of the English mind is directed to finding a difficulty, a defect, or an impossibility in it. If you speak to him of a machine for peeling a potato, he will pronounce it impossible; if you peel a potato with it before his eyes, he will declare it useless, because it will not slice a pineapple. Import the same principle or show the same machine to an American, or to one of our colonists, and you will observe that the whole effort of his mind is to find some new application of the principle, some new use for the instrument.” — Charles Babbage, 1852

As early as 1852, Charles Babbage could see symptoms of decay and infer from them a vision of future performance. In so doing he provides a perfect description of the blaming style of communication, which emerges in ‘decaying’ organizations–be they nations or software engineering organizations. What is a “blaming style of communication,” and why is it important in systems development?

What Is Congruence?

Congruence is a concept that describes the human experience of alignment between the internal and external–what is thought and felt (the internal), and what is said and how it is said (the external).

In order to operate congruently in the world, you need to take into account three general factors: self (the internal world), other (the immediate external world of people), and context (the larger external world of things, structures, processes, laws, and cultures).

• Self: You must consider your own needs and capabilities. Suppose you are a manager who doesn’t trust anyone else’s judgment, so you try to attend every technical meeting. Doing this, you’re likely to overload all your available time, and then be unable to do the managerial job, nor to make real technical contributions in any case.
• Other: You must consider the needs and capabilities of other people. For instance, if you are a programmer who refuses to be bothered to write readable code, then testing and maintenance of your code will be a great burden, if not an impossibility.
• Context: You must consider the reality of the context in which you are operating. For instance, if you are a manager who insists on sticking with an old design that no longer has the capacity to handle the task, your project may be doomed no matter how hard everyone works. Or, if you are a manager in a start-up company and spend money as if the company had a billion-dollar cash balance, your organization may be out of business before its software product is ready for market.

Congruence is integrity at the most basic level and thus has immense value to a project and each individual in it. Without integrity, we cannot build trust; without trust, we don’t feel safe; without safety we have a hard time being congruent. Thus, congruence reinforces congruence in a powerful loop which improves the chances of producing a quality product, on time, and within budget.

On the other hand, the same loop causes incongruence to reinforce incongruence. If a project is allowed to ride such a downward spiral, the integrity of information is destroyed. Soon it becomes impossible for anyone to know what is really happening. Such projects invariably fail, and when they fail, they are invariably found to have been keeping two sets of “books.” Their external picture is not congruent with their internal picture, and they die. Or worse yet, live forever–the living dead.

If congruence is so important for project success, why aren’t all projects congruent? One reason is that congruence is not without a price. Another is that congruence usually involves risk. The level of risk is somewhat contingent on the kind of congruence being demonstrated–mental or emotional.

Mental congruence

In the United States, it’s relatively easy to express our thoughts with out too much incrimination–freedom of speech was a foundation upon which the country was built. Even so, there may be a price to pay for “speaking up.” For example, differing with a colleague or someone in authority at the wrong time can put us on a fast track to isolation, reprimands, reduced opportunities, and subtle door closings. Thus, we’ve all learned the importance of being careful about what we say where and to whom. Saying the wrong thing can lead to heated debates, followed by proclamations of who is right or wrong and who is good or bad. At that point, we’ve lost most possibilities for enhanced understanding and effective communication.

Emotional congruence

In our culture, feelings are reserved for athletic events, celebrations, funerals, near death experiences, deeply felt spiritual experiences, fights, and exchanges between intimate others, the very young and the very old. We even have many feelings about our feelings and some of the strongest have to do with shame and embarrassment over having them. Feelings are personal and lie close to our heart, where we are tender and vulnerable. No wonder we have all become so skilled at denying our feelings–which necessarily makes us incongruent.

Suppose you are a developer who is scared that you won’t be able to deliver a product when you promised. You try to tell your manager about your fear, but he tells you in no uncertain terms what will happen to you if you don’t express more confidence. “Why are you so negative? Aren’t you a team player?” One way to protect yourself from such negative responses is to live in your head. Perhaps you say, –”It’s just an estimate; I’m not attached to it,” meaning you won’t be hurt because you’ve distanced yourself sufficiently to ward off anything that might hint at rejection. But, though you deny your scared feeling to your manager, you still feel it, squashed down inside. You can stand back away from your ideas, but you always remain standing in your feelings. And, of course, you have been incongruent, and deprived your manager of your best information.

When you share your feelings, your heart-self is being presented to the outer world–exposed to the elements. When you’re scared and express your fear while maintaining consideration for the other person (your manager) and the context (the project), you are being congruent. Your critical issue here is, “Can I share my feelings and still be in control?” If the environment of your project is blaming, it threatens to remove your control if you tell the truth–so the temptation to lie about your feelings and your ideas increases. That’s why blaming cultures lead to “double books,” and that’s how they lead to failure.

What is Blaming?

In a congruent organization, your manager asks, “Where does your project stand?” and you answer, “I’m rather scared that I’m not going to make my schedule.” This starts a problem-solving discussion, out of which the two of you make new plans to get the project back on track. In a blaming organization, however, your manager may well tell you that only inferior people lack confidence. In that case, problem-solving will be replaced by blame-avoidance.

From a writer’s point of view, congruent interactions aren’t very dramatic; people just act sensibly, are considerate of one another, get their work done, and enjoy what they’re doing. That kind of behavior might not make as good a soap opera scene as your manager throwing a tantrum and you cringing in the corner, but it definitely makes a better project.

Not that a blaming culture conducts every interaction in a dramatic, blaming way. Under ordinary circumstances, congruent coping is the rule, but if circumstances were always ordinary, we wouldn’t need managers. When feelings of self-esteem are low, they are manifest much more dramatically in characteristic incongruent coping styles: blaming, placating, being superreasonable, loving or hating, and acting irrelevant. We can’t deal with all of these in a short article¹ , so let’s discuss blaming, perhaps the most common and most directly destructive of the coping styles.

Under stress, people tend to lose their balance, and one or more of these three essential components may be ignored, leading to a characteristic incongruent coping style. For example, when people fail to take other people into account, they fall into a blaming posture. Here is a typical blaming action you may see in software organizations (italicized words are stressed in this style of speaking–because multiple stressed words in a sentence are a linguistic sign of blaming²):

Manager, as programmer arrives late for a meeting: “You’re always late. You never show any consideration for other people.”

Why is this incongruent? If the manager really is feeling and thinking that the programmer is always late and inconsiderate, isn’t she being congruent by saying so? Yes, but that isn’t what this manager said. She didn’t say, “It’s my impression that you’re always late to my meetings.” Instead, she pronounced her impression of lateness as if it were a scientific fact, never offering the possibility that the programmer might have a different impression. She generalized experience in her meetings as if they necessarily applied to all meetings, never allowing for the possibility that her experience might not be the only one that counts.

If the manager really is feeling and thinking that the programmer is always late and inconsiderate, she might say, “I think that you’re always late, and I feel that you’re not being considerate of me and the others. Is this your perception, too?” (And leave out the stressed words.) Even better management style would be to give the programmer a chance to provide a different perception before launching into interpretation. At the very least, that prevents embarrassment in situations such as the following:

Manager, as programmer arrives late for a meeting: “It seems to me that you’re always late. Is this your perception, too?”

Programmer: “Yes, and I feel bad about it. The reason I’m always late is that I have to donate blood for my 9-year-old son, who’s dying of leukemia, and the only time they take donations is just before this meeting.”

Manager: “I’m sorry about your son. I didn’t know about it. Let’s figure out a new meeting schedule so you don’t have to be late.”

More generally, it allows for the possibility that there may be other considerations that count besides those of this one manager. For example, perhaps the programmer is coming from a meeting with customers–a regularly scheduled meeting which overlaps the manager’s meeting.

But what if the programmer really is always late, with no reasonable explanation? Isn’t the manager then entitled to blame the programmer? Not really, because this situation is not about entitlement, but about getting the project done. For that purpose, the problem is most effectively resolved using a non-blaming confrontation with the facts about the unacceptable behavior. By foregoing blaming, the manager keeps the communication clear and open, maximizing the chance that the programmer will receive the intended message. And, of course, receiving the intended message maximizes the chance (though it doesn’t guarantee) that the problem will be solved.

When blaming, problem-solving is less likely because the facts of the case become a minor issue–the major issue in blaming is “who is important and who is insignificant.” When blaming, a person is saying, in effect, “I am everything, you are nothing.” Of course, this stance comes not from really thinking “I am everything,” but just the opposite. Directing the attention at another person–and blaming is often accompanied by a pointed finger–is a self-protective device to distract others from the inadequacy the blamer feels.

Like all incongruent coping, blaming is reinforced by feelings of low self-esteem. When you blame, you attempt to build yourself up by tearing down others because you don’t have the confidence that you can amount to much–or even survive–any other way.

Blaming usually fools people who are unsophisticated, or whose own self-esteem is at a low ebb. The knowledgeable observer, however, sees the amount of blaming as a sure measure of how inadequate the blamer feels. Moreover, if blaming is the preferred project communication style, then it becomes a measure of how far an environment has degenerated–how little communication is being directed at the project’s issues, compared to the amount that is being directed to puffing up the communicator’s weak self-esteem.

In a blaming organization, it’s not merely the managers who blame, as illustrated by these examples:

Programmer, when asked by a manager to volunteer to talk to a job applicant: ‘Why don’t you do it yourself? I’m not going to do your job for you. If you were better organized, you wouldn’t need to ask me such things.”

Customer, when project manager asks about the possibility of revising the requirements: “You never get the requirements right the first time. If I told you once, I told you a thousand times: Do the job right the first time, then you won’t bother me with revisions.”

(To test your understanding of the blaming style of communication, you might try to improve the congruence of these examples.)

How Blaming Hurts A Project

Of course, people are not perfect, so it’s impossible to conduct a large project without occasions on which people cope incongruently. Normal project management can deal with these situations–when they are exceptional. But when the whole environment encourages blame, each new situation further elaborates the incongruence. Fred Brooks³ once asked, “How does a one-year project get to be two years late?” His answer was “one day at a time.” Our answer is “one incongruent communication at a time,” as the following example illustrates:

One of the developers was developing a module that produced a printed report when it was tested. The manager put a lot of pressure on the developer to be ready on time, with no excuses allowed. The programmer produced the report, and the manager was pleased (though he didn’t show it, of course–it was “just an expected part of the job” in this blaming culture).

A month later, other people tried to use this module and discovered that it was not finished after all. The developer had used a word-processor to produce a fake report that looked just like a correct test report should look. He thought this would buy him time (it was a month, after all,until anybody found out) to finish the module. Unfortunately, since he was in over his head, a month wasn’t enough time.

The manager blamed the programmer. The programmer said nothing, because in this culture of blame, saying something only brought further streams of blame down on your head. The person who reported this incident said that in this organization, failure is not allowed under any circumstances. People who have problems in a project and can foresee slippage are unable to cry HELP! and receive appropriate assistance. According to the managers, each programmer is responsible for meeting the deadlines that the programmer agreed to. Inaccurate estimation is “not allowed” and perfection is to be achieved from day one–otherwise you are put in the pillory of blame. In this situation, fake test reports are the rule, not the exception.

Blaming is the dark secret underlying the failure of many projects. A blaming culture hurts a project in at least six major ways:

1. People commit to plans they know they cannot achieve, at least to delay blame.
2. People hide facts that managers need to control the project, as in the above example.
3. When problems are finally revealed, people avoid coming forth with creative solution ideas, for fear they will be blamed if the ideas don’t work, or simply appear dumb at first glance.
4. In day-to-day operations, a major portion of everyone’s effort is devoted to positioning themselves so they will not be accused when the time of reckoning arrives.
5. Those people who somehow feel safe enough to focus on the job at hand find themselves spending large amounts of time checking up on the reliability of others’ communications.
6. People feel bad most of the time, and spend a lot of time fiddling with unproductive tasks or simply staring at the walls.

What Incongruence Looks and Feels Like

Organizations can be changed from a culture of blame to a culture of congruence. To make this change, the first step is measurement, or at least detection–but how to measure blaming? Actually, an experienced consultant can detect a blaming organization within a few minutes of contact, because symptoms are everywhere. Indeed, people within the organization already know it’s a blaming culture-but of course within a blaming culture, blame is undiscussable, and moreover, the undiscussability is also undiscussable.⁴ Paradoxically, the existence of undiscussability makes blaming easy to detect. The manager of one project issued a memo saying that there would be no more discussion of project morale, and that he would entertain no questions on the subject because everyone should be grateful to be working on such a terrific project. This could happen only in a blaming organization.

Executives

A culture of blame usually starts at the top. Members of the top level of management are inclined to see the other people in the organizatation as the source of all problems. The employees are seen as “ungrateful” for the jobs, pay, benefits, and opportunities management has bestowed on them. They are seen to “lack an appropriate work ethic,” “not know the value of a dollar,” “have authority problems,” and “resist change.” These perceptions leave upper management in a predicament: “Do I fire them, or do I fire the people who hired them?”

Such managers feel that they are trying to realize a vision without getting the necessary support, which leaves them out on a limb. The internal kinesthetic experience of these executives is normally a dull and chronic headache-unless the profit margin is really down. In that case, they have more acute feelings, like pain in the chest and burning in the gut. Their low self esteem reflects outwardly in the form of frequent downsizing, re-engineering, avoiding serious problems, futile memos, and, of course, humiliating of subordinates. Towards themselves, they often practice addictive and self-destructive behaviors (which cannot be discussed, but are alway the subject of gossip).

Middle Management

When the top leadership is incongruent, middle managers constantly receive mixed messages. Project managers are told of their importance, then find that their seniors have bypassed them to intervene directly in projects or change the rules without consulting them. They feel as if they are living on a roller coaster–unable to predict whether a particular day or week will be an upper or downer. After being publicly humiliated a few times, they decide their best strategy is to try to stay out of trouble by not ever rocking the boat. Even though they cannot perform at their best, they try to appear important and extremely useful.

In the blaming organization, top managers try (perhaps unconsciously) to teach their middle managers their own blaming attitudes. When one project manager complained of her inability to get the developers to work faster, the Vice-President of Development said, “If your dog won’t jump high enough, get a bigger stick to beat it with.” Living in hail of such incongruence from above, middle managers’ survival issues stay close to the surface. As they did when they were children, they figure out how to either appease, please, or avoid the power owners. By so doing they insure their survival–and pass the blame on to lower levels.

Employees

At the bottom rung of a blaming organization, employees are usually looking for someplace else to work unless the company is in a stable condition with little competition-or if their retirement is within view. The way to survive is to hide out and appear only to pick up a regular pay check.

Employees are discouraged from thinking creatively–new ideas are interpreted as blaming the management or attempting to usurp their power and prerogatives. Employees are not rewarded for industriousness–but they are frequently punished for perceived “laziness.” Employees cannot seem to find their managers–except when there are problems. Then, the major efforts are directed as attaching blame rather than solving the problem at hand.

The style of blaming varies from organization to organization. It can be harsh, vindictive, direct or indirect–but it is always contagious. Some organizations have polished their blaming style to a high degree of subtlety–without raised voices, merely by a look, or a memo, or an e-mail message, or a phone call, or a visit if things are really bad. In other organizations, the blame is loud, angry, and frequently done in front of an audience of peers–ensuring that all get the message of who is right, who is good, who is in charge, and who should become invisible.

In such an environment, defensiveness becomes pervasive. To those without formal power and authority, it seems that those with power really don’t care about them–and would banish them with no feeling at all. Thus they feel justified in retaliating (in advance, and in secret), and in avoiding their managers and their problems.

Regardless of the style, blaming from the top always generates fear, malaise, errors, accidents, and passive-aggressive responses from the bottom. Those on the bottom feel small and act from a place of powerlessness. The lack of emotional safety effectively erodes the trust level and makes any attempt at congruence extremely risky. This envirorunent sounds awful and it is–both for the person who has regressed into emotional immaturity and, sadly, for the person at the top who is doing the blaming.

Those on the bottom of any large organization can easily come to feel a sense of dependency on those above them in the hierarchy. When blaming is the primary mode of dealing with people, this dependency is exacerbated. Then, out of a feeling of dependency, people easily generate a feeling of hostility. As this hostility grows so does the debilitating experience of shame–that overly critical judge that lies latent in all humans.

What Congruence Would Look/Feel Like

Most people who have experienced a congruent organization won’t tolerate the misery of working in a blaming organization. But many people haven’t ever had that experience, and have a hard time believing what a congruent organization is really like. Let’s look at what would happen if a healthy dose of congruence could be magically applied on a large scale to an incongruent project organization.

Executives

If we could magically install congruence in the internal programs of those blaming executives, their style would shift dramatically. For example, if they would truly consider the others involved in their communication, they would be more likely to believe in the intent of people to contribute, to be productive, to belong, and to learn–and would take deviations from this ideal as evidence of ineffective management. Their belief in the inherent value of all people along with a healthy respect for the constraints of the work context would engender energy, hope, appreciation, understanding, and gratitude among their employees.

An executive who truly does not believe in the good intentions of the employees will be likely to say, ‘No excuses! You will get this done on October First.” But, with employees whose intentions are bad, this style (or any other style) isn’t really going to work.

A congruent executive who truly does believe in the good intentions of the employees will be likely to say, “We need this badly by October First. What do you need from us to help get it?” This kind of mutuality and support enlivens a genuine “can do” feeling that increases the chance that a project meets its goals–and that nobody has to make false promises to escape abusive blaming.

When the top level managers sustain their commitment to congruence, they see that most workers appreciate the opportunity the business provides them in developing skills, meaning, relationships, and monetary rewards. They also know how to cope when the occasional worker doesn’t seem appreciative or even productive. Managers who know how to use their power congruently generally get the results they seek–not perfection, which they know not to expect.

These leaders know they have a special kind of power–power they use with awareness and sensitivity. They do not resist accountability to those they lead, but demonstrate the same level of integrity they seek from others. And if they cannot match the levels of commitment they request from others, they are open about that. They know they are sometimes going to be weak and vulnerable and need support–perhaps even to see the value of their own visions. They use their awareness of this human reality to nurture their capacity to empathize and to have compassion for themselves and others.

Congruent executives know that their principal job is developing their organization’s capability, not just pushing the same old shoddy products and services out the door. They involve themselves seriously in organizational improvement efforts while simultaneously involving others in the organization to ground these efforts in real-life, practical operational input and decision making. They know that synergy is needed for organizational development, and they know that synergy comes from high quality connections among people–regardless of level.

Middle Management

When the top folks begin to operate from congruence, the middle managers receive direct, clear messages–not mixed messages with double meanings. Communications are more open, making it is easier to know more about what’s really going on. Given higher quality information, they know more about how to be useful, so they can more easily join their leaders in their visions. Knowing more clearly the strategic directions desired and feeling that they count in this process frees them to contribute more generously and thoughtfully–rather than merely playing safe. Success becomes a goal that all can share.

Given their unique vantage points, middle people have useful input to assist in predicting problems, projecting realistic time lines, and forecasting trends. What they see, hear, think and feel is valued, and they are in a position to initiate behaviors that prevent project weaknesses from growing into project failure. They know the necessity of interdependence, so if major problems do develop, they can be counted on to provide–and seek-truthful information. They are not ashamed or afraid to work for those who employ them. Indeed, they have pride about their commitment to the organization–and know it is a commitment not so much as to schedules and budgets, but to the truth about schedules and budgets.

Because congruence at the top trickles down, middle managers take notice of the difference in their leaders. They respond to the modeling by passing it on to their constituencies. Everyone in the organization knows what is at stake in doing each job well, so everyone feels safe to tell what is wrong, what is getting in the way, and what is needed to fix it. Honest reporting of facts and feelings is genuinely appreciated, and do not put people at risk of being humiliated or losing their jobs. That’s why congruent organizations deliver their projects as promised.

Congruent middle managers encourage high quality communication. Their belief in people’s ability to learn and change towards more congruence make those around them responsive. With congruence radiating from the center of the organization, everyone can have a place, position, and function of importance and value–so things get done, and done right.

Employees

Working at the front line of a business where the top leadership is congruent, is entirely a different experience from working in a blaming organization. Commitment and energy are the norm, not the exception practiced by new employees until they “learn the way things are around here.”

Congruent organizations hold to an ideology that doing well in the marketplace is connected to doing well with employees as well as with customers. The perspective of the leadership includes a global consciousness about the existence of multiple non-linear factors, the importance of connections among all the various parts of the whole, and the necessity of all parts knowing their value. Workers feel that this is a company going somewhere, where growth is a natural state and everyones’ efforts count.

Workers in a congruent organization tend to have a long range view and can usually maneuver as needed to meet the changing needs of clients and customers. Employees trust that what they see and hear is real. They share in the enthusiasm of creating a future. They may not like everything that happens–for instance, they don’t always feel that they are rewarded adequately for what they give–but they don’t feel that there is a chronic pattern of undercutting, diminishing, discrediting, and devaluing them and what they do. They can risk congruence knowing that it will act as a catalyst for optimizing successful outcomes that benefit everyone.

Congruence is the bright secret underlying the success of many projects. A congruent culture helps a project in at least six major ways:

1. People commit to plans they know only after open negotiation, so plans are more likely to be realistic in the first place.
2. People come forth readily with facts that managers need to control the project, as soon as they are known, so managers can act early and act small to correct the problems.
3. When problems are revealed, people readily come forth with creative solution ideas, increasing the chances for quick and effective solutions.
4. A major portion of everyone’s effort is devoted to getting their jobs done, and helping other get their jobs done.
5. Because human fallibility is considered normal, an appropriate–but small–amount of time is spent assuring the reliability of communications.
6. People feel good most of the time, and thus are productive most of the time.

Congruence in Large Systems Development Efforts

In the course of developing systems, people engage in numerous acts of communication–about requirements, schedules, interpersonal problems, designs, progress, and just about anything else. That’s why effective individual communication is important in all projects, large and small. That being said, effective communication becomes even more important as the size of the development effort grows. The number of necessary communications goes up non-linearly with the size of the project, so the effect of imperfect communication style is magnified. Thus, if the quality of individual communications remains fixed while the project grows, the overall quality of communication will go down.

For instance, a certain level of congruent communication might be adequate for a producing a product with 25,000 lines of code, yet be totally unacceptable for a product with 2,500,000 lines of code. In order to develop larger and/or more complex systems, then, it’s not sufficient to pay attention to technical issues–accepting that the existing communication style will be adequate. Managers must also improve the project’s communication culture, and thus they must pay more attention to congruence.

To make matters worse, unless we manage well, tougher projects tend to dimish congruence–because stress tends to rise when the expectation of quality rises. We are not always utterly logical creatures, but have feelings as well as thoughts in response to tougher assignments. When these inner feelings are strong enough, they translate into characteristic styles of coping with the stress. If our characteristic style is incongruent, communications become less effective and the job becomes even more difficult, creating a viscious cycle.⁵

Congruence, of course, is but one of the factors in effective communication–other factors include such things as timeliness, memory, proper audience, and accuracy of data. But without congruence, your efforts to improve these more “logical” factors will always be seriously undermined, along with your ability to build bigger, more complex, or more reliable systems.

Achieving Congruence

When Deming said, “Drive fear out of the workplace,” we think he was talking about changing the blaming organization to the congruent organization. This kind of change is made by one person at a time–hopefully starting at the top–and one step at a time. The steps can be broken down into six ‘A’s’, as follows: Awareness, Acceptance, Authorship, Articulation, Application, Activism. Let’s look at how each of these steps takes place in the context of an individual trying to change a blaming organization.

Awareness

Awareness says, “This is happening. This is real.” Awareness comes from experience, when I allow myself to experience the world around me as it is–not as it is supposed to be, or I wish it to be, or someone else tells me they want it to be.

Awareness is always the first step, and probably the hardest, because generally we’re not aware that we’re not aware. Here’s a personal example of how lack of awareness stops the change process before it can even start:

Jerry was attending a project meeting in a software company–a meeting called by the company President to find out what was going on in a late project, After some coaxing, one of the developers said that she was afraid to go to Nat, the Development Manager, with problems, because of the reception she got. Nat got red in the face, stood up, and shouted angrily, “How can you say that? My door is always open to hear your problems! The only thing I won’t tolerate is if you’re all emotional when you come, or if you don’t have a proposed solution!”

In the calmest voice he could manage (it’s hard to stay calm when someone is being so angry, even if it’s not directed at you), Jerry turned to the President and asked if Nat ever came to him with problems. When the President said yes, Jerry asked if the Nat was always calm and carrying a proposed solution. Before the President could answer, Nat interrupted: ‘Why would I come with a problem if it wasn’t important enough to get excited about? And, if I had a solution, why would I come to him?”

Although it was now clear to everyone else in the room that Nat was demanding that others “do as I say, not as I do,’ he was unable to see the incongruence. Lacking awareness, there was no way Nat was going to change–and indeed he never did change, up to the time the President released him to seek greener pastures.

Nat’s case is quite typical. Since incongruence is a defense, incongruent people erect all kinds of shields that close off information about congruence. Their own incongruence, and that of others, is invisible–it is accepted, especially if it is the norm in the organization. This invisibility makes it very hard to reach them with any kind of information on the subject.

In other words, when you’re being incongruent, you’re losing your ability to take in what’s going on in the world (inner or outer). So, you don’t know that you need changing. And, even if you did, you haven’t a clue what to change to. No wonder it is so difficult to transform an incongruent culture, when the very first step–awareness–is so hard to come by.

Awareness comes from experience, when you allow yourself to experience the world around you as it is–not as it is supposed to be, or you wish it to be, or someone else tells you they want it to be. But in the blaming organization, where people shield themselves from experience, becoming aware usually requires help. Helping others become aware takes the skill to develop safe environments and to build relationships. It takes the patience and caring to watch for signs of awareness and help build on them. It also takes a belief and a commitment that “part of my job is to help the people on my team to develop– the most important part.” If you don’t believe this, then certainly don’t try to help people become aware. Otherwise, you’ll find yourself saying, “You aren’t aware of what a lousy employee you are, but I’m going to make you be aware!”

But awareness of the overall situation is not sufficient–you also need self-awareness. Self-awareness says, “This is me. This is mine.” You may be fully aware of the blaming, but as long as you merely say, “This is a blaming organization,” you’re not doing anything to change it. When you say, “I am a part of this blaming organization,’ you move forward. You own the blaming as a part of yourself and your behavior–not just something that “they” do (to you).

Self-awareness is often followed by depression or shame or guilt. Some people react with anger, at themselves or at any convenient target. Yet Self-awareness is empowering–the thought that since I own it, it’s mine to do something with.

Acceptance

Acceptance moves the change process beyond self-blaming and says, “I’m not a bad person because I do this. My intentions are good, though my actions may not be effective.” Acceptance means that you understand that taking responsibility is not the same as blaming yourself. Thus, you have mercy on yourself and your all-too-human imperfection. You stop being angry. You forgive yourself for not doing better in the past, based on your present understanding and standards. And, as you forgive and accept yourself, you gain compassion for the others involved–thereby increasing the chance that you can communicate with them and effect change.

At the point when you’re trying to reach acceptance, it’s critical that you not be punished or humiliated by someone else. You need a little help in getting off your own back, or else you think so little of yourself that you couldn’t possibly do anything about the situation. Of course, in a blaming organization, you may have a hard time avoiding this kind of punishment, which is why authorship and acceptance are usually done internally, and kept internal for some time.

Authorship

Authorship is the first decision point, when you say, “I have choices. I can do something about this.” With some encouragement, you accept that you are responsible for choice in your life. You understand that you don’t have to react, but that you can chose your response–that you create, in large part, your own interpersonal context. You know there are some parts of the context that you can control and some that you can’t; and you know accurately which is which.

Articulation

Articulation is the public commitment to change, and says, “I’m going public with this (for accountability and support).” Articulation is ineffective if attempted before the prerequisites are in place. If you can’t accept yourself or how you have reflected yourself out to the world, or if you don’t know that you have choices or feel you can gain support for those choices, then speaking out is merely ineffective bravado.

But, when the prerequisites are in place, you cannot be effective by keeping silent–you must decide to speak out. In the process of speaking you transform your inner awareness to another kind of experience. You hear yourself and you notice the response you get from others. You make public, if you will, your self–your mental and emotional position.

Initially, of course, you must seek out safe places to disclose your truer and more honest expressions of your thoughts and feelings. When you become more grounded in the power of your true self then you can seek the kind of support that challenges and confronts you, as opposed to the kind of support that coddles and consoles.

Initial steps of articulating congruence are often awkward. That’s why a responsive and receptive listener satisfies one of the requirements for promoting the development of congruence.

Application

Application says, ‘These are my choices (my new ways of coping).” You learn to be congruent yourself, first in your most immediate, safe, and encouraging context. Then you expand the contexts in which you can respond congruently. Don’t try to “not be incongruent.” This paradoxical command only invokes the incongruence of perfectionism. (”If I can’t be perfectly congruent all the time, I’m worthless.”) Focus on congruence, practice congruence, and the incongruence “muscles” will simply atrophy.

With support and practice you can begin to use and test out congruence in your immediate relationships. We suggest that you continue to design for success, so that initially these tests of your new skill are done within environments where you will more likely be given the benefit of the doubt. As you experience success, then you can be centered even in more turbulent and conflicted arenas. In other words, once you “get the call,” don’t march into the president’s office and announce that henceforth, all the guilty parties must stop blaming, or else.

Activism

Activism says, “Now that I can make a difference in myself and my most familiar world, I’m going to help spread this throughout the organization.” Activism is applied leadership, starting at the point at which you have enough competence at being congruent to reach out and be proactive–anticipating, initiating, instigating–but not inflicting. You cannot operate from an incongruent position and force other people to be congruent. (”I have to blame them, because they’re so blaming. Once they change, then I’ll be able to change.”)

In any case, you don’t have to inflict congruence on anyone. Congruence is contagious–when directed consciously to creating a safe, nurturing, productive environment. It may spread more slowly than you’d like, but once it starts moving, it’s hard to stop.

Notes:

1. For more on how blaming and other incongruent styles impact software work, see Weinberg, G. M. (1994). Quality Software Management: Congruent Action. New York: Dorset House.
2. For more on incongruence and verbal patterns, see Hardin, S. E. (1989). Success with the Gentle Art of Verbal Self-Defense. Englewood Cliffs, NJ: Prentice-Hall.
3. Brooks, F.P. (1982). The Mythical Man-Month. Reading, MA:Addison-Wesley.
4. For more on undiscussability, see Argyris, C. (1993). Knowledge for action: a guide to overcoming barriers to organizational change. San Francisco: Jossey-Bass.
5. for more on such system dynamics of projects, see, for example:
   Senge, P. M. (1990). The Fifth Discipline: The Art & Practice of the Learning Organization. New Turk: Doubleday.
   Weinberg, G. M. (1975). An Introduction to General Systems Thinking. New York: Wiley-Interscience.
   Weinberg, C. M. (1991). Quality Software Management: Systems Thinking. New York: Dorset House.

convert this post to pdf.

P.T. BARNUM said there’s a sucker born every minute, but Barnum was a conservative estimator — or else he didn’t know any IT managers. For more than 45 years now, I’ve watched an endless stream of technical “solutions” being promoted, sold, and quickly put on the shelf and forgotten.

Come to think of it, forgetting these “solutions” is not such a bad result. As someone once said: “A problem is the solution to the previous problem.” At least forgotten solutions don’t become bigger problem than they were supposed to solve.

Remember COBOL? What was it supposed to solve?

As Jean Sammet recalls in her History of Programming Languages, the users for whom COBOL was designed were two subclasses of those people concerned with business data processing problems.

One is the relatively inexperienced programmer for whom the naturalness of COBOL would be an asset, while the other type of user would be essentially anyone who had not written the program initially.

Little solutions

In other words, the readability of COBOL would provide documentation to all who might wish to examine the programs, including supervisory or management personnel. Little attempt was made to cater for the professional programmer.

I have clients today who are maintaining, with professional programmers, tens of millions of lines of COBOL code — and no supervisory or management personnel would dare to look at a single line, let alone change one.

COBOL solved some little problems, but left us with a much bigger one. Because these organizations are busy chipping away at the incredible mountain of maintenance, new development work of organizations falls behind.

Like addicts deprived of their drugs, the customers are eager for a “quick fix,” and ready to deal with any pusher. One quick fix is called “rapid prototyping.” Almost all of the “rapid prototyping” I’ve so far seen hasn’t been all that rapid, but that doesn’t matter, because it hasn’t been prototyping either.

I know that statement will bring letters from a hundred vendors agreeing with me – except as far as their product is concerned. But that’s not the battle I want to fight. Nor am I concerned that where prototyping works, it often works backwards. In building airplanes, for example, a prototype often leads to a higher rate of failure in the final version because the prototype makes the builders overly ambitious about the successor.

But let’s put these little quibbles aside and assume that everyone’s rapid prototyping system is both rapid and prototyping. Let’s grant that they work (after all, COBOL worked) and contemplate some of the consequences.

Santayana said that those who failed to study history were condemned to repeat it. I suggest we study the history of that earlier rapid prototyping language, COBOL, so perhaps we won’t all repeat it.

Although many today consider COBOL a failure, objective analysis says it was a great success. If it hadnít been a success, we wouldnít have billions of lines of COBOL code to maintain.

Here is a riddle: How do you accumulate a billion lines of COBOL code? Answer: one line at a time. In most cases, thatís literally true, because very few of those billions of lines consist of original code. Over the years, as requirements changed, the COBOL programs have changed. Studies indicate that in a mature COBOL program, there have been three lines written for every one that remains in the code.

It took many programmers many years to accumulate those billions of lines, one line at a time. But we’re lucky, because now that we can program so much more rapidly, we won’t have to wait as long to accumulate our mountain of rapid prototype code.

In fact, now that we’ll eliminate the professional programmer, we’re going to have 100 times as many people developing prototypes. It took us half a century to get into the COBOL mess, but with rapid prototyping we can surpass that in a few weeks.

It’s not just the volume of COBOL code that causes the huge maintenance effort. Volume must be multiplied by a quality factor, because low quality code takes more effort to maintain. Yes, I know rapid prototyping languages are supposed to produce more readable code — but have you looked at any? Have you seen what happens after the users have made a few changes?

Lessons of history

History teaches us that when the users do actually make those changes, their ambition quickly outstrips their skill and the capacity of their language. At this point, they turn to the more experienced — the professional programmers who already are buried in COBOL code.

Again from history, we know that the more different people using code or data, the more constraints there are when it comes time to change. The amount of constraint makes each change more difficult, so a constraint factor must be added to the maintenance effort equation.

There may be some hope of controlling all this, but history teaches that most IT managers are going to go into a dopey daze in the sand while this quick fix enters the bloodstream of their organization. They can look forward to more maintenance, more difficult maintenance, done under greater constraints, with greater shortages of professional staff. Because they’re in a dopey daze, however, they won’t be looking forward at all.

The only people who can resist a quick fix are those that are not addicts. The only organizations that can avoid turning the maintenance solution into a maintenance trap are those that already have their maintenance under control. But that takes good management, for which there is no quick fix.

The moral of this story for my readers: Don’t despair of these hard times! There will always be enough work for those who are willing to slowly fix those quick fixes.

convert this post to pdf.

These days, with all the talk about “internet time,” professional workers are always trying to be the first with new ideas. But is that really the only path to success? Is it, indeed, a very effective path at all? What about being second?

Our culture certainly encourages people to be “first.” In school, the emphasis ranges from who raises a hand first in class to who graduates with the highest grade-point average. The valedictorian – first in the class – gets lots of honors, but the salutatorian – second in the class – has to make the speech (phooey!).

Sports competitions also honor the “winner,” and books on problem solving and business often borrow this metaphor – emphasizing finding the “winning” idea before anybody else. But most problem-solving areas of life are not, in fact, like sports. It?s not having the idea that matters, it?s what you do with the idea that counts.

And, in fact, ideas don?t count that much in sports, either. Anyone can have the idea, “Hit a home run now and win the game,” but there?s a lot more to hitting home runs than simply having the idea. To have a fair chance of hitting a home run, you have to practice, practice, and practice. As in most of life, the key issue is not who is there first with the idea; the key issue is how you develop the idea once you have it. It?s not your ideas alone that win, but ideas plus capability and the will to develop your ideas.

If you think having ideas first is the issue, consider this. Every year, tens of thousands of individuals start businesses based on being the first with a “new” idea. If that was all it took to be wildly successful, many of these firms would quickly displace all of the giant firms and become giants themselves, every year! Yes, we all know stories of small firms that had a better idea and indeed succeeded at becoming giants, but most of the time, the giants persist and the midgets fall humbly by the wayside.

Giant companies survive the onslaught of little start-ups with one of two strategies:
1. Exploring many parallel ideas and developing the few good ones.
2. Letting others do most of the searching for ideas, then developing the few good ones.

What can the individual professional learn from these strategies?

Exploring many parallel ideas depends on having huge amounts of capital, which the individual professional cannot manage. But even giants couldn?t afford to have so many explorations in the pipeline if they didn?t know how to kill the ones that show no promise, and kill them early. So, for the individual, the lesson of this strategy is to learn how to let go.

For me, letting go means not trying to maintain leading-edge competence in every field in which I was once competent. I used to be one of the world?s great IBM 704 assembly language programmers, and I suppose there are still some jobs maintaining such code, but I don?t think I?d want them anyway. I?ve let go of that one, along with dozens of others.

Letting go also means that I don?t try to pursue every new fad I happen to hear mentioned at a conference or on the web – which leads me into the second strategy – letting others do most of the searching for me.
In a field where capital costs are low (like software development), chances are better that some small firm will come up with the good idea first because there are tens of thousands of such small firms out there. In that case, the big successful companies don?t rely on coming up with every good idea first. Instead, they pursue an “always be second” policy, and support it. They maintain some minimal competency in a wide variety of areas, so that they?ll readily recognize one of these good ideas when it comes along – from another company, or often from one of their customers. Then, they?ll either copy the idea, buy the rights, or buy the company.

I?m not able to buy companies, or even their licenses, but I am able to learn from them. And, under some circumstances, I can ally with them. That way, even a single individual can pursue an always-be-second strategy.
To be a great second, I use a process that resembles the way a breeder produces improved plants and animals, with three essential elements: variation, selection, and retention. Variation provides the new ideas; selection weeds out the ones lacking promise; and retention propagates the ones that survive the selection.

Variation (new ideas) for an individual, comes from using a network to supply information from literally hundreds of sources. By communication with people in my network, I can be sure that few new ideas escape my attention. I have created a huge virtual organization, far larger than any real organization I could afford. The AYE Conference is a central element of that network, where I can meeting many of my “nodes” face-to- face once a year and exchange ideas and experiences.

The network provides some of the selection, too. First of all, any idea that nobody passes on to me is unlikely to be a worthwhile idea. Conversely, when I hear of the same idea from three separate sources, I raise its “score.” Of course, in order for this selection process to be meaningful, I have to consider the reliability of my sources. For example, if I hear an idea supported enthusiastically by certain people, I reduce it?s score.
I work hard to keep my network alive and healthy so I can depend on it to do a good job of variation and selection. Ultimately, though, I have to rely on myself to select which ideas are worth retaining and developing, but the whole process is designed to keep me from developing “neat things” that don?t fit the market.

I don?t know how to automate the retention and development of ideas, so it takes a lot of work, and I can?t afford to develop very many new ideas the way a large organization might. Sometime I can share work by co- developing ideas (seminars, books, articles) with colleagues from my network. But ultimately, I have to develop in my own way, to create the unique service I can sell to my clients. This is the place where it pays me to be first – I may be satisfied being second in the race to market, but I always try to be first in quality.

convert this post to pdf.

In a previous article, I wrote about the usefulness of treaties between technical teams, but I didn’t give much detail about the actual negotiation process that goes into making a successful treaty. To learn about such negotiations, let’s look at two scenarios of negotiations that went wrong.

Here’s Scenario Number One:

Bob (the Boss): Fay, what’s your estimate of when that component will be ready to ship to testing?

Fay: If I get the equipment I’ve requisitioned, I’m pretty sure I can have it ready in 14 weeks.

Bob: <looking disappointed> Oh.

Fay: Isn’t that okay?

Bob: Well,…

Fay: I suppose I can really push and get it in 12 weeks.

Bob: <still looking disappointed> Oh.

Fay: Darn. Well, if everything goes exactly right, I can make it in 10 weeks.

Bob: <brightening a little> Did you say eight?

Fay: Okay, I guess I can push for eight.

Bob: <smiling> That’s terrific, Kay. I knew you could do it!

Here’s Scenario Number Two:

Darlene (the boss): Ira, what’s your estimate of when that component will be ready to ship to testing?

Ira: If I get the equipment I’ve requisitioned, I’m pretty sure I can have it ready in 14 weeks.

Darlene: <standing up and raising her voice> Ira, that’s simply not acceptable. I want it in eight weeks, not a day later!

Ira: <eyes lowered to the his shoelaces> Uh… But there’s just too much to …

Darlene: <turning red, and raising her voice another level> Ira! I hope you’re not about to say something negative! You know we’re a team here, and we don’t have room for nay-sayers!

Ira: <trying to swallow when his throat is dry> Well… I suppose I could…

Darlene: <breaking into a tight smile> …you could do it! I knew you’d find a way, Ira. <turning towards the door> All right, then. I have your commitment, so don’t disappoint me. See you in eight weeks! <out the door>

—–

Q: What’s the important difference between these two scenarios?

A: Nothing. Nothing important, that is. Bob used a soft approach; Darlene used a hard approach, but nothing was really different. Successful negotiations usually involve trade-offs among schedule, resources, and technical specifications, but these two contain no trading off at all – just different kinds of manipulations to make one person submit to another person’s desires.

Here’s Scenario Number Three, which should produce a better result:

Annabelle (the Boss): Myron, what’s your estimate of when that component will be ready to ship to testing?

Myron: If I get the equipment I’ve requisitioned, I’m pretty sure I can have it ready in 14 weeks.

Annabelle: <looking disappointed> Oh.

Myron: Isn’t that okay?

Annabelle: Well, not really.

Myron: If the schedule is that important, we can look at alternatives.

Annabelle: I can’t give you any more people. We’re shorthanded already.

Myron: Darn. Well, actually, new people right now might be more disruptive than helpful. Well, something has to give – we can’t reduce schedule and hold resources and specs constant.

Annabelle: That’s certainly true. But I do need something to show to my marketing team in eight weeks. There’s that business expo where we have to do a demo, and I can’t change that date.

Myron: Okay, I guess we’ll have to see what features we leave out of the demo, or perhaps fake a bit.

Annabelle: <smiling> That sounds like what we’ll have to do, Myron. Let’s take a look at what you can give us that will look good in eight weeks.

—-

And so Annabelle and Myron get down to the business of examining which features will contribute most to a good demo (her problem) while at the same time being within Myron’s team’s capabilities (his problem). Nobody was forced; nobody was manipulated. The negotiation stayed open and based on facts, not speculation or screaming or placating.

Of course, this kind of negotiation takes trust – trust in the other person, but even more, trust in yourself.

• You must feel that you can be honest without being taken advantage of.
• You must be confident that you understand the trade-offs on your own side of the business.
• You must have enough self-esteem to be able to say what you don’t know.
• It also helps to know that agreements forged through manipulation will be weak and unreliable agreements.

In my experience, at least half of the problems developers have with customers are the result of poor negotiation – usually the result lack of skill and will to deal with various forms of conscious or unconscious manipulation by their negotiating partner.

Do you understand what I?m telling you? Well, you?d better understand, unless you?re too incompetent to do your job! From now on, I?m assuming your commitment to learn to do better at dealing with manipulation, so don’t disappoint me!

(Of course, the way you?ll disappoint me is by yielding to my attempted manipulations.)

convert this post to pdf.