When it comes to doling out rations of appreciation, some mangers act like the Norwegian husband whose wife, on their tenth anniversary, asked if he loved her. He looked at her with a stern yet puzzled expression and said, “I told you I loved you when I married you, and if I change my mind, I’ll let you know.”

When I talk to managers about appreciating behaviour they want to reinforce, these strong, self-reliant men and women seem to turn into mush. The one ability they retain is the ability to produce rationalizations, such as

• They should know if they’re doing well
• They’re paid to do a good job. That’s appreciation enough
• I’ll tell them at appraisal time (ten months from now)

One source of this fear is shame. As Tagore, the Nobel-prize winning Indian poet said, “Praise shames me, because I secretly crave it.”

Managers who are ashamed to want appreciation for themselves are unlikely to offer it to their own employees. It would help them to know this big secret: All people like to have their work appreciated.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 17

Culture makes language, then language makes culture. When you arrive at your destination but your bags don’t, the baggage handler shapes the context by asking “Did you lose your luggage?” This presupposition may have been originated by the airlines and taught quite intentionally in the handler’s training, but by now it’s completely unconscious. You can see that it is unconscious by replying, “No, you lost my luggage,” and observing the confused look of someone whose cultural assumptions have been violated. If repeated a few times, it also brings you a much better chance of effective handling of your problem.

The same influence is seen is software engineering cultures.

Organizations that use “bug language” develop and maintain software in a different way than those that use “fault language.” When someone says “I was late because there was a bug in my program,” you could change the frame a tiny bit by replying, “Oh, when did you put the mistake in the program?” Merely changing the language may not cause people to take responsibility for their creations, but it certainly helps. Once you reach a certain threshold, social pressure starts to act on those who continue to evade responsibility by using bug language.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 16

Busy management is bad management. To engage others, you have to be available, and availability is cited by new managers as one of the three most important characteristics in a mentor. The other two characteristics are setting high standards, and orchestrating developmental experiences, both of which also require a lot of engaging. Irrelevant managers keep busy doing irrelevant or unimportant things, or things they should be having others do.

If done well, management is a tough job, which is why they pay is premium. However, there will always be those managers who want to get paid for the hard parts of management work without actually doing them. Offering feedback is one of those hard parts. Under a performance appraisal system, placating or irrelevant managers can think, “Well, I won’t bring that up right now. I’ll save it for the performance appraisal in December.” Over the months, feedback accumulates to be dumped on people when it is too large and too late to do anything by create resentment and opposition. Managers appear to be doing management work, but they are simply creating trouble.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 15

You cannot possibly prohibit blaming one hundred percent. People blame when their self-esteem is low, and there’s no way you can ensure that self-esteem is always high for everybody in the organization. However, managers can create conditions in which blaming cannot thrive, even should it spout.

The key to a non-blaming organization is openness. Like the repulsive creatures that live under rocks, blaming thrives in the dark. The first requirement for a blame-proof environment is an open-door policy all the way to the top. Openness only at the top is not sufficient, but must be part of a general openness policy. Openness is the enemy of error, and blame is the enemy of openness.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 14

Placating occurs when self-esteem is low. Raising self-esteem – through management style, training, and affirming feedback – can help to block placating, but in itself cannot prevent it. For instance, IS customers often have high self-esteem, but not in the context of computers. Feeling technically incompetent, they must humble themselves to the sole source of technical help.

To understand their situation, picture yourself stranded in a remote hotel, and suppose that each meal offers a menu with only one selection. Having no other choice if you don’t want to go hungry, you eat what the chef has prepared. If the chef is rude to you, you are polite to him. If he is rigid, you are accommodating. If he demands a high price, you bite your tongue and pay. This no-choice restaurant more or less describes the situation of the captive customer or an in-house software organization.

There is no particular reason for a restaurant with a captive clientèle to maintain its excellence, which leads to the following principle: To prohibit placating, give customers alternative sources of services.

Although this principle is the foundation of American capitalism, it seems to unhinge the mightiest managers of internal IS organizations. They certainly agree with the principle, but always for the other guy. The know (extending the dining metaphor) that if the customer ever has an alternative she may try to retaliate for the rude chef. In the IS world, when the customer finally decides to retaliate, she pronounces the dreaded word outsourcing. Outsourcing is to IS managers what a silver crucifix is to Count Dracula. But contrary to the internal manager’s trepidations, outsourcing may be the best thing that ever happened.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 13

In the nineteenth century, heroin was put into use as a cure for morphine addiction. It was successful at ending morphine addiction so long as heroin was available because heroin was more powerful. Of course, the morphine addiction then became a heroin addiction, which wasn’t much progress. This replacement dynamic is being repeated in the twentieth century with the use of methadone. And, oh yes, morphine itself was thought to be a cure for opium addiction.

In the software world, FORTAN was put forth as a cure for the addiction to assembly language. COBOL was designed to eliminate the dependence on programmers, since executives would be able to write their own code. Spreadsheets were going to replace COBOL, but now many executives spend more time fiddling with their spreadsheets than doing executive-type work.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 12

To understand my style and intent when I am not being congruent, others must be skilled technologists of human behaviour. If I want to make others’ jobs easier, I too have to master the same technology and apply it to the job of becoming more congruent.

The technology of human behaviour is many times more complex than the technology of software. Engineers sometimes express disdain for the study of human behaviour, saying it is a soft science, not a hard science like electrical engineering or computer science. Well, software may be a hard technology, but human behaviour is a difficult technology. Compared to you or me, an operating system is a piece of trivia.

In my interactions as a manager, as I try to understand or influence another person, I am modifying the other person’s program, or stimulating that program to get certain responses and not others. For people who have survived to adulthood and hold jobs, most programs are 99 percent functional. But one wrong bit can produce total or very large dysfunction that can destroy any software project, no matter how well managed elsewhere. Thus, the size of my control intervention is not the issue. The issue is the precision.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 11

A major task of the software engineering manager is to help people in the organization develop their social skills, not just because the workplace is better when people are polite, but because social skills influence more and more the effectiveness of technical skills. Teaching social skills is an investment in problem resolution, but even more in problem prevention. As the organization learns to be congruent more frequently, the amount of time spent dealing with incongruence decreases.

Feeling unable to trade off either quality or schedule goals, managers are too often tempted to sacrifice the quality of human interaction, for which the soon pay the price in both quality and the schedule.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 10

In contrast to the Management by Selection Model (which says programmers, analysts, testers, writers, or whoever are born, not made, and that technical people can be ranked on a one-dimensional scale), the Management by Systematic Improvement Model is based on multi-dimensional thinking:

• People differ in many dimensions that can affect performance
• Programmers, analysts, testers, writers, or whoever can learn

Here is the way this model is applied:

1. Identify the good programmers (or any technical workers)
2. Analyze the performance of the best to determine why they are doing so well
3. Develop systems (training, technical reviews, teams, mentoring, or modelling) for passing these best processes on to large numbers of people

The model says:

1. Attention to process increases the awareness of what’s effective
2. Training increases the penetration of existing effective processes
3. Identifying effective processes leads to abandoning the ineffective processes

The training, of course, takes many forms. For one thing, simply going through the identification process tends to train everyone involved, so a group effort will have better results than an isolated team of experts. Second, much of the training will be invisible, as many ineffective processes will simply disappear once they have been identified. Third, the training will be more effective if it’s safe, particularly if it’s not used to identify “bad” people and blame or fire them.

For instance, some people think that the purpose of technical reviews is to catch people doing bad things, but their greatest benefit is catching people doing good things. If I’m reviewing your work and see something good, I can safely incorporate it into my own work without ever admitting I was bad.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 9

In software development, things can happen at a slow rate and often need unsticking, as when one blocking fault stops progress on an entire project for a month. In software maintenance, things happen at a fast rate and often need something to get them moving again, as when a customer is screaming on the phone for a quick fix so the payroll can get out.

As we improve our ability to control the physical and intellectual parts of the software business, we encounter a paradox. More and more situations are handled routinely, even automatically, so our productivity increases. This means we can handle more work with the same resources, but more work means more situations in which the routine doesn’t work. So, as we develop routines to handle intellectual and physical problems, we find that our ability to manage well depends not on our ability to handle routine situations, but on our ability to handle exceptional situations.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 8