Managing Yourself and Others

Managing Yourself and Others

by

Gerald M. Weinberg

CLICK HERE TO SKIP TO THE BEGINNING

SMASHWORDS EDITION

* * * * *

PUBLISHED BY:

Gerald M. Weinberg on Smashwords

Published by

Weinberg &. Weinberg

Managing Yourself and Others

Copyright © 2011 by Gerald M. Weinberg

All rights reserved. Without limiting the rights under copyright reserved above, no part of this publication may be reproduced, stored in or introduced into a retrieval system, or transmitted, in any form, or by any means (electronic, mechanical, photocopying, recording, or otherwise) without the prior written permission of both the copyright owner and the above publisher of this book.

Contents

Preface

Acknowledgments

Part I. Managing Yourself

Chapter 1. Why Congruence is Essential for Managing

Chapter 2. Choosing Management

Chapter 3. Styles of Coping

Chapter 4. From Incongruence to Congruence

Chapter 5. Moving Toward Congruence

Part II. Managing Others

Chapter 6. The Manager's Job

Chapter 7. Preference Differences

Chapter 8. Temperament Differences

Chapter 9. Differences as Assets

Chapter 10. Patterns of Incongruence

Chapter 11. The Technology of Human Behavior

Appendix A: The Diagram of Effects

Appendix B: The Software Engineering Cultural Patterns

Appendix C. The Satir Interaction Model

Appendix D. Control Models

Appendix E. The Three Observer Positions

Notes

Preface

We discovered that the key reason for our lack of competitiveness was poor management—by worldwide, not U.S. standards. We were being wiped out by the Japanese because they were better managers. It wasn't robotics, or culture, or morning calisthenics and the company songs—it was professional managers who understood their business and paid attention to detail. - Vaughn Beals

In the five decades I've spent in the software business, I've learned that there are three fundamental abilities you need to do a quality job of managing software engineering:

1. the ability to understand complex situations so you can plan a project and then observe and act so as to keep the project going according to plan, or modify the plan.

2. the ability to observe what's happening and to understand the significance of your observations in terms of effective adaptive actions

3. the ability to act appropriately in difficult interpersonal situations, even though you may be confused, or angry, or so afraid you want to run away and hide

All three abilities are essential for quality software management, but I didn't want to write a large, imposing book. Therefore, like any quality manager of software, I decomposed the project into three smaller projects, each one addressing one of these three fundamental abilities. Volume 1, Systems Thinking dealt with the first ability—the ability to understand complex situations. Volume 2, First-Order Measurement, dealt with the ability to observe what's happening and to understand the significance of your observations. The third volume, Congruent Action dealt with the ability to act appropriately even in the presence of strong feelings.

For many of my readers, these volumes were still too big and imposing, so I decided to update them and break them down even further, giving each a sharper topic focus. Volume 1 became two volumes: How Software Is Built and Why Software Gets In Trouble. Volume 2 became How to Observe Software Systems and Responding to Significant Software Events. Volume 3 is also becoming two volumes: Managing Yourself and Others and and (tentatively) Managing Teams and Organizations.

Now for an apology. Like most software managers, my initial estimate for this total work was optimistic. As a result, I could not finish what I had to say in three volumes, but required a fourth. In the fourth volume, I treat the question of organizational change—how you can manage a large organization, using all the tools of the first three volumes, so as to transform your organization into as high a cultural pattern as you wish, but particularly Pattern 4. This volume is titled, Anticipating Change. As it happens, change is a huge topic, so the book is huge, too. So huge, in fact, that I'll probably make three smaller volumes as I update it. But that's for the future. Right now, we're doing Managing Yourself and Others.

In order to understand and improve software engineering management, organizations are going to have to understand and improve the emotional functioning of their software engineering managers. The congruent managers they need must possess the three essential abilities of cybernetic control mechanisms:

• take information about actual and desired performance

• process that information congruently

• act in an appropriate manner

In short, they need managers whose personal effectiveness will tie together all components of effective software engineering management. Somehow managers themselves must take responsibility for upgrading the quality of management. They must recognize that managers are people, too, and just like everyone else, are trying to be helpful. Wherever I've seen this kind of upgrading, it's been individual managers taking responsibility for changing themselves before they try to impose changes on everyone else.

What are you doing to bring congruent management into your organization? What are you doing to become a more congruent manager yourself? Some of your personal effectiveness comes from training and experience—feedback from past projects. Some of it comes from your ability to take in what's happening in the present project. But even more of it comes from your past experience of a more general kind—your experience as a human being functioning in the world.

Some managers do not succeed because they shouldn't have been chosen as managers in the first place—and likely didn't even want to be chosen—but their organizations didn't appreciate that choosing managers for other than managerial potential is a mistake. Some are well-chosen, true. But nobody seems to appreciate that management is as much dependent on technique as any other profession. Even the most able managers must be trained.

This volume and the next are devoted to helping those individuals earn a fresh start—a chance to decide if they really want to be managers, and if so, to develop themselves to lead the way to a true profession of software engineering.

Acknowledgments

I'd like to acknowledge the important contributions of the following people to the improvement of this book through reviews, discussions, demonstrations, experiments, and examples: Wayne Bailey, Jim Batterson, Jinny Batterson, Lee Copeland, Michael Dedolph, Peter de Jager, Phil Fuhrer, Dawn Guido, Payson Hall, Naomi Karten, Norm Kerth, Mark Manduke, David McClintock, Lynne Nix, Judy Noe, Bill Pardee, David Robinson, Dan Starr, Eileen Strider, Wayne Strider, Dani Weinberg, Janice Wormington, Gus Zimmerman

Plus, the Change Artists and others in my client organizations, as well as numerous participants in the Problem Solving Leadership Seminars, the Organizational Change Shop, the Quality Software Management seminars, the CompuServe Software Engineering Forum, the Washington DPMA study group, and other educational experiences.

In this book, I'll credit each person who made a contribution, except that I'll disguise all people and clients from whom I've obtained confidential information. I hope that someday these people will experience working in an environment in which they needn't be afraid to tell their stories.

Part I. Managing Yourself

When I am, as it were, completely myself, entirely alone, and of good cheer… it is on such occasions that my ideas flow best and most abundantly. Whence and how they come I know not, nor can I force them … Nor do I hear in my imagination the parts in sequence, but I hear them, as it were, all at once. What a delight that is I cannot tell. - Wolfgang Amadeus Mozart

In his classic article on software engineering, Fred Brooks exposes our tendency to seek a silver bullet—some new technical breakthrough that would magically set software engineering to rights. Then he delivers the message of his title: There is no silver bullet.

Unfortunately, Brooks's audience doesn't seem to want to hear his message. I have seen very little evidence of software engineering managers giving up their search for the silver bullet. I do hear Fred Brooks quoted by managers opposing someone else's technical idea. Apparently, you think you've got a silver bullet, they say, mockingly. "Don't you know that Fred Brooks says that there is no silver bullet?" Then, having humiliated their opponent, they continue with the sale of their own silver bullet.

Even though none of these silver bullets has hit its target, some software organizations are producing high-quality work. After observing many of these high-quality organizations, I'd like to amend Brooks's aphorism to read:

There is no silver bullet, but sometimes there is a Lone Ranger.

In every high-quality software organization I have visited, I have discovered at least one Lone Ranger and several Tontos acting as backup. In Part I, I want to show what differentiates the Lone Rangers and their Tontos from the other characters—those who never manage to do much of anything memorable unless they are villains.

Chapter 1. Why Congruence is Essential for Managing

You're writing a gospel

A chapter a day,

By things that you do

By things that you say.

People read what you write

Whether faithless or true,

Say, what is the gospel

According to you?

- Children's poem

To produce high-quality software, we need high-quality, effective software engineering managers. This volume is about how to become such a manager—such a person.

Up until now, such managers have been rare in software engineering. During my career as a software developer, I never had such a manager, so I believed they didn't exist. More than that, I believed they were unnecessary—and I was right. Such high-quality managers were not necessary to produce mediocre software. In my years as a consultant, however, I've met many high-quality managers, and learned they are necessary if you want to go beyond mediocrity.

Perhaps your experience is much like mine. Perhaps you haven't met many high-quality software engineering managers. In such a case, you'll have to take my word for their necessity, because if you do not believe high-quality software requires high-quality managers, this book seem irrelevant to you.

But even if you believe in the necessity of effective managers, you may not agree with my understanding of what it takes to be effective. For instance, you may believe an effective manager simply needs to understand the concepts of software engineering, not to practice according to those concepts. This erroneous belief is the cause of a great deal of trouble, and extremely difficult for intelligent people to overcome. At least it was for me. For many years, I enjoyed the superiority of thinking that if I knew what to do, it didn't much matter if I actually did it. That opinion made it easy for me to be a sideline manager.

I've met many others like me in the software business, so this first chapter will introduce the idea of congruence, and tackle the question: Why must actions be congruent with thoughts?

1.1 Knowing versus Doing

The previous volumes in this series showed that in order to manage an engineering system by feedback control (Figure 1-1) a manager as controller needs to

• plan what should happen

• observe what significant things are really happening

• compare the observed with the planned

• take actions needed to bring the actual closer to the planned (Figure 1-2).

Figure 1-1. The feedback model of a software development system requires feedback of information about the system's performance plus requirements for the controller to compare with that information. This is the model that distinguishes Pattern 3 (Steering) from Pattern 0 (Oblivious), Pattern 1 (Variable), and Pattern 2 (Routine).

Figure 1-2. In Pattern 3 (Steering) organizations, management's job is to control a process that produces a desired product or service. Management plans what should happen, then observes what actually happens. Management's actions are designed on the basis of the difference between the planned and the actual results, then are fed back into the process being controlled. The focus of this volume is on the actions.

The first two volumes of this new series focus on the planning. The third and fourth volumes focus on observing and comparing. This volume (and the next) focus on action.

The focus on action may seem strange to those readers who believe that once the planning is done, the right actions must follow. I used to believe this myself. I had experienced many ineffective managers, and I attributed their ineffectiveness to their lack of brains: they simply didn't know what to do. Much later, I learned this wasn't always their problem. I have witnessed hundreds of instances when managers knew quite well what to do but were somehow incapable of doing it. For instance,

• A manager knew there was not the slightest hope of completing a project on time, but was unable to say this to her manager in order to open a discussion of alternative.

• A manager knew adding developers to his late project would only make it later, but he was unable to take the risk of appearing to do nothing.

• A manager knew screaming at people would only make things worse, but was unable to stop screaming at them.

• A manager knew an employee smelled so bad the other employees weren't able to work with him, but wasn't able to speak to the employee about it.

• A manager knew a certain person was right for an assignment, but put another person there because he disliked the best candidate.

• A manager knew a project shouldn't proceed without a clear understanding of the problem they were trying to solve, but was unable to resist the eagerness of the developers to get started writing code.

• A manager knew she shouldn't make promises she wasn't sure she could keep, but she kept making promises to get out of difficult interpersonal situations (temporarily).

1.2 Requisite Variety

Ross Ashby pointed out that any controller, in order to be effective, must have sufficient variety in its coping mechanisms to counter the variety of actions that could be exhibited by the system being controlled. Ashby's Law of Requisite Variety says the action taken by the controller must be congruent with the situation, in there is at least one controller action to deal with each possible system action. The managers who couldn't do what they knew they should do lacked the requisite variety of actions to perform their jobs effectively.

For control purposes, it doesn't matter why these managers were unable to exhibit the requisite variety of action. A manager (acting as controller) may lack a plan or may lack the observations needed to compare the plan to what's really happening, as Volumes 1 and 2 discuss extensively. But it's also useless if a manager knows what to do but is incapable of actually doing it—especially under stress, when managers may be called upon to use any of their full variety of potential actions.

When people are not tapping their full variety of potential actions, they are coping incongruently. According to the Law of Requisite Variety, managers acting incongruently may not be capable of controlling the system they are trying to control. This book is about increasing the congruence of your actions—especially under stress—and thus your ability to manage for the quality you desire.

1.3 The Importance of Management

The significance of congruent management extends beyond simple projects to the process of raising the general cultural level of the organization. As Bill Curtis—former director of the Process Program at the Software Engineering Institute (SEI)—observed:

If an organization is trying to build a general management infrastructure at the same time it is trying to improve its software process, then it will take longer to achieve the next level.

Even further, Humphrey and Curtis—SEI's first two directors of the Process Program—said:

A defined engineering process cannot overcome the instability created by the absence of sound management practices. Occasionally, unusually capable and forceful managers can withstand such pressures...

Now, it seems to me we could follow this observation in one of two directions.

1. We could try to introduce defined engineering practices so we could overcome instability even with incapable and weak managers.

2. We could seek and cultivate these unusually capable and forceful managers.

The SEI is pursuing Path 1, which is appropriate for an organization such as the SEI whose clients are organizations. This volume will pursue Path 2, which is appropriate because that's my audience—individuals who want to become unusually capable and forceful managers.

1.4 The Number One Random Process Element

Even though that's not my path, I believe it's extremely important that SEI and other institutions pursue Path 1. For one thing, it is the path we in computing have always pursued and know best: figure out ways to achieve quality by eliminating people from the equation. Secondly, it has had some phenomenal successes.

I recently read about William Shanks, who in the 19th century took 20 years to compute pi to 707 digits, and made a mistake in the 528th decimal place.