"Process workers" vs "knowledge workers"

Factual Questions
1

Some jobs to me, are clearly, what I would call “process jobs”. These are jobs that usually focus on some kind of manual work, and usually follow fixed processes and procedures. There is limited decision making required on the part of the worker. Work output is easily measurable, and interruptions to a process worker’s job has roughly a one-to-one effect on the worker’s output. Eg, if a process worker, who usually works an 8 hour shift, gets 4 hours worth of interruptions over the course of the day, the process worker can expect to achieve roughly 50% output for that day compared to their usual output for an uninterrupted 8 hour day. An example of a “process job” would be one of my old jobs - stocking shelves at a supermarket. It basically involved picking up a box, opening it, finding where the product belongs on the shelf, filling the shelf, and disposing of the empty cardboard box. Where I worked, we were expected to pack on to the shelves 65 boxes of stock per hour. If an hour of my shift was interrupted for 30 minutes while I cleaned up a spill, I would only be expected to pack 32.5 boxes for that hour (half of the usual expected output). And that, to me, seemed reasonable.

However, there’s another type of worker, that I will term “knowledge worker”. The productivity of a knowledge worker can be difficult to measure. Knowledge workers operate in a field where quality of output can vary substantially, and quantity of output becomes a less reliable measure of one’s output. Knowledge workers are required to make a lot of decisions relying on skill, judgement and experience, rather than following fixed processes and procedures. Some of the tasks performed by knowledge workers require high levels of uninterrupted concentration, tasks that require the knowledge worker to simultaneously consider multiple pieces of information to determine a correct course of action to produce some output. Interruptions to a knowledge worker’s time and concentration has an exponential effect on their output. A knowledge worker who usually works an 8 hour day, who receives 4 hours worth of interruptions over the course of the day, can expect to achieve far less than 50% output than if they’d worked a standard, uninterrupted 8 hour day.

What I’d like to know is… are there any articles or resources that talk about/acknowledge these two different kinds of jobs, the challenges of each, how to manage these types of workers, etc.

Thanks.

2

I guess in a way this could be similar to blue collar/white collar jobs, or at least a component thereof; I doubt anyone would consider stocking shelves ‘white collar’, and a doctor or lawyer would fit into your ‘knowledge worker’ category.

3

The distinction isn’t as simple as process vs. knowledge. Some processes are sufficiently complex and have enough variance that they resemble the knowledge jobs. And some of things that get categorized as knowledge jobs are just very complicated processes, and in both categories creativity may be a requirement, which wouldn’t fall cleanly into either knowledge or process.

Anyway, books that address employee management will address these issues.

4

The reason I ask is, I work for an IT company. Two types of employees we have are data entry staff, and programmers. I’m a programmer.

What a lot of managers and other company stakeholders don’t seem to understand is… repeated interruptions to the work day of a programmer are extremely damaging to that programmer’s productivity. Repeated interruptions to the data entry staff, however, shows almost no affect on their productivity, once the time loss is factored in.

As a senior programmer in the team, I would like to try and educate the managers and other stakeholders as to why repeatedly interrupting the programmers is seriously impacting their ability to complete tasks. I’d like to educate them in such a way that distinguishes the “type” of work a programmer is doing compared to the type of work a data entry officer is doing.

5

I read something recently by a guy who made precisely the same point you are trying to make about the damage to productivity interruptions make on what you are calling knowledge workers. I will try to look him up later this morning and come back to share the information.

6

This sounds like where I work. After our medium-size company was bought by megacorp, our “corporate culture” has changed dramatically. I will be following this thread with interest.

7

This is what I was thinking of. I haven’t watched it again so I don’t know if it’s as good a fit as I recall but it’s in line with what you’re trying to communicate to your bosses, I think.

http://www.ted.com/talks/jason_fried_why_work_doesn_t_happen_at_work.html

8

Times article on multitasking

Freakonomics on multitasking

Another Times thing on multitasking

Another Times article

9

Peter Drucker coined the term “knowledge worker”, and wrote pretty extensively on the topic.

10

You sound very optimistic (or naive, sorry) if you expect managers to be interested to learn anything, even if facts are given.

The usual solution to this is to have a mid-manager - best would be programmer himself - who acts as buffer between management or other areas and the programmers. No personal requests to any programmers, anything must go through the one and only prog. man., who then has both the overview over which programmer is busy with what, how long the new task will roughly take, how many people to assign to one project - and which individuals, etc.

This also means that the prog. man. can explain (in small words) why some requests that non-programmers think would take half an hour in reality are complicated and would require two weeks and is this function really important or just nice to have? The prog. man. would also require and demand a project plan with specifics of what the finished product must be able to do, would be nice to do, should never do, when it must be finished, etc. Basically a contract, and the manager who authorizes that project agrees with it. No more changing their mind three times, forcing the programmers to throw everything away.

For this, the prog. man. needs to be an excellent communicator, because he is the bridge between hazy, unformed wishes of the users, and the reality of the programming world, which is a wide gap. The user says “I want a product that does this and this” because he knows product X that can also do this. The user doesn’t know that function y would be helpful because he doesn’t know if it’s possible. The user also needs functions w, z and r, but doesn’t remember them because they occur seldom - but when they do occurr, they are important.

So the prog. man. should team up with an experienced user and follow him like a shadow for a day, writing down what the user does now, in what way, to get all exceptions. Then he should talk with management if certain processes can be re-organized before writing software that copies the current process and has to be re-designed in a month. Then he can write the specs for the programmers and the contract.

On top of that, in order to stand his ground against higher management, the prog. man. needs himself to be higher management, which usually conflicts with the other qualifications.

So in theory a buffer is nice, in practice, the users usually start going directly to their programmer and bugging him anyway. So I don’t think there’s a solution, sorry.

11

Dream on, constanze. At mega-corp, it is institutional policy that we (developers or anyone else) are available and interruptible by anyone at any time. Our first-line managers, who are very sympathetic to our situation, try to be a buffer where they are able. But that leaves a lot that they are not allowed to have any control over. Basically all the developers are also supposed to be providing support (internal and external) and that always takes priority.

12

This is essentially what we have in our software group, and it works very well. The ony difference is that our manager doesn’t program at all anymore, except in special circumstances. She is a full time manager now. But she used to be a programmer, so she knows about programmers’ issues.

ETA: To address the point made by ratatoskK: Certainly, there are times that our work as programmers has to be interrupted by some corporate shift in priorities or some other reason. But still our manager tries to make it have the least effect on our productivity as possible. By giving any new work to the person who is the least overloaded, for example.

13

Try this essay by Paul Graham. Graham is the founder of Ycombinator, a different kind of VC firm in Silicon Valley. Both Graham and Ycombinator are reasonably famous there.

14

Oh certainly, the manager of programmers themself should not program anymore, they should manage: take care of their programmers with hugs and snacks (figurativly), be a bulldog to managers bothering her programmers, design and structure the projects, get feedback to project status from the programmers …

If managing is done correctly, it requires a lot of time, energy and skills. Sadly, a lot of managers get the position through other requirements like hot air and college certificates.

15

You may not want this…

I’m a programmer. I’ve had to deal with situations where this “mid-manager” mangles requirements (basically through the “telephone” game), and tells me to do something other than what the requestor actually wants)

16

Hey, I didn’t say it worked well in real life. In theory, managers generally are there to oversee people who do the work, often specialists and experts, and, you know, manage things so that the workers can concentrate on doing their job; in practice, a lot of managers either let things run their bad course or activly interfere to make the workers job harder.

The alternative to a mid-level manager is usually no mid-level manager, which means that several programmers meet with several customers, have the problem of trying to find a common language, like:

programmers: we can build function x in y days
customers: sure! :slight_smile:
after the beta-test, c: we really need function w and s, too
p: why didn’t you say so earlier? :rolleyes:
c: we didn’t realize it :smack:

or three customers bugging the same programmer, because he’s nice when answering the phone, never mind how busy he really is.

17

The trouble is that the distinction is not really white-blue collar. A really good car mechanic, for example, is wort their weight in gold; as anyone who has taken a car in with a persistent problem can attest. This is particularly true in the days of complicated, computer-controller autos.

Programming or mechanics, what it relies on is good analytical and problem-solving skills, and likely a long background of experience in similar situations (The “I’ve seen it all” experience.)

Another major misconception of management is that repair time for complex problems can be scheduled, let alone predicted - “4 hours to fix the overtime issue”. A particular problem, say , with a program may take an hour or a week to solve. I’ve had to endure various management “flavour of the month” management theories. Covey Time-Text or similar wonder planners might work for sales or accounting, but for programming it does not - particularly when 90% of what you do is reactive to problems rather than proactive “green-field” programming. (The best expression for management “Flavour of the Month” was BOHICA, for “Bend Over Here It Comes Again”).

18

Not really valid, there are lots of white collar process jobs. I have one in the call center I work at.