For knowledge workers, automating the business process so that the system can “tell them what to do” is the entirely wrong focus for IT system support. The focus of the system should instead be on presenting to knowledge workers the current status of the project, measured a couple of different ways. The distinction is subtle, but important.
“We need guidelines, not guardrails”
To be perfectly clear: this article is about knowledge workers. These are people who figure out what they have to do, and there are often very creative differences between how each case is handled. How can we design IT support that supports their work, and yet still leaves them free to be creative and innovative.
The answer lies in what all seasoned managers know: you give your best employees useful feedback on how well they are doing, but you don’t tell them what to do. One of the most famous management guide books, “The One minute Manager“, makes it clear that in order to engage and motivate your best talent, a good manager will give short, clear written statements about what results expected, and not a detailed itinerary of all the steps and how exactly to perform each step. Working out the details is part of the job of the knowledge worker.
You may find it odd that I am comparing an IT system to a manager. The IT system does not replace management in any sense. A good manager provides the right extra ingredients to make a knowledge worker successful, and there is every reason to believe that the IT system to support knowledge workers should be based on the same principles.
Does a knowledge worker need a detailed description of exactly what is to be done? Management wisdom clearly indicates that they do not. In fact, when a detailed list of the steps to be taken are provided to the work, we call this “micro-management” and it is universally considered a bad thing. A detailed process diagram showing exactly what needs to be done, is exactly the same thing as micro-managing. This sort of detail might be the right thing for assembly line workers, because the routine, repeatable aspect of that work makes it appropriate, but for creative, innovative knowledge workers is it not. Remember, it is that creativity and ability to handle unexpected situations that you pay the large salary for. You don’t want to defeat that by micro-managing them.
Instead of focusing on the finding, documenting, and presenting the steps to be performed, we would better spend our time on tracking meaningful status. Here are a few examples:
- Every year my companies goes through an employee review process, and each manager has a lot of things to do. Instead of indicating a process of precisely how to accomplish this, it is better to make a display that shows what has not been accomplished yet. I have a number of people who report to me, and I have done this for a number of years, what I need is a list of the people who I have NOT complete the write up on, or the list of people who have NOT had their assessment reviewed and approved.
- Similarly, we have an in-house training program and there are several courses a year. From the title, I can not always know if that is the course I already took or not. A display showing all the courses I have completed, along with all the courses I have not yet started, would be the right thing to allow me to coordinate my activities.
- A sales person does not need a fixed process saying “today you need to do Y for prospect X”. Instead, a display showing their total activity this quarter, their expected activity (quota), and the list of prospects and their latest status. This kind of dashboard allows a creative salesman to find the right next thing to do based on a lot of internal expertise that can not be coded into a process diagram.
- It is a well known practice in software development Agile method that you make a big status display board that shows the current work packets (cases) and what their status is. It does not tell the workers directly what exactly must be done. In fact, these details will be different for each work packet. Yet we can all agree that we want to get the work to the “done” status, and to do whatever it takes to get that done.
Maybe I am splitting hairs here: what is the difference between telling the status of a work instance, and telling what has to be done next? It is the difference between goal oriented, and task oriented. Goals imply tasks, and tasks imply goals.
The point I am trying to make is this: the person who creates a process map will determine an ordering for tasks to be done. That ordering is unnecessary for the knowledge worker, and can in some cases actually get in the way. Forget about the ordering of the tasks. Instead, focus on providing good status what what has and has not been done.
This is not that surprising. Many good systems are designed today along these lines. Consider a customer relationship management system (e.g. Salesforce). The focus is on providing a dashboard with all the customers/prospects and the status. Consider a typical management project review meeting: a list of what has and has not been accomplished. Consider a doctor’s patient status chart showing vital signs and recent treatments. Financial managers focus on financial market status indicators, and account status indicators.
I have experienced systems that violate this principle, and they simply tell you what you have to do next, without any context around it, and without any status of other things. These systems are frustrating and unhelpful. If you want the best from your knowledge workers, you will learn from management wisdom, and provide a status overview that the knowledge worker can use effectively to determine for this case what needs to be done. It is not only more motivating, it also supports creativity and innovation.
I am not trying to say that all concept of a process should be eliminated. Clearly we have an understanding that a sales prospect will be vetted at a basic level long before the deal is signed. I am simply saying that the focus should not be on specifying the exact process, because knowledge workers are by their nature already knowledgeable about this. Instead, the focus should be screens and displays that gather status information. Knowledge workers need to be informed about the status of things … often things outside their direct control. This is an area of great need, and an area that will yield results.
If you are starting by mapping out the process that a knowledge worker will perform, then you might be focusing on the wrong thing. Instead, start by finding what sources of information and status can be collected and presented in a dashboard. Leave the knowledge worker free to decide what the right thing to do it. That feedback information is the right thing to support, motivate, and get the best from knowledge workers.
0 comments:
Post a Comment