Watts Humphrey shares his ‘Reflections on Management,’ Part II

Watts Humphrey headed the IBM development team that introduced the first software license, and he later served as its director of programming and vice president of technical development. He is a fellow of the Software Engineering Institute and the Association for Computing Machinery, as well as a recipient of The United States Patent and Trademark Office’s National Medal of Technology.

Accolades and accomplishments aside, he’s also made his share of mistakes, and from his decades of experiences, he learned hard lessons about how software projects should be managed, how to manage teams, his bosses and himself. Humphrey recounts those experiences in his recent book, “Reflections on Management,” which he elaborates on in the second part of this interview.

SD Times: In a low-growth economy, how does a manager make the case for prioritizing projects rather than triple-assigning programmers to pretend that every job was staffed?
Watts Humphrey: All it takes is guts, and the brains to recognize that you are just putting off an inevitable problem and making it worse at the same time. Double- and triple-staffing projects is wrong for four reasons:

It destroys teams. No one knows who is on the team so no one can count on anyone else for help when they need it.

It demotivates the engineers. In effect, management is telling them, “We can’t set priorities, so you decide what to do.” This is like telling the engineer that none of his or her work is very important, and that management is just pretending that all these projects are being worked on.

It destroys productivity. It takes time to switch jobs and to rebuild the context of what you were doing a day or two earlier.

Finally, by double- and triple-staffing your projects, you are pretending that you can do more work than you actually can do.

Why pretend? Face the issue now. If management insists on taking on more work than they have resources to accomplish, that’s their problem and make sure they know it. Stick to your guns, and as long as you have good plans, you will win the inevitable battles.

You stressed the importance of open dialog throughout your book, yet noted, “Bearers of bad news are the first to be shot.” How can you expect team members to willingly provide feedback and communicate freely, and to fully contribute what he or she knows?
This is a question of trust. In the typical blame-based management culture, it is risky to speak out. This inhibits innovation and creativity, delays early warning of problems until it is too late to prevent them, and makes people unwilling to identify problem causes for fear of being blamed for the resulting damage.

Admiral [Hyman G.] Rickover, when he established the U.S. Navy’s nuclear fleet, instituted an open and honest culture. He required that all problems on a nuclear submarine be reviewed by a captain’s mast, the causes identified, and the corrective actions reported to his office. This produced an unrivaled quality culture, which continues to this day.

The only way to establish such a culture is from the top, but that takes leadership and an appreciation of the new styles of management required for modern systems and software work.

You frequently note how ideal self-directed teams are, and that teams must first become cohesive in order for that to occur. Can distributed teams ever really become cohesive?
Building cohesive and jelled teams when the members are distributed is more difficult than when they are co-located. However, we have found that it can be done. The key is to follow an orderly team-building process like that provided by the TSP and to ensure that all team members are in agreement on the team’s goals and plans. This is best done by bringing all team members to one location for the team launch. However, even a distributed team launch can be handled with the use of various conferencing tools and aids as long as it has proper leadership and coaching.

With teams we have launched in India and on the U.S. west coast, for example, this required that one of the groups work late at night, but we have not found that to be a serious problem. A cohesive team can still result as long as the launch is properly conducted and as long as senior management participates when they are supposed to, even if it is late at night.

Given the impact that personality and politics have on any organization, can a closed group where one person dominates realistically transition into being an open group?
This really gets back to the trust problem discussed in question 6. In a trusting environment, open and honest behavior is the norm, and the difference between that and a blame-based environment is like night and day.

How do you encourage self-sufficient personality types to ask for and receive help when they need it?
The key to this is to help people to recognize their own skills and abilities, and to also understand their own limitations and weaknesses. We have now trained thousands of industrial software engineers in these methods, and we typically have them tell us things like, “I never realized how many defects I make,” “I’m not as good as I thought I was,” or “My productivity sucks.”

The key to self-improvement is recognizing where you fall short and where others are able to do better. Then everybody, even the most skilled and self-sufficient engineers, is more realistic about their own abilities and much more likely to ask for help when they need it. They are also much more likely to help others and to be cooperative and effective team members.

Describe the qualities of an ideal team leader possesses.
The ideal team leader is, first of all, a leader rather than a manager. He or she has clear and compelling goals, sells these goals to the teams, and sets and maintains high performance standards. He or she also insists that the team make its own plans and commitments, and challenges the members to manage their own problems and to consistently meet their commitments.

The ideal team leader also builds and develops the team members, challenges them to do even better, and looks for and develops potential leaders who could take over whenever needed. Great leaders not only motivate and guide their members, they also know that they must have potential replacements who can take over in emergencies. They also know that they can’t be promoted without a potential replacement.

What advice do you have for managers who are dealing with executives who are focused on cutting costs yet demanding mission-critical software?
These are not contradictory objectives. Cutting costs is always a worthwhile objective particularly when developing large-scale mission critical software. The key to doing this is to focus on the biggest cost items. The cost-of-quality measure is most useful for this purpose, and the cost-improvement opportunities with big mission-critical programs are generally far greater than anyone realizes.

With a measured and managed quality program, we typically see test costs being cut by 75% or more and schedules being accelerated by many months. This has been true for both large and small systems programs of all types. Again, for further information on this subject, see my books and papers.