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

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

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

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

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

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

I recently read about William Shanks, who in the 19th Century took twenty years to compute pi to 707 digits, but made a mistake in the 528th decimal place. Today, to compute pi to 707 decimal places, I can invoke a program called Mathematica on my desktop with the instruction: N[Pi,707]. 10 seconds later I have my 707 places, all correct this time.

Because of software technology, I have achieved truly spectacular increases in performance, cost, and quality. But this problem has an important characteristic: It involves essentially no management! If they did involve management, the spectacular gains made possible by tools would evaporate. What would happen in your organization if a customer submitted a request to compute pi to 707 decimal places? Is this a ten-second job?

I had a number of my students conduct this pi-to-707-decimal-places test in their organizations, secretly asking a customer to submit the request. Here are some of the results:

• After one week, the request form was returned by a clerk with the comment “Incorrectly completed.”
• The request form was never returned, never acted on, and never heard of again three months later. (This was the most frequent “response”)
• The customer received a call from a secretary to schedule a meeting with an analyst. The analyst had no available time for more than a month.
• The request form was returned in ten days marked “you’re not serious”
• Several replies were in terms of programming estimates, which ranged from three weeks to four months
• One customer got a printout of pi to 1,000 decimal places
• One customer was asked on the phone wehter he wanted a printout or a file on disk. He asked for the file, and was given it by hand less than an hour later.

To me this silly little survey simply confirms what I have observed directly in dozens of organizations. The variation in service produced by these organizations didn’t come from the differences in technology, because all had access to the same technology. The variation came from the differences in management. In software work today, Management is the number one random process element

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

… software engineering is polarized around two subcultures – the speculators and the doers. The former invent but do not go beyond publishing novelty, hence never learn about the idea’s usefulness – or the lack of it. The latter, not funded for experimentation but for efficient product development, must used proven, however antiquated, methods. Communication between them is sparse …

— L A Belady and R Leavenworth, “Program Modifiability”, IBM Research Report RC8147, cited in Robert Glass, “Reuse: Software Parts – Nostalgia and Deja Vu”

(If anyone can find me a copy of the original Belady and Leavenworth report, I’d be very grateful!)

“If a quality, like reliability, is not clearly specified, you can deliver the project earlier, if you interpret the quality requirements as “whatever it happens to be when the deadline arrives.” This, coupled with an innocent “Oh! You wanted more than two minutes between failures!” after the first complaints arrive, will solve the deadline problem initially. You are of course prepared to discuss a new schedule and project for enhancing quality to the required levels, not clarified for the first time”

— Tom Gilb

I like to quote Tom Gilb’s observations about what he calls “Weinberg’s Zeroth Law of Unreliability.” It represents the only time I can remember winning an argument with Tom. After he had published his “Gilb’s Laws of Unreliability”, I commented that he had left out the most important one of all, the Zeroth Law:

If a system doesn’t have to be reliable, it can meet any other objective

He argued that nobody could be so stupid as to not know that law, but a year later he admitted that most of his clients didn’t seem to know it at all. Moreover, they were desperately trying to remain ignorant of the law, and to keep their customers ignorant so they could use the escape hatch that Tom describes in the quotation above.

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

In addition to all the other benefits, reviews teach while testing. Review participants learn about a number of things that are important to their development as software engineering professionals. First and most obvious, they learn about technical issues. They learn about various languages, tools and techniques. Learning in reviews is much cheaper than learning in formal classes, and is also more immediately relevant to the task at hand.

Participants also learn the specific product under review, which provides a much more secure base for project completion. If someone leaves or is needed in another task, anyone who has reviewed the project has a heard start on taking over.

They also learn about reviewing. Reviews are usually rather clumsy at first, but even without outside help, reviewers soon learn to do a much more efficient and effective job.

Less obviously, review participants learn about themselves. They learn just how good they are compared to others. This learning takes place without anyone being insulted or embarrassed, but helps people know what they can handle and what they cannot, as yet.

Participants also learn how much they have to learn, and what that is specifically. People who participate in reviews not only learn more effectively than those who participate in classes, they also make better use of those classes they do take, because they know what they need to know.

Finally, review participants learn about others in the review. They learn who is working on what, which develops a project consciousness and improves the efficiency of the informal communication system. They also learn who knows how to do what, so that when they have a future problem, they more quickly reach the person who can help them solve it.

Thus, although the review seems to be directed at the product, its major effect in the long run is on the process.

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