Only the knowledge workers know exactly what they are doing and how they are doing it. Because knowledge work is invisible, no one else, including the managers, can understand what the knowledge workers are doing or how they are doing it. Because it is impossible to manage effectively work that you do not understand, no one but the knowledge workers can manage knowledge work. Watts Humphrey, “Motivating Knowledge Workers” SD Times, June 2011, pg 71.

The only problem I had with this is that it almost eliminates the need for management. I’m not quite in agreement with that. Otherwise, I loved it as this is dead-on with my experience.

I often advocate first getting the project schedule right. What this fundamentally does is give the knowledge workers the space they need to do their job and to do it right the first time. The catch has always been to help get that schedule right, and doing that has always been hard to do — but not for the reasons most often cited.

In planning for a project, I talk about realizing the difference between telling the project management team what to do in the project plan or by using the project plan to capture what it is that will be done by the knowledge workers. This is an important distinction that often leads the project manager and senior managers astray. More often the planning process should describe how things are going to happen (which when accurate, will often surprise a lot of people the first time) rather than be what is considered more intuitive — but often wrong — as something that is a contract that tells the project team and organization how something will be done. Watts summarizes very nicely above why this approach, the descriptive plan instead of the directive plan, works best with experts.

So what is the purpose of project plan if it is not to tell everyone what to do? It instead informs everyone what others are doing so that they can better do their own jobs and better communicate with the other teams. In this way project management is helping the teams to communicate, rather than the often inappropriate notion of telling the teams how to do their jobs.

The other notion in the article is how the mangers can not know what the expert knowledge worker is doing. While I agree in principle, this should not stop the project manger from continuing to get smart on what the experts are doing. I readily recommend regularly embedding our selves into the technical work to improve our understanding of what the experts are doing. This helps us be better managers (communicate, persuade, translate goals so experts understand why they are doing something) but does not mean we are the experts or can think for them.

Finally, the article advocates experts tracking their own personal performance so they can better estimate tasks and efforts. This again matches well the notion that we must know our performance numbers so we can better estimate and manage our projects. While we can and often do go overboard on tracking data, I can’t overemphasize how important it is to train our gut by knowing how things are really going. Until we’ve taken the time to track what we do, we really don’t know (or recall) how things have gone in the past.

I’m still not totally convinced that teams can be completely self managing. However, it is clear in my experience that many if not most of the project management problems comes from management trying to over-manage teams of knowledge workers. This comes from what seems an intuitively obvious belief that, as the manager, this must be our job. Watt’s book nicely summarizes why encouraging team self-management and self-measurement is a project management tool that works.

What are some good examples of knowledge worker management you have seen?