‘QSM3’ Category Archives


The Skilled Technologist of Human Behaviour

by Tony in QSM3

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


Social Skills

by Tony in QSM3

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


Management by Systematic Improvement

by Tony in QSM3

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


The Paradox of Control

by Tony in QSM3

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


Myers-Briggs in the Workplace

by Tony in QSM3

The four dimensions of the Myers-Briggs Type Indicator are significant in the workplace because they describe four elements that determine much of a person’s working style.

For each dimension of the MBTI model, there is a pair of letters to choose from:

  • Internal or External, according to how I prefer to get energy
  • Sensing or iNtuitive, according to how I prefer to obtain information
  • Thinking or Feeling, according to how I prefer to make decisions
  • Judging or Perceiving, according to how I prefer to take action

Failure to take the I/E difference into account leads to underperformance by one group or the other. At technical review meetings, for example, Internals prefer to study the material carefully in advance, but Externals prefer walkthroughs so they can study the material through group interaction. One of the manager’s jobs is to assure that meetings are designed to accommodate the environmental preferences of both Internals and Externals.

Sensors want the facts, lots of facts, while Intuitives want the big picture. When a Sensor is giving the facts, the Intuitives become bored out of their underwear. When an Intuitive is painting the big picture, the Sensors itch for some real data. A manager who has communication problems with employees should explore this difference as a prime candidate for the root cause.

Thinkers and Feelers are often intolerant of each others’ preferred style. In an organisation you can see the T/F preference in action whenever decisions are to be made. Thinkers want objectivity, logic and impersonality; while Feelers want humanity, values, and cooperation. In arriving at decisions, neither type objects to consideration of the other’s attributes, but merely considers them of low priority. Many T/F problems can be solved by designing the correct environment for decision making.

The Judging (or closure-seeking) preference is to have things settled, while the Perceiving (or information-seeking) preference is to keep options open on the chance that more information will affect the choice.

J/P differences are often the source of great conflict, as well as the source of great attraction, because each needs the other. Teams without any Judgers tend never to finish anything; while teams without any Perceivers find things only to find they aren’t really finished because some factor has been omitted.

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


What Congruent Managers Do

by Tony in QSM3

Over the years I have interviewed people on dozens of well-managed projects. When I ask the project members how their managers contributed to their success, here are the things they said most often:

Our managers contributed to our success by

  • offering positive reinforcement
  • giving precise and clear instructions, and always being willing to clarify when they’re not clear
  • not constraining workers any more than is essential
  • letting people fully explore the possibilities
  • simplifying tasks whenever possible, yet making sure the tasks aren’t insultingly easy
  • making the time frames clear and giving the reasoning behind them
  • paying attention to people’s skills
  • balancing the workload among all employees
  • ensuring there is some real part for everyone to play
  • teaching how to be supportive by being supporting of employees and each other
  • teaching how to trust by trusting each other and the customers
  • remembering what it’s like to be an employee and to be managed
  • answering questions correctly and honestly to build trust
  • getting good consulting advice and using it
  • creating a vision of the problem and communicating it clearly to everyone
  • providing organizational guidance whenever employees need it
  • setting things up so people can experience early success
  • not asking people to do things they aren’t able or willing to do
  • creating an environment in which it’s okay to have fun
  • making their objectives clear at the beginning
  • being available to workers and being generous with their time
  • understanding and forgiving mistakes
  • valuing creative approaches, even when the approaches are different from what they had in mind
  • not forcing people to be something they’re not
  • finding the resources employees genuinely need to do their jobs
  • changing their plans to fit environmental changes
  • resisting the temptation to change the rules in the middle of the project unless it is absolutely essential
  • explaining the reasons when something has to change
  • always being up front with employees, even when it’s embarrassing
  • genuinely wanting people to succeed
  • oh, yes, and occasionally making good decisions about hiring and firing subordinates

This sounds like an environment in which I’d like to work. It also sounds like the manager I’d like to be.

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



by Tony in QSM3

Perhaps the reason blaming is so popular among software engineering managers is the difficulty of the work, leading to a fear of losing control. Blaming is intended to provoke fear, and fear calls up survival rules and incongruent coping behaviour. The hope is that the preferred coping will be placating, so that the people attacked will do exactly what managers want.

This blaming approach might not be altogether bad if managers were perfect, so that all they needed was perfectly compliant employees. If you are perfect, you may consider employing this approach. Keep in mind, though, that not everybody prefers to placate in response to blame. Even if they don’t outwardly counterattack, or freeze, or go bezerk, remember that even the best placaters seem to have a finger of blame poised behind their back where you can’t see it. You’ll know it’s there only when you become aware of their malicious compliance, which may be too late. In the end, blaming causes you to lose the very control you crave.

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


Institutionalized Irrelevance

by Tony in QSM3

Idea-generating processes such as brainstorming can be seen as “institutionalized irrelevance” – desperate measures to be used when everything rational has been tried, or sensible measures to generate idea before the situation becomes desperate. Consultants often use games to introduce a playful element into an organization that is serious desperate (otherwise it never would have called in a consultant). In some deep way, the organization realises that it must break its patterns if it is to find a way out of some apparently hopeless situation. Behaviour that might have been irrelevant in another context then becomes the most congruent thing the organization can do.

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


Blaming as management style

by Tony in QSM3

Like all incongruent coping, blaming arises from feelings of low self-esteem. When I blame, I attempt to build myself up by tearing down others because I don’t have the confidence that I can amount to much 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 management style, it becomes a measure of how far an organizational environment has degenerated.

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


Software Impact Payoff

by Tony in QSM3

In his classic study of software engineering economics, Boehm isolates a number of “cost drivers,” of which Tools, People, Systems and Management are indicated to be the most important. By studying these drivers, we can determine which areas ought to be given management priority:

Category Influence
Tools ++ 3
People ++++++ 11
Systems +++++++++ 17
Management ++++++++++++++++++++++++++++++++ 64

Top managers could use this as a high-level guide showing where best to concentrate their organizational efforts. Suppose the elements had not been labelled, so that all you could see was a list of four impact ratios – 3, 11, 17 and 64. If you were managing a software engineering organization, where would you spend the most of your time seeking improvement? Obviously the factor of 64 would be the first place to look for improvement, and that place is management.

The question seems absurd, except for the fact that most managers answer the question in reverse order of the chart if they are given only the categories – tools, people, systems, and management. Perhaps the reason certain drivers are bigger that others is that management spends so little time paying attention to them.

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