Large-Scale Work–Part V: Building Team Ownership



Watts S. Humphrey

This library item is related to the following area(s) of work:

Process Improvement

This article was originally published in News at SEI on: May 1, 2006

This is the fifth column in a series on large-scale development work. The first column briefly summarized the issues of large-scale development work. It then addressed the problems of organization size and how, as organizations grow and mature, they necessarily become less efficient. The second column dealt with project issues and particularly with the management decision process. Often, the most serious problems in large projects concern the way decisions are made. In the third column, I focused on the people and teams that make up the project staff and the issues involved in maximizing their performance. The fourth column addressed the problems of applying democratic management principles in large organizations. As demonstrated in politics, autocratic management is not an effective way to run a large and complex modern country. Autocratic management has also proved troublesome for large and complex organizations and projects. In this column, I discuss why so many organizations appear to be autocratic and why project ownership is important.

Why Are Organizations Autocratic?

Most organizations aren’t really autocratic, they just look that way. The problem is not that the managers are truly autocrats, but that their people act as if they were. For example, during my years at IBM, I ran a development laboratory of several thousand people. I made a practice of walking through the lab several times a week and chatting with folks. I soon got to know the crew in the model shop pretty well. Two of the development engineers had starting coming in late and hanging their coats on the model shop coat rack so nobody would know they were late. At the end of the day, they left right on time. The entire shop was in an uproar.

One day, the shop elected a spokesman, and he came to see me. He was obviously very upset, and he told me the entire story. In my staff meeting later that day, I told this story to the senior managers. I concluded by saying that this was unacceptable behavior, and it had to stop. Thereafter, I was known as an autocrat who insisted on punctuality. That, of course, was not the case, but there was nothing I could do about it.

While a great deal could be said about the subject of image and how to develop or improve one, only three points are pertinent to this discussion. First, managers are people, and they occasionally get annoyed and take action without thinking about how it might affect their image. Second, technical managers have so much to do that they simply can’t take to time to explain everything that must be done. They just have to do what they think is right and assume that their people will trust them and follow their guidance. The third part of the autocratic image problem concerns positive actions, and this is where many managers fail. Managers must provide the guidance and support their teams need to develop a feeling of ownership among all of their members.

How Do You Develop Owners?

In my lab, the machinists clearly felt and acted like owners. They had all been with the company for many years and had large parts of their savings invested in IBM stock. They had an ethic of getting to work early and working until they finished that day’s jobs, even if it meant staying late. But at least two of the development engineers did not have this feeling. So how do you overcome this kind of problem?

I recently heard a story that described what a now-retired vice president did to handle this problem. In this large military contractor’s development laboratory, dates were often set by the customer, by some other team, or by executive fiat. The development teams couldn’t do much but struggle with impossibly tight schedules. This VP understood that such schedules would often slip, but he expected his teams to do their best to meet these dates anyway.

When team leaders came to him with proposals to slip their dates, however, he would consider the proposals, but only with two caveats. First, these team leaders had to provide an understandable rationale for the slip. Second, they had to have a recovery plan that they were certain to meet. In effect, he said: “The first slip’s on me, but the second one’s on you.” This made the team leaders owners of their recovery plans and schedules. As far as these team leaders were concerned, this executive was no autocrat.

So making team leaders into owners would seem to be relatively straightforward: management just has to let them set their own dates. While this may help, it doesn’t really address the problem of making the developers into owners. To do that, management must have the entire team, not just the team leader, set the dates.

Negotiating with Management

To make developers feel like owners, management must really make them owners. This can be done only by having all the members of each development team participate in making its own plan. Then they all must participate in negotiating that plan with management. To do this, however, the teams must know how to make reasonably accurate plans, and they must be guided through this planning process by someone who can coach them on how to make accurate plans and on how to negotiate plans with management.

The obvious next question is: “How much evidence does it take to convince management to agree to the team’s plan instead of the one that management originally wanted?” Managers have commitments too, and sometimes these commitments are very hard to change. So teams can expect their managers to be hard to convince. On the other hand, managers are frequently seasoned professionals, and many of them have also been developers. They have generally been around long enough to understand the common problems that development teams have with schedules.

So the key is for teams to do more than just complain that this is a tough schedule and that they don’t see how to meet it. They have to make very detailed and thorough plans. And, in doing so, they must work with the entire team and do their very best to produce a plan that meets management’s date. Then, if they can’t, they will know why and be able to explain the reasons to management.

While this may sound too easy, it turns out to be surprisingly effective. I have worked with hundreds of teams while at IBM and the SEI, and I know of no case where a team has followed this advice and not succeeded in convincing management that it had a better and more realistic plan for doing the job. Even when the team’s plan took twice as long as management wanted or took twice as many people as originally planned, management has still bought the team’s recommendation or a negotiated variant. The results of this strategy have also turned out to be good business: when teams produce their own plans, their typical schedule errors drop from 50% or more to less than 10% [Davis 03].

Self-Directed Teams

While it can take a lot of work to make a really detailed and accurate plan, it is not really that hard to do. In fact, the Team Software Process (TSP) provides an entire process framework and a set of management and team-member courses that have proved successful at doing just this [Humphrey 02, 05, 06a, 06b]. TSP also addresses more than just the schedule issues that most often lead to autocratic behavior. It shows teams how to own and manage all aspects of their work. With TSP, teams select their own strategies, define their own processes, and make their own plans. They then manage their work to these plans and keep management posted on their progress.

For large-scale work, however, the problem is not just getting a team or two to make plans and to believe that they own these plans, it is building a feeling of ownership across an entire large-scale program. While the first part of doing this must be making plans and establishing ownership at the team level, that is only one step. How do you then extend this individual team-based ownership strategy to cover an entire large-scale program? This is the scale-up problem that I will address in the next column.


First, I want to thank Phil Gould for his e-mail describing the story of the VP of a large defense contractor. It is a marvelous example of how executives, by being sensitive to the ownership issue, can make an enormous difference in how their teams feel about their work and their executives. Also, thanks to Bob Schaefer for his e-mail about convincing management to agree to new plans.

In writing papers and columns, I make a practice of asking associates to review early drafts. For this column, I particularly appreciate the helpful comments and suggestions of David Carrington, Harry Levinson, and Bob Schaefer.

In Closing, an Invitation to Readers

In this particular series of columns, I discuss some of the development issues related to large-scale projects. Since this is an enormous subject, I cannot hope to be comprehensive, but I do want to address the issues that you feel most strongly about. So, if there are aspects of this subject that you feel are particularly important and would like covered, please drop me a note with your comments, questions, or suggestions. Better yet, include a war story or brief anecdote that illustrates your ideas. I will read your notes and consider them when planning future columns.

Thanks for your attention and please stay tuned in.

Watts S. Humphrey


[Davis 03]
Davis, Noopur, & Mullaney, Julia. Team Software Process (TSP) in Practice (CMU/SEI-2003-TR-014). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2003.

[Humphrey 02]
Humphrey, Watts S. Winning With Software: An Executive Strategy. Boston, MA: Addison-Wesley, 2002.

[Humphrey 05]
Humphrey, Watts S. PSP: A Self-Improvement Process for Software Engineers. Boston, MA: Addison-Wesley, 2005.

[Humphrey 06a]
Humphrey, Watts S. TSP: Leading a Development Team. Boston, MA: Addison-Wesley, 2006.

[Humphrey 06b]
Humphrey, Watts S. TSP: Coaching Development Teams. Boston, MA: Addison-Wesley, 2006A.

About the Author

Watts S. Humphrey founded the Software Process Program at the SEI. He is a fellow of the institute and is a research scientist on its staff. From 1959 to 1986, he was associated with IBM Corporation, where he was director of programming quality and process. His publications include many technical papers and several books. His most recent books are Introduction to the Team Software Process (2000) and Winning With Software: An Executive Strategy (2002). He holds five U.S. patents. He is a member of the Association for Computing Machinery, a fellow of the Institute for Electrical and Electronics Engineers, and a past member of the Malcolm Baldrige National Quality Award Board of Examiners. He holds a BS in physics from the University of Chicago, an MS in physics from the Illinois Institute of Technology, and an MBA from the University of Chicago.

The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.

Find Us Here

Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

Share This Page

Share on Facebook  Send to your Twitter page  Save to  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

For more information

Contact Us


Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.