Digital Intelligence & Forensics
Measurement & Analysis
Performance & Dependability
Process & Performance Improvement
Security & Survivability
NEWS AT SEI
This library item is related to the following area(s) of work:Process Improvement
This article was originally published in News at SEI on: June 1, 2007
This is the third in a series of columns on being your own boss. The first two columns discussed ideal jobs and autocratic management. In this column, I discuss knowledge work—what it is, and why it is so important. I also discuss why the management of knowledge work is fundamentally different from the way management is typically performed today and the consequences of today’s common management styles. While I will ultimately talk about what you and I, the knowledge workers, can do about the way we are managed, I am not yet ready to discuss that in this column.
The key point is that how we are managed is up to us. Once we have acquired the requisite knowledge and skill, we really will have the ability to manage our own projects, even if our organizations and our immediate managers do not know how to manage knowledge work. However, to be successful at doing this, we will have to show our managers how to manage us. Understanding how to do that, of course, is the key, and that is what I am talking about in this series of columns.
In part II, I mentioned the way development plans are typically made today. The manager sits down by himself or herself and lists half a dozen or so checkpoints, gives them more or less arbitrary dates that in aggregate meet management’s desired delivery date, and then reviews this “plan” with the team. After the team has commented on the plan, and the manager has made a few minor changes, this becomes the official team plan. The team is then committed to delivering the product on the date specified in this plan. The fact that none of the developers think that this plan has a reasonable delivery date or that they can meet the schedule is beside the point; this is the “official team plan.”
There are three things wrong with such plans. First, the team does not own the plan; it is the team leader’s plan. The members are not committed to it, and they do not believe they can meet it. Second, plans like this do not guide the work, and they do not provide a realistic estimate of how long the work will take. Third, development work is knowledge work, and plans that are produced in this way are not suitable for guiding knowledge workers. In addressing these points, I start at the back and work forward.
In this column, I discuss knowledge work, what it is, why it is important, and how to manage it. In subsequent columns, I will address the characteristics of plans that can truly guide knowledge work and help developers accurately commit to how long their projects will really take. After this important preparatory material, there will still remain the problem of getting people to actually work in this way. This is also a topic for future columns. In case there is any suspense, however, and for those of you who don’t know me and my work, all of the columns in this series are leading up to a discussion of how the Team Software Process (TSP) can guide you as you strive to become your own boss.
Knowledge work is work with minds instead of hands. While your hands may be involved, the true product of knowledge work is concepts, ideas, and designs and not the devices, machines, or things that may ultimately be produced from these knowledge products. The knowledge worker is most productive when he or she is creating, refining, recording, or elaborating ideas, concepts, and representations. This is creative work, and it requires a very special kind of management. Peter Drucker originated the concept of knowledge work, and he discussed it extensively in his final books and papers [Drucker 1999]. He describes what knowledge work is and how to prepare for it, and his books and papers are well worth reading.
My objective, however, is to describe how knowledge workers can take control of their own work. This is not a subject that Drucker has addressed. However, Drucker did succinctly state the management principle for knowledge work, which is that managers can’t manage knowledge work; the knowledge workers must manage it themselves. I add to this the point that, for knowledge workers to manage themselves, they must know how to manage. While all of this may sound very logical, there are some key questions. First, why must knowledge workers manage themselves? Second, why don’t they manage themselves today? And third, what is wrong with having managers manage knowledge workers?
First, the reason that knowledge workers must manage themselves is that nobody else can. We all think in our own way and often we don’t think much about how we think; we just do it. While this is a natural and comfortable way to work when you can, most of us work for organizations, and we are paid to produce results on committed schedules. However, to meet our schedule commitments, we must work to achievable schedules.
Since the essence of management is using the available resources to produce defined and committed results, the manager must know a great deal about the work, the available resources, and how the work is to be done. This means that whoever manages knowledge work must be able to project how long the work will take. To do this, however, that manager must also understand something about the products to be produced, how the knowledge workers intend to produce them, and how long similar work has taken them in the past. Finally, this requires that these managers have some historical data on how long it took these knowledge workers to do similar work in the past.
The reason that nobody but the knowledge workers themselves can manage knowledge workers is that their work is highly individual. If you ask designers how they design, for example, and assuming that they have thought about this question, they will tell you that they leap from one abstraction level to another, and frequently dive from the highest level all the way down to code and back [Curtis 1999].
When you couple this dynamism with the fact that you can’t watch people and tell how they are thinking, it is obvious that nobody but the knowledge workers themselves can know what they are doing, how they are doing it, what they have accomplished, or how long it took. Since you must know all of these things to manage any kind of sophisticated work, this means that nobody but the knowledge workers themselves can manage knowledge work.
This gets us to the second question: “Why don’t knowledge workers manage themselves today?” The principal reason is that few knowledge workers know how to manage themselves. For example, the things that software developers must be able to do to manage themselves are the four things I just listed above. They must know what they are doing, understand how they are doing it, be able to measure what they have accomplished, and gather data on how long it took. While knowing how to do all of this is not terribly difficult, it is not obvious. In fact, explaining how to do this is the principal reason that I wrote several of my books. The most relevant one for today’s software professionals is PSP: A Self-Improvement Process for Software Engineers [Humphrey 2006].
The basic requirements for self management are pretty straightforward, and they only require that the knowledge workers be able to convince their management that they can manage their own work. Then, of course, they must actually manage it properly and do it so consistently and well that management will continue to trust them to manage themselves in the future. This, however, is the key: trust. If your managers do not trust you to manage your own work, they must manage you. They may not want to, but their continued success as managers depends on the results that you produce.
Since your manager’s performance depends on your performance, and since the performance of software groups has historically been so poor, managers do not trust software professionals to manage themselves. To overcome this problem, all we have to do is to convince management that we can manage ourselves and then perform that self management so well that management will continue to trust us. Since software groups have been unable to do this in the past, they have not been trusted to manage themselves. This situation will continue until we software professionals do something about it. For more information on how to do this, read the rest of this series of columns.
This now gets us to the third question: “What is wrong with having managers manage knowledge workers?” Here the answer has two parts. The first is that even though the managers don’t know how to manage the knowledge workers, that doesn’t mean they won’t try. Unfortunately, however, when they do try, they do a bad job. That is why we get vague, inaccurate, and highly misleading plans and why software projects so frequently miss their schedule commitments. Furthermore, since the managers can’t produce precise or detailed plans, and since there is no way that they could know how long the various knowledge-working tasks would take, there is no way to measure and track progress against these plans.
Also, as noted above, when the managers make the knowledge-workers’ plans, the knowledge workers do not own these plans, and they have no real commitment to them. So, in summary, the reasons that managers should not manage, or even try to manage, knowledge workers are the following.
That is why the managers should not manage knowledge work. However, the problem is that, if the knowledge workers do not manage themselves, the managers must.
In the next column, I will start to address the question of what software developers and other knowledge workers must to do get control over their own work. Basically, this is the issue of building trust and credibility with management. Unfortunately, credibility and trust are hard to build but very easy to lose. All you have to do is to blow one schedule. This, of course, leads us to a circular problem: the managers blame the developers for missing their schedules and the developers blame the managers for giving them schedules that they can’t meet. Breaking this circle is not a trivial problem, which is why so few knowledge workers are actually able to manage their own work.
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 Judi Brodman, David Carrington, and Bob Schaefer.
In these columns, I discuss development issues and how they impact the work of engineers and their organizations. However, I am most interested in addressing the issues that you feel are important. So, please drop me a note with your comments, questions, or suggestions. Better yet, include a story or brief anecdote to illustrate 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
Humphrey, Watts S. PSP: A Self-Improvement Process for Software Engineers, Reading, MA.: Addison Wesley, 2006.
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 11 books. His most recent books are Winning with Software: An Executive Strategy (2002), PSP: A Self-Improvement Process for Software Engineers (2005), TSP, Leading a Development Team (2006), and TSP: Coaching Development Teams (2006). 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. In a White House ceremony in 2005, President George W. Bush awarded him the National Medal of Technology.
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.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.