Datasheet

active learning processes, we gain many useful insights into the process by

which software is developed and deployed. By recognizing IT staff as knowl-

edge workers, a rich ﬁeld of literature and experience opens up from which we

may learn from to help improve our own practice.

From the same book quoted above, we can distil a list of knowledge work

characteristics:

Knowledge workers like autonomy: they don’t like being told what to do.

Specifying detailed steps to follow is less valuable than in other types of

work.

Knowledge workers ﬁnd it difﬁcult to describe what they do in detail: if

you want to know, you’re better off watching.

Not only do knowledge workers ﬁnd it difﬁcult to describe what they do,

but they’re aware of the value of knowledge and don’t share it without a

motivation.

Even though they may not be able to describe what they do, these workers

often have good reason for doing what they do and have often thought in

advance about the way in which they work.

Commitment matters and makes a huge difference in productivity.

Looking at this list, two things stand out: ﬁrstly, this is a list of developer

characteristics too, so any doubt that developers are knowledge workers should

be dispelled. Secondly, an individual with these characteristics is unlikely to

relish routine, factory-like, work. The traditional view of management isn’t

applicable to these workers.

Recognizing that IT workers are knowledge workers also recognizes that

they’re not unique. They share the same characteristics as other knowledge

workers. Nor are the problems that they encounter unique. The opportunities

and problems faced by IT staff and their managers are quite legitimate, and are

shared by other modern knowledge workers. Consequently, it is wrong to think

of the IT geek as a class apart.

Once we recognize software developers as knowledge workers, it becomes

clear that development activities – specifying, designing, coding and testing

new software – are themselves knowledge activities. Such activities are

completely different from traditional factory production line processes, where

a worker’s individual knowledge makes little immediate difference to the end

product. Having recognized this critical difference, it becomes meaningless to

characterize software development as a factory process.

Many previous attempts to change the way in which IT staff work were

misplaced because they failed to recognize the roles of knowledge and the

characteristics of knowledge workers. Naive attempts at quality improvement,

productivity enhancement and cost cutting that draw on manufacturing

experience are simply wrong.

Introduction 7