《高效的项目和团队》

Productive Projects and Teams是一本好书。 许多其中许多关于管理和沟通的精辟言论让我大有相见很晚之感。其实不仅是软件的开发项目，任何项目，甚至任何行业的管理，都首先是对人的管理，然后才是对事物的管理，所以设身处地的为别人着想，用鼓励来代替批评，用相互学习来取消互相排挤，在失败中学习，在前进中自醒，则无往而不胜。

鉴于原书是英文的，我打算利用业余时间把它翻译成中文，一来方便后学者，二来以此提高自己的英文水平。我将在这里随时提供翻译的最新动态。

下面是原文文本

PART I
MANAGING THE HUMAN
RESOURCE


Most of us as managers are prone to one particular failing: a 
tendency to manage people as though they were modular components. 
It's obvious enough where this tendency comes from. 
Consider the preparation we had for the task of management: We 
were judged to be good management material because we performed 
well as doers, as technicians and developers. That often involved 
organizing our resources into modular pieces, such as software routines, 
circuits, or other units of work. The modules we constructed 
were made to exhibit a black-box characteristic, so that their internal 
idiosyncrasies could be safely ignored. They were designed to be 
used with a standard interface. 

After years of reliance on these modular methods, small wonder 
that as newly promoted managers, we try to manage our human 
resources the same way. Unfortunately, it doesn't work very well. 

In Part I, we begin to investigate a very different way of 
thinking about and managing people. That way involves specific 
accommodation to the very nonmodular character of the human 
resource. 


Chapter 1 

SOMEWHERE TODAY,
A PROJECT IS FAILING


Since the days when computers first came into common use, 
there must have been tens of thousands of accounts receivable programs 
written. There are probably a dozen or more accounts receivable 
projects underway as you read these words. And somewhere 
today, one of them is failing. 

Imagine that! A project requiring no real technical innovation 
is going down the tubes. Accounts receivable is a wheel that's been 
reinvented so often that many veteran developers could stumble 
through such projects with their eyes closed. Yet these efforts 
sometimes still manage to fail. 

Suppose that at the end of one of these debacles, you were 
called upon to perform an autopsy. (It would never happen, of 
course; there is an inviolable industry standard that prohibits examining 
our failures.) Suppose, before all the participants had scurried 
off for cover, you got a chance to figure out what had gone wrong. 
One thing you would not find is that the technology had sunk the 
project. Safe to say, the state of the art has advanced sufficiently so 
that accounts receivable systems are technically possible. Something 
else must be the explanation. 

Each year since 1977, we have conducted a survey of development 
projects and their results. We've measured project size, 
cost, defects, acceleration factors, and success or failure in meeting 
schedules. We've now accumulated more than five hundred project 
histories, all of them from real-world development efforts. 

We observe that about fifteen percent of all projects studied 
came to naught: They were canceled or aborted or "postponed" or 


4 PEOPLEWARE 

they delivered products that were never used. For bigger projects, 
the odds are even worse. Fully twenty-five percent of projects that 
lasted twenty-five work-years or more failed to complete. In the 
early surveys, we discarded these failed data points and analyzed the 
others. Since 1979, though, we've been contacting whoever is left 
of the project staff to find out what went wrong. For the overwhelming 
majority of the bankrupt projects we studied, there was 
not a single technological issue to explain the failure, 

The Name of the Game 

The cause of failure most frequently cited by our survey participants 
was "politics." But now observe that people tend to use this word 
rather sloppily. Included under "politics" are such unrelated or 
loosely related things as communication problems, staffing problems, 
disenchantment with the boss or with the client, lack of motivation, 
and high turnover. People often use the word politics to 
describe any aspect of the work that is people-related, but the 
English language provides a much more precise term for these 
effects: They constitute the project's sociology. The truly political 
problems are a tiny and pathological subset. 

If you think of a problem as political in nature, you tend to be 
fatalistic about it. You know you can stand up to technical challenges, 
but honestly, who among us can feel confident in the realm 
of politics? By noting the true nature of a problem as sociological 
rather than political, you make it more tractable. Project and team 
sociology may be a bit outside your field of expertise, but not 
beyond your capabilities. 

Whatever you name these people-related problems, they're 
more likely to cause you trouble on your next assignment than all the 
design, implementation, and methodology issues you'll have to deal 
with. In fact, that idea is the underlying thesis of this whole book: 

The major problems of our work are not so much 

technological as sociological in nature. 

Most managers are willing to concede the idea that they've got 
more people worries than technical worries. But they seldom manage 
that way. They manage as though technology were their principal 
concern. They spend their time puzzling over the most convoluted 
and most interesting puzzles that their people will have to 


SOMEWHERE TODAY, A PROJECT IS FAILING 5 

solve, almost as though they themselves were going to do the work 
rather than manage it. They are forever on the lookout for a technical 
whiz-bang that promises to automate away part of the work (see 
Chapter 6, "Laetrile," for more on this effect). The most strongly 
people-oriented aspects of their responsibility are often given the 
lowest priority. 

Part of this phenomenon is due to the upbringing of the average 
manager. He or she was schooled in how the job is done, not 
how the job is managed. It's a rare firm in which new managers 
have done anything that specifically indicates an ability or an aptitude 
for management. They've got little management experience and 
no meaningful practice. So how do new managers succeed in convincing 
themselves that they can safely spend most of their time 
thinking technology and little or no time thinking about the people 
side of the problem? 

The High-Tech Illusion 

Perhaps the answer is what we've come to think of as the High-
Tech Illusion: the widely held conviction among people who deal 
with any aspect of new technology (as who of us does not?) that 
they are in an intrinsically high-tech business. They are indulging in 
the illusion whenever they find themselves explaining at a cocktail 
party, say, that they are "in computers," or "in telecommunications," 
or "in electronic funds transfer." The implication is that they are part 
of the high-tech world. Just between us, they usually aren't. The 
researchers who made fundamental breakthroughs in those areas are 
in a high-tech business. The rest of us are appliers of their work. 
We use computers and other new technology components to develop 
our products or to organize our affairs. Because we go about this 
work in teams and projects and other tightly knit working groups, 
we are mostly in the human communication business. Our successes 
stem from good human interactions by all participants in the 
effort, and our failures stem from poor human interactions. 

The main reason we tend to focus on the technical rather than 
the human side of the work is not because it's more crucial, but 
because it's easier to do. Getting the new disk drive installed is positively 
trivial compared to figuring out why Horace is in a blue funk 
or why Susan is dissatisfied with the company after only a few 
months. Human interactions are complicated and never very crisp 
and clean in their effects, but they matter more than any other aspect 
of the work. 


6 PEQPLEWARE 

If you find yourself concentrating on the technology rather 
than the sociology, you're like the vaudeville character who loses 
his keys on a dark street and looks for them on the adjacent street 
because, as he explains, "The light is better there." 


Chapter 2


MAKE A CHEESEBURGER,
SELL A CHEESEBURGER


Development is inherently different from production. But 
managers of development and allied efforts often allow their thinking 
to be shaped by a management philosophy derived entirely from 
a production environment. 

Imagine for the moment that you're the manager of the local 
fast food franchise. It makes perfect sense for you to take any or all 
of the following efficient production measures: 

. Squeeze out error. Make the machine (the human machine) 
run as smoothly as possible. 
Take a hard line about people goofing off on the job. 
. Treat workers as interchangeable pieces of the machine. 
. Optimize the steady state. (Don't even think about how the 
operation got up to speed, or what it would take to close it 
down.) 
. Standardize procedure. Do everything by the book. 
. Eliminate experimentation—that's what the folks at headquarters 
are paid for. 
These would be reasonable approaches if you were in the fast food 
business (or any production environment), but you're not. The 
"make a cheeseburger, sell a cheeseburger" mentality can be fatal in 
your development area. It can only serve to damp your people's 
spirits and focus their attention away from the real problems at hand. 
This style ofmanagementwill be directly atodds with the work. 


8 PEOPLEWARE 

To manage thinking workers effectively, you need to take 
measures nearly opposite those listed above. Our proposed opposite 
approaches are described in the following sections. 

A Quota for Errors 

For most thinking workers, making an occasional mistake is a natural 
and healthy part of their work. But there can be an almost Biblical 
association between error on the job and sin. This is an attitude 
we need to take specific pains to change. 

Speaking to a group of software managers, we introduced a 
strategy for what we think of as iterative design. The idea is that 
some designs are intrinsically defect-prone; they ought to be rejected, 
not repaired. Such dead ends should be expected in the design 
activity. The lost effort of the dead end is a small price to pay for a 
clean, fresh start. To our surprise, many managers felt this would 
pose an impossible political problem for their own bosses: "How 
can we throw away a product that our company has paid to produce?" 
They seemed to believe that they'd be better off salvaging 
the defective version even though it might cost more in the long run. 

Fostering an atmosphere that doesn't allow for error simply 
makes people defensive. They don't try things that may turn out 
badly. You encourage this defensiveness when you try to systematize 
the process, when you impose rigid methodologies so that staff 
members are not allowed to make any of the key strategic decisions 
lest they make them incorrectly. The average level of technology 
may be modestly improved by any steps you take to inhibit error. 
The team sociology, however, can suffer grievously. 

The opposite approach would be to encourage people to make 
some errors. You do this by asking your folks on occasion what 
dead-end roads they've been down, and by making sure they 
understand that "none" is not the best answer. When people blow 
it, they should be congratulated—that's part of what they're being 
paid for. 

Management: The Bozo Definition 

Management is a complex enough thing to defy simple definition, 
but that nuance was lost on one senior manager we encountered at a 
professional society meeting in London. He summed up his entire 


MAKE A CHEESEBURGER,SELL ACHEESEBURGER 9 

view of the subject with this statement: "Management is kicking 
ass." This equates to the view that managers provide all the thinking 
and the people underneath them just carry out their bidding. Again, 
that might be workable for cheeseburger production, but not for any 
effort for which people do the work with their heads rather than their 
hands. Everyone in such an environment has got to have the brain 
in gear. You may be able to kick people to make them active, but 
not to make them creative, inventive, and thoughtful. 

Even if kicking people in the backside did boost their short-
term productivity, it might not be useful in the long run: There is 
nothing more discouraging to any worker than the sense that his 
own motivation is inadequate and has to be "supplemented" by that 
of the boss. 

The saddest thing about this management approach is that it's 
almost always superfluous. You seldom need to take Draconian 
measures to keep your people working; most of them love their 
work. You may even have to take steps sometimes to make them 
work less, and thus get more meaningful work done (more about 
this idea in Chapter 3). 

The People Store 

In a production environment, it's convenient to think of people as 
parts of the machine. When a part wears out, you get another. The 
replacement part is interchangeable with the original. You order a 
new one, more or less, by number. 

Many development managers adopt the same* attitude. They go 
to great lengths to convince themselves that no one is irreplaceable. 
Because they fear that a key person will leave, they force themselves 
to believe that there is no such thing as a key person. Isn't that the 
essence of management, after all, to make sure that the work goes 
on whether the individuals stay or not? They act as though there 
were a magical People Store they could call up and say, "Send me a 
new George Gardenhyer, but make him a little less uppity." 

One of my clients brought a splendid employee into a 
salary review and was just amazed that the fellow 
wanted something other than money. He said that he 
often had good ideas at home but that his slow dial-up 
terminal was a real bother to use. Couldn't the company 
install a new line into his house and buy him a 


10 PEOPLEWARE 

high-performance terminal? The company could. In 
subsequent years, it even built and furnished a small 
home office for the fellow. But my client is an unusual 
case. I wonder what a less perceptive manager would 
have done. Too many managers are threatened by anything 
their workers do to assert their individuality. 

—TRL 

One example ofjust such a less perceptive manager was a boss 
who showed extreme signs of being threatened by his people's 
individuality: He had one very talented worker on the road for much 
of the year visiting client sites and as a result living on expense 
account. An analysis of the man's expense reports showed that his 
expenditures on food were way out of line with those of other travelers. 
He spent fifty percent more on food than the others did. In 
an indignant public memo, the boss branded the worker a "food 
criminal." Now, the worker's total expenditures weren't out of line; 
whatever extra he spent on food, he saved on something else. The 
man was not more expensive, he was just different. 

The uniqueness of every worker is a continued annoyance to 
the manager who has blindly adopted a management style from the 
production world. The natural people manager, on the other hand, 
realizes that uniqueness is what makes project chemistry vital and 
effective. It's something to be cultivated. 

A Project in Steady State Is Dead 

Steady-state production thinking is particularly ill-suited to project 
work. We tend to forget that a project's entire purpose in life is to 
put itself out of business. The only steady state in the life of a project 
is rigor mortis. Unless you're riding herd on a canceled or 
about-to-be-canceled project, the entire focus of project management 
ought to be the dynamics of the development effort. Yet the way we 
assess people's value to a new project is often based on their steady-
state characteristics: how much code they can write or how much 
documentation they can produce. We pay far too little attention to 
how well each of them/ite into the effort as a whole. 

/ was teaching an in-house design course some years 
ago, when one of the upper managers buttonholed me to 
request that I assess some of the people in the course 


MAKE A CHEESEBURGER, SELL A CHEESEBURGER 11 

(his project staff). He was particularly curious about 
one woman. It was obvious he had his doubts about her: 
"I don't quite see what she adds to a project^she's not a 
great developer or tester or much of anything." With a 
little investigation, I turned up this intriguing fact: 
During her twelve years at the company, the woman in 
question had never worked on a project that had been 
anything other than a huge success. It wasn't obvious 
what she was adding, but projects always succeeded 
when she was around. After watching her in class for a 
week and talking to some of her co-workers, I came to 
the conclusion that she was a superb catalyst. Teams 
naturally jelled better when she was there. She helped 
people communicate with each other and get along. 
Projects were more fun when she was part of them. 
When I tried to explain this idea to the manager, I 
struck out. He just didn't recognize the role of catalyst 
as essential to a project. 

-TDM 

The catalyst is important because the project is always in a 
state of flux. Someone who can help a project to jell is worth two 
people who just do work. 

We Haven't Got Time to Think About This Job, 
Only to Do It 

If you are charged with getting a task done, what proportion of your 
time ought to be dedicated to actually doing the task? Not one hundred 
percent. There ought to be some provision for brainstorming, 
investigating new methods, figuring out how to avoid doing some 
of the subtasks, reading, training, and just goofing off. 

Looking back over our own years as managers, we've both 
concluded that we were off-track on this subject. We spent far too 
much of our time trying to get things done and not nearly enough 
time asking the key question, "Ought this thing to be done at all?" 
The steady-state cheeseburger mentality barely even pays lip service 
to the idea of thinking on the job. Its every inclination is to push the 
effort into one hundred percent do-mode. If an excuse is needed for 
the lack of think-time, the excuse is always time pressure—as 
though there were ever work to be done without time pressure. 




The importance of a more considered approach goes up 
sharply as the stakes increase. It's when the truly Herculean effort 
is called for that we have to learn to do work less of the time and 
think about the work more. The more heroic the effort required, the 
more important it is that the team members learn to interact well and 
enjoy it The project that has to be done by an impossible fixed date 
is the very one that can't afford not to have frequent brainstorms and 
even a project dinner or some such affair to help the individual participants 
knitinto aneffective whole. 

But all that is motherhood. Everybody knows that and acts 
accordingly, right? Wrong. We are so single-mindedly oriented 
toward Doing Something, Anything that we spend a scant five percent 
ofour time on the combined activities ofplanning, investigating 
new methods, training, reading books, estimating, budgeting, 
scheduling, and allocating personnel. (The five percent figure comes 
from an analysis of system development projects, but it seems to 
apply more broadly than that, perhaps to the entire category of 
salaried workers.) 

The statistics about reading are particularly discouraging: The 
average software developer, for example, doesn't own a single book 
on the subject of his or her work, and hasn't ever read one. That 
fact is horrifying for anyone concerned about the quality of work in 
the field; for folks like us who write books, it is positively tragic. 


Chapter 3


VIENNA WAITSFOR YOU


Some years ago I was swapping war stories with the 
manager of a large project in southern California. He 
began to refate the effect that his project and its crazy 
hours had had on his staff. There were two divorces 
that he could trace directly to the overtime his people 
were putting in, and one of his worker's kids had gotten 
into some kind of trouble with drugs, probably because 
his father had been too busy for parenting during the 
past year. Finally there had been the nervous breakdown 
of the test team leader. 

As he continued through these horrors, I began to 
realize that in his own strange way, the man was bragging. 
You might suspect that with another divorce or 
two and a suicide, the project would have been a complete 
success, at least in his eyes. 

—TDM 

For all the talk about "working smarter," there is a widespread 
sense that what real-world management is all about is getting people 
to work harder and longer, largely at the expense of their personal 
lives. Managers are forever tooting their horns about the quantity of 
overtime their people put in, and the tricks one can use to get even 
more out of them. 


14 PEOPCEWARE 

Spanish Theory Management 

Historians long ago formed an abstraction about different theories of 
value: The Spanish Theory, for one, held that only a fixed amount 
of value existed on earth, and therefore the path to the accumulation 
of wealth was to learn to extract it more efficiently from the soil or 
from people's backs. Then there was the English Theory that held 
that value could be created through ingenuity and technology. So 
the English had an Industrial Revolution, while the Spanish spun 
their wheels trying to exploit the land and the Indians in the New 
World. They moved huge quantities of gold across the ocean, and 
all they got for their effort was enormous inflation (too much gold 
money chasing too few usable goods). 

The Spanish Theory of Value is alive and well among managers 
everywhere. You see that whenever they talk about productivity. 
Productivity ought to mean achieving more in an hour of 
work, but all too often it has come to mean extracting more for an 
hour of pay. There is a large difference. The Spanish Theory managers 
dream of attaining new productivity levels through the simple 
mechanism of unpaid overtime. They divide whatever work is done 
in a week by forty hours, not by the eighty or ninety hours that the 
worker actually put in. 

That's not exactly productivity—it?s more like fraud—but 
it's the state of the art for many American managers. They bully and 
cajole their people into long hours. They impress upon them how 
important the delivery date is (even though it may be totally arbitrary; 
the world isn't going to stop just because a project completes a 
month late). They trick them into accepting hopelessly tight schedules, 
shame them into sacrificing any and all to meet the deadline, 
and do anything to get them to work longer and harder. 

And Now a Word from the Home Front 

Although your staff may be exposed to the message "Work longer 
and harder" while they're at the office, they're getting a very different 
message at home. The message at home is, "Life is passing you 
by. Your laundry is piling up in the closet, your babies are uncuddled, 
your spouse is starting to look elsewhere. There is only one 


VIENNA WAITS FOR YOU 15 

time around on this merry-go-round called life, only one shot at the 
brass ring. And if you use your life up on COBOL.,." 

But you know when the truth is told,
That you can get what you want or you can just get old.
You're going to kick off before you even get halfway through.
When will you realize . . . Vienna waits for you?


—"The Stranger," Billy Joel 

The Vienna that waits for you, in Billy Joel's phrase, is the 
last stop on your personal itinerary. When you get there, it's all 
over. If you think your project members never worry about such 
weighty matters, think again. Your people are very aware of the one 
short life that each person is allotted. And they know too well that 
there has got to be something more important than the silly job 
they're working on. 

There AIn?i No .Such Thing as Overtime 

Overtime for salaried workers is a figment of the naive manager's 
imagination. Oh, there might be some benefit in a few extra hours 
worked on Saturday to meet a Monday deadline, but that's almost 
always followed by an equal period of compensatory "undertime" 
while the workers catch up with their lives. Throughout the effort 
there will be more or less an hour of undertime for every hour of 
overtime. The trade-off might work to your advantage for the short 
term, but for the long term it will cancel out 

Slow down you crazy child, 

And take the phone off the hook and disappear for a while. 

It's all right. You can afford to lose a day or two. 

When will you realize . . . Vienna waits for you? 

Just as the unpaid overtime was largely invisible to the Spanish 
Theory manager (who always counts the week as forty hours 
regardless of how much time the people put in), so too is the undertime 
invisible. You never see it on anybody's time sheet. It's time 
spent on the phone or in bull sessions or just resting. Nobody can 


16 PEOPLEWARE 

really work much more than forty hours, at least not continually and 
with the level of intensity required for creative work. 

Overtime is like sprinting: It makes some sense for the last 
hundred yards of the marathon for those with any energy left, but if 
you start sprinting in the first mile, you're just wasting time. Trying 
to get people to sprint too much can only result in loss of respect for 
the manager. The best workers have been through it all before; they 
know enough to keep silent and roll their eyes while the manager 
raves on that the job has got to get done by April. Then they take 
their compensatory undertime when they can, and end up putting in 
forty hours of real work each week. The best workers react that 
way; the others are workaholics. 

Workaholics 

Workaholics will put in uncompensated overtime. They'll work 
extravagant hours, though perhaps with declining effectiveness. Put 
them under enough pressure and they will go a long way toward 
spoiling their personal lives. But only for a while. Sooner or later 
the message comes through to even the most dedicated workaholic: 

Slow down, you're doing fine,
You can't be everything you want to be before your time.
Although it's so romantic on the borderline tonight.
But when will you realize . . . Vienna waits for you?


Once that idea is digested, the worker is lost forever after to 
the project. The realization that one has sacrificed a more important 
value (family, love, home, youth) for a less important value (work) 
is devastating. It makes the person who has unwittingly sacrificed 
seek revenge. He doesn't go to the boss and explain calmly and 
thoughtfully that things have to change in the future—he just quits, 
another case of burnout. One way or the other, he's gone. 

Workaholism is an illness, but not an illness like alcoholism 
that affects only the unlucky few. Workaholism is more like the 
common cold: Everyone has a bout of it now and then. Our purpose 
in writing about it here is not so much to discuss its causes and 
cures, but to address the simpler problem of how you, the manager, 
ought to deal with your workaholics. If you exploit them to the hilt 
in typical Spanish Theory fashion, you'll eventually lose them. No 
matter how desperately you need them to put in all those hours, you 


VIENNA WAITS FOR YOU 17 

can't let them do so at the expense of their personal lives. The loss 
of a good person isn't worth it. This point goes beyond the narrow 
area of workaholism, into the much more complex subject of meaningful 
productivity. 

Productivity: Winning Battles and Losing Wars 

Next time you hear someone talking about productivity, listen carefully 
to hear if the speaker ever uses the word turnover. Chances 
are that he or she will not. In years of hearing productivity discussed 
and in hundreds of articles about it, we have never encountered 
a single expert that had anything to say about the related subject 
of turnover. But what sense can it possibly make to discuss one 
without the other? Consider some of the things that organizations 
typically do to improve productivity: 

. pressure, people to put in more hours 
. mechanize the process of product development 
. compromise the quality of the product (more about this in 
the next chapter) 
. standardize procedures 
Any of these measures can potentially make the work less enjoyable 
and less satisfying. Hence, the process of improving productivity 
risks worsening turnover. That doesn't say you can't improve productivity 
without paying a turnover price. It only says you need to 
take turnover into account whenever you set out to attain higher 
productivity. Otherwise, you may achieve an "improvement" that is 
more than offset by the loss of your key people. 

Most organizations don't even keep statistics on turnover. 
Virtually none can tell you what replacement of an experienced 
worker costs. And whenever productivity is considered, it is done 
as though turnover were nonexistent or cost-free. The Eagle project 
at Data General is a case in point The project was a Spanish Theory 
triumph: Workaholic project members put in endless unpaid overtime 
hours to push productivity to unheard of levels. At the end of 
the project, virtually the entire development staff quit What was the 
cost of that? No one even figured it into the equation. 

Productivity has to be defined as benefit divided by cost. The 
benefit is observed dollar savings and revenue from the work per



18 PEOPLEWARE 

formed, and cost is the total cost, including replacement of any 
workers used up by the effort. 

Reprise 

During the past year, I did some consulting for a project 
that was proceeding so smoothly that the project 
manager knew she would deliver the product on schedule. 
She was summoned in front of the management 
committee and asked for a progress report. She said 
she could guarantee that her product would be ready by 
the deadline of March 1, exactly on time according to 
the original estimate. The upper managers chewed over 
that piece of unexpected good news and then called her 
in again the next day. Since she was on time for March 
1, they explained, the deadline had been moved up to 
January 15. 

—TRL 

A schedule that the project could actually meet was of no value 
to those Spanish Theory managers, because it didn't put the people 
under pressure. Better to have a hopelessly impossible schedule to 
extract more labor from the workers. 

Chances are, you've known one or more Spanish Theory 
managers during your career. It's all very well to smile at their 
short-sightedness, but don't let yourself off the hook too easily. 
Each of us has succumbed at one time or another to the short-term 
tactic of putting people under pressure to get them to work harder. 
In order to do mis, we have to ignore their decreased effectiveness 
and the resultant turnover, but ignoring bad side effects is easy. 
What's not so easy is keeping in mind an inconvenient truth like this 
one: 

People under time pressure don't work better; 
they Just work faster. 

In order to work faster, they may have to sacrifice the quality 
of the product and their own job satisfaction. 


Chapter 4


QUALITY—IF TIME PERMITS


Twentieth centurypsychological theory holds that man's character 
is dominated by a small number of basic instincts: survival, 
self-esteem, reproduction, territory, and so forth. These are built 
directly into the brain's firmware. You can consider these instincts 
intellectually without great passion (that's what you're doing now), 
but when you feel them, there is always passion involved Even the 
slightest challenge to one of these built-in values can be upsetting. 

Whenever strong emotions are aroused, it's an indication that 
one of the brain's instinctive values has been threatened. A novice 
manager may believe that work can be completed without people's 
emotions ever getting involved but if you have any experience at all 
as a manager, you have learned the opposite. Our work gives us 
plenty of opportunity to exercise the emotions. 

Chances are, you can think of at least one incident when a 
person's emotions did flare up as a direct result of something purely 
work-related Consider that incident now and ask yourself (probably 
for the nth time), Where did all the emotion come from? Without 
knowing anything about your specific incident, we're willing to bet 
that threatened self-esteem was a factor. There may be many and 
varied causes of emotional reaction in one's personal life, but in the 
workplace, the major arouser of emotions is threatened self-esteem. 

We all tend to tie our self-esteem strongly to the quality of the 
product we produce—not the quantity of product, but the quality, 
(For some reason, there is little satisfaction in turning out huge 
amounts of mediocre stuff, although that may be just what's 
required for a given situation.) Any step you take that may jeopar



20 PEOPLEWARE 

dize the quality of the product is likely to set the emotions of your 
staff directly against you. 

The Flight from Excellence 

Managers jeopardize product quality by setting unreachable deadlines. 
They don't think about their action in such terms; they think 
rather that what they're doing is throwing down an interesting challenge 
to their workers, something to help them strive for excellence. 

Experienced (jaded) workers know otherwise. They know 
that under the gun, their efforts will be overconstrained. There will 
be no freedom to trade off resources to make on-time delivery possible. 
They won't have the option of more people or reduced function. 
The only thing to give on will be quality. Workers kept under 
extreme time pressure will begin to sacrifice quality. They will push 
problems under the rug to be dealt with later or foisted off onto the 
product's end user. They will deliver products that are unstable and 
not really complete. They will hate what they're doing, but what 
other choice do they have? 

The hard-nosed, real-world manager part of you has an 
answer to all this: "Some of my folks would tinker forever with a 
task, all in the name of 'Quality.' But the market doesn't give a 
damn about that much quality—it's screaming for the product to be 
delivered yesterday and will accept it even in a quick-and-dirty 
state." In many cases, you may be right about the market, but the 
decision to pressure people into delivering a product that doesn't 
measure up to their own quality standards is almost always a mistake. 


We managers tend to think of quality as just another attribute 
of the product, something that may be supplied in varying degrees 
according to the needs of the marketplace. It's like the chocolate 
sauce you pour onto a homemade sundae: more for people who 
want more, and less for people who want less. 

The builders' view of quality, on the other hand, is very different. 
Since their self-esteem is strongly tied to the quality of the 
product, they tend to impose quality standards of their own. The 
minimum that will satisfy them is more or less the best quality they 
have achieved in the past. This is invariably a higher standard than 
what the market requires and is willing to pay for. 


QUALITY—IF TIME PERMITS 21 

"The market doesn't give a damn about that much quality." 
Read those words and weep, because they are almost always true. 
People may talk in glowing terms about quality or complain bitterly 
about its absence, but when it comes time to pay the price for quality, 
their true values become apparent. On a software project, for 
instance, you might be able to make the following kind of presentation 
to your users: "We can extrapolate from empirical evidence that 
the Mean Time Between Failures for this product is now approximately 
1.2 hours. So if we deliver it to you today, on time, it will 
have very poor stability. If we put in another three weeks, we can 
forecast MTBF of approximately 2,000 hours, a rather respectable 
result." Expect to see some Olympic-class hemming and hawing. 
The users will explain that they are as quality-conscious as the next 
fellow, but three weeks is real money. 

Speaking of software, that industry has accustomed its clients 
to accept in-house developed application programs with an average 
defect density of one to three defects per hundred lines of code! 
With sublime irony, this disastrous record is often blamed on poor 
quality consciousness of the builders. That is, those same folks 
who are chided for being inclined to "tinker forever with a program, 
all in the name of 'Quality'" are also getting blamed for poor 
Let's put the blame where it belongs. He who pays the piper is 
calling for a low-quality tune. By regularly putting the development 
process under extreme time pressure and then accepting poor-quality 
products, the software user community has shown its true quality 
standard. 


All of this may sound like a diatribe against software users and 
against the standards of the marketplace in general, but it needn't be 
taken that way. We have to assume that the people who pay for our 
work are of sound enough mind to make a sensible trade-off between 
quality and cost. The point here is that the client's perceived 
needs for quality in the product are often not as great as those of the 
builder. There is a natural conflict. Reducing the quality of a product 
is likely to cause some people not to buy, but the reduced market 
penetration that results from virtually any such quality reduction will 
often be more than offset by increased profit on each item sold. 

Allowing the standard of quality to be set by the buyer, rather 
than the builder, is what we call the flight from excellence. A market-
derived quality standard seems to make good sense only as long 
as you ignore the effect on the builder's attitude and effectiveness. 


22 PEOPLEWARE 

In the long run, market-based quality costs more. The lesson 
here is, 

Quality, far beyond that required by the end user, 
is a means to higher productivity. 

If you doubt that notion, imagine the following gedanken 
experiment: Ask one hundred people on the street what organization 
or culture or nation is famous for high quality. We predict that more 
than half the people today would answer, "Japan." Now ask a different 
hundred people what organization or culture or nation is 
famous for high productivity. Again, the majority can be expected 
to mention, "Japan." The nation that is an acknowledged quality 
leader is also known for its high productivity. 

Wait a minute. How is it possible that higher quality coexists 
with higher productivity? That flies in the face of the common wisdom 
that adding quality to a product means you pay more to build it. 
For a clue, read the words of Tajima and Matsubara, two of the 
most respected commentators on the Japanese phenomenon: 

The trade-off between price and quality does not exist 
in Japan. Rather, the idea that high quality brings on 
cost reduction is widely accepted. 

Quality Is Free, But . . . 

Philip Crosby presented this same concept in his book, Quality Is 
Free, published in 1979. In this work, Crosby gave numerous 
examples and a sound rationale for the idea that letting the builder set 
a satisfying quality standard of his own will result in a productivity 
gain sufficient to offset the cost of improved quality. 

We have an awful inkling that Crosby's book has done more 
harm than good in industry. The problem is that the great majority 
of managers haven't read it, but everybody has heard the title. The 
title has become the whole message. Managers everywhere are 
enthusing over quality: "The sky's the limit for quality, we'll have 
as much free quality as we can get!" This hardly boils down to a 
positive quality consciousness. The attitude is just the opposite of 
what Crosby advocates. 


QUALITY—IF TIME PERMITS 23 

The real message of the linked quality and productivity effects 
needs to be presented in slightly different terms: 

Quality Is free, but only to those who are willing 
to pay heavily for it. 

The organization that is willing to budget only zero dollars and 
zero cents for quality will always get its money's worth, A policy 
of "Quality—If Time Permits" will assure that no quality at all 
sneaks into the product. 

Hewlett-Packard is an example of an organization that reaps 
the benefits from increased productivity due to high, builder-set 
quality standards. The company makes a cult of quality. In such an 
environment, the argument that more time or money is needed to 
produce a high-quality product is generally not heard. The result is 
that developers know they are part of a culture that delivers quality 
beyond what the marketplace requires. Their sense of quality 
identification works for increased job satisfaction and some of the 
lowest turnover figures seen anywhere in the industry. 

Power of Veto 

In some Japanese companies, notably Hitachi Software and parts of 
Fujitsu, the project team has an effective power of veto over delivery 
of what they believe to be a not-yet-ready product. No matter that 
the client would be willing to accept even a substandard product, the 
team can insist that delivery wait until its own standards are 
achieved. Of course, project managers are under the same pressure 
there that they are here: They're being pressed to deliver something, 
anything, right away. But enough of a quality culture has been built 
up so that these Japanese managers know better than to bully their 
workers into settling for lower quality. 

Could you give your people power of veto over delivery? Of 
course it would take nerves of steel, at least the first time. Your 
principal concern would be that Parkinson's Law would be working 
against you. That's an important enough subject to warrant a chapter 
of its own. 


Chapter 5


PARKINSON'S LAW REVISITED


Writing in 1954, the British author C. Northcote Parkinson 
introduced the notion that work expands to fill the time allocated for 
it, now known as Parkinson's Law. 

If you didn't know that few managers receive any management 
training at all, you might think there was a school they all went to 
for an intensive course on Parkinson's Law and its ramifications. 
Even managers that know they know nothing about management 
nonetheless cling to that one axiomatic truth governing people and 
their attitude toward work: Parkinson's Law. It gives them the 
strongest possible conviction that-the only way to get work done at 
all is to set an impossibly optimistic delivery date. 

Parkinson's Law and Newton's Law 

Parkinson's Law is a long way from being axiomatic. It's not a law 
in the same sense that Newton's law is a law. Newton was a scientist. 
He investigated the gravitational effect according to the strictest 
scientific method. His law was only propounded after rigorous 
verification and testing. It has stood the test of some two hundred 
years of subsequent study. 

Parkinson was not a scientist. He collected no data, he probably 
didn't even understand the rules of statistical inference. Parkinson 
was a humorist. His "law" didn't catch on because it was so 
true. It caught on because it was funny. 

O/l 


PARKINSON'S LAW REVISITED 25 

Of course, Parkinson's Law wouldn't be funny if there 
weren't a germ of truth in it. Parkinson cites examples of his law as 
observed in a fictitious government bureaucracy, some believe patterned 
on the British Post Office. Bureaucracies are prone to such 
problems, because they give little job-derived satisfaction to their 
workers. But you probably don't work in a bureaucracy. Even if 
you do, you go to great lengths to make sure that your people are 
spared its effects, otherwise they'd never get anything done. The 
result is that your people have the possibility of lots ofjob-derived 
satisfaction. That leads to a simple truth worth stating: 

Parkinson's Law almost certainly doesn't apply to 
your people. 

Their lives are just too short for any loafing on the job. Since 
they enjoy their work, they are disinclined to let it drag on forever—
that would just delay the satisfaction they all hanker for. They 
are as eager as you are to get the job done, provided only that they 
don't have to compromise their standard of quality. 

You Wouldn't Be Saying This If You'd Ever Met 
Our Herb 

Every manager, at least some time in his or her life, has to deal with 
a worker who does seem to be avoiding work, or who seems to 
have no standard of quality, or who just can't get the job done. 
Doesn't that confirm Parkinson's Law? 

In a healthy work environment, the reasons that some people 
don't perform are lack of competence, lack of confidence, and lack 
of affiliation with others on the project and the project goals. In 
none of these cases is schedule pressure liable to help very much. 
When a worker seems unable to perform and seems not tacare at all 
about the quality of his work, for example, it is a sure sign that the 
poor fellow is overwhelmed by the difficulty of the work. He 
doesn't need more pressure. What he needs is reassignment, possibly 
to another company. 




Even on the rare occasion when leaning on someone is the 
only option, the manager is the last person to do the leaning. It 
works far better when the message comes from the team. We've 
seen cases of well-knit teams in which the manager would have had 
to get in line to yell at the one person who wasn't pulling along with 
everyone else. 

We'll have more to say in later chapters about teams and 
building a sensible chemistry for team formation. The point here is 
not what does work, but what doesn't: Treating your people as 
Parkinsonian workers doesn't work. It can only demean and demotivate 
them. 

Some Data from the University of New South Wales 

Of course, the Parkinson's Law mentality is not going to go away 
just because we say it ought to. What would help to convert managers 
would be some carefully collected data proving that Parkinson's 
Law doesn't apply to most workers. (Forget for a moment 
that Parkinson supplied no data at all to prove that the law did apply, 
he just reiterated it for a few hundred pages.) 

Two respected researchers at the University of New South 
Wales, Michael Lawrence and Ross Jeffery, run a project survey 
every year. They measure live projects in industry according to a 
common data collection standard. Each year they focus on a different 
aspect of project work. The 1985 survey provided some data 
that reflects on the inapplicability of Parkinson's Law. It isn't 
exactly the "smoking gun" that completely invalidates the law, but it 
ought to be sufficient to raise some doubts. 

Lawrence and Jeffery set out to determine the productivity 
effect of various estimating methods. They had in mind to prove (or 
disprove) the folkloric belief that developers (programmers, in this 
case) work harder if they're trying to meet their own estimates. For 
each of 103 projects studied, Lawrence and Jeffery formed a 
weighted metric of productivity, similar tothe CoCoMoproductivity 
metrics advocated by Barry Boehm. They then grouped the sample 
into subgroups, depending on how the original estimates we're 
made. A partial result is presented in Table 5.1: 


PARKINSON'S LAW REVISITED 27


Table 5.1
Productivity by Estimation Approach
(Partial Result)


EFFORT ESTIMATE AVERAGE NUMBER OF
PREPARED BY PRODUCTIVITY PROJECTS



Programmer alone 8.0 19
Supervisor alone 6.6 23
Programmer & supervisor 7.8 16


So far, the results confirm the folklore: Programmers seem to 
be a bit more productive when they can do the estimate themselves, 
compared to cases in which the manager does it without even consulting 
them. When the two do the estimating together, the results 
tend to fall in between. 

In 21 projects studied that same year, estimates were prepared 
by a third party, typically a systems analyst. These cases substantially 
outperformed the projects in which estimating was done by a 
programmer and/or a supervisor: 

Table 5.2
Productivity by Estimation Approach
(Partial Result)


EFFORT ESTIMATE AVERAGE NUIVBEROF 
PREPARED BY PRODUCTIVITY PROJECTS 


Programmer alone 8.0 19 
Supervisor alone 6.6 23 
Programmer & supervisor 7.8 16 
Systems analyst 9.5 21 




These last data points do not confirm the folkloric view at all. 
Why should the programmer work harder to meet the analyst's estimate 
than he would for even his own? It may be tempting to explain 
this away as a simple anomaly in the data. But if you believe as we 
do that bad estimates are always a demotivating factor, then this data 
doesn't need explaining away at all. The systems analyst tends to be 
a better estimator than either the programmer or the supervisor. He 
or she typically knows the work in as much detail, but is not hampered 
by the natural optimism of the person who's actually going to 
do the job or the political and budgetary biases of the boss. Moreover, 
systems analysts typically have more estimating experience; 
they are able to project the effort more accurately because they've 
done more of it in the past and have thus learned their lessons. 

Bad estimates, hopelessly tight estimates, sap the builders' 
energy. Capers Jones, known for his metric studies of development 
projects, puts it this way: "When the schedule for a project is totally 
unreasonable and unrealistic, and no amount of overtime can allow it 
to be made, the project team becomes angry and frustrated ... and 
morale drops to the bottom." It doesn't matter too terribly much 
whether the "totally unreasonable and unrealistic" schedule comes 
from the boss or from the builders themselves. People just don't 
work very effectively when they're locked into a no-win situation. 

The most surprising part of the 1985 Jeffery-Lawrence study 
appeared at the very end, when they investigated the productivity of 
24 projects for which no estimates were prepared at all. These projects 
far outperformed all the others: 

Table 5.3 

Productivity by Estimation Approach 
(Full Result) 

EFFORT ESTIMATE AVERAGE NUMBER OF 
PREPARED BY PRODUCTIVITY PROJECTS 

Programmer alone 8.0 19 
Supervisor alone 6.6 23 
Programmer & supervisor 7.8 16 
Systems analyst 9.5 21 
(No estimate) 12.0 24 


PARKINSON'S LAW REVISITED 29 

Projects on which the boss applied no schedule pressure 
whatsoever ("Just wake me up when you're done.") had the highest 
productivity of all. Of course, none of this proves that Parkinson *s 
Law doesn't apply to development workers. But doesn't it make 
you wonder? 

The decision to apply schedule pressure to a project needs to 
be made in much the same way you decide whether or not to punish 
your child: If your timing is impeccable so the justification is easily 
apparent, then it can help. If you do it all the time, it's just a sign 
that you've got troubles of your own. 

Variation on a Theme by Parkinson 

A slight variation on Parkinson's Law produces something that is 
frighteningly true in many organizations: 

Organizational busy work tends to expand to fill 

the working day. 

This effect can start when the company is founded, and become 
worse every year. It's part of the reason that very mature companies 
are less fun to work for. The few remaining employees of the Dutch 
East India Company (founded in 1651 and once the largest company 
in the world) now spend forty hours a week filling out forms. 
Notice that in this case, it's the company that exhibits Parkmsonian 
behavior rather than its employees. We'll return to this theme in 
PartlL 


Chapter 6
LAETRILE


Laetrile is a colorless liquid pressed from the soft bitter insides 
of apricot pits. In Sweden, you can buy the stuff in the grocery 
store for about the price of almond extract, and you use it in baking 
much as you would any other extract. In Mexico, you can buy it for 
fifty dollars a drop to "cure" your fatal cancer. Of course, it doesn't 
cure anything. All the evidence demonstrates that it is a cruel fraud. 
But since no one else has anything at all to offer them, terminal patients 
accept the claims of the laetrile peddlers, no matter how outrageous. 
People who are desperate enough don't look very hard at the 
evidence. 

Similarly, lots of managers are "desperate enough," and their 
desperation makes them easy victims of a kind of technical laetrile 
that purports to improve productivity. There is seldom any evidence 
at all to support the claims of what they buy. They, too, dispense 
with evidence because their need is so great. 

Lose Fat While Sleeping 

One day, in a moment of high silliness, I started clipping 
ads for products that claimed to boost productivity 
by one hundred percent or more. Within a very short 
time, I had quite a pile. The amazing thing was the 
diversity of the means advertised to yield big productivity 
gains. There were seminars, packaged programs, 
methodologies, books, scheduling boards, hardware 
monitors, computing languages, and newsletters. 

30 


LAETRILE 31


Going uptown on the subway that night, I spotted one 
final ad on the back of the New York Post. It read, 
"Lose Fat While Sleeping." It seemed to fit right in 
with the others. 

_TRL 

We're all under a lot of pressure to improve productivity. The 
problem is no longer susceptible to easy solutions, because all the 
easy solutions were thought of and applied long ago. Yet some 
organizations are doing a lot better than others. We're convinced 
that those who do better are not using any particularly advanced 
technology. Their better performance can be explained entirely by 
their more effective ways of handling people, modifying the workplace 
and corporate culture, and implementing some of the measures 
that we'll discuss in Parts II through IV. The relative inefficacy of 
technology may be a bit discouraging, at least in the short run, 
because the kinds of modification to corporate culture we advocate 
are hard to apply and slow to take effect. What would be far preferable 
is the coupon you cut out of the back pages of a magazine to 
send in with a few thousand bucks, so that some marvelous 
productivity gimmick will come back to you in the mail. Of course, 
it may not do much for you, but then easy non-solutions are often 
more attractive than hard solutions. 

The Seven Sirens 

The false hopes engendered by easy technological non-solutions are 
like those Sirens that tempted poor Odysseus. Each one reaches out 
to you with her own beguiling message, an attractive fallacy that 
leads nowhere. As long as you believe them, you're going to be 
reluctant to do the hard work necessary to build a healthy corporate 
culture. 

The particular Sirens that plague you are a function of what 
industry you work in. We've identified seven from the field that we 
know best, software development, and we present them below 
along with our own responses: 

SEVEN FALSEHOPES OFSOFTWAREMANAGEMENT 

1. There is some new trick you've missed that could send productivity 
soaring. 



Response: You are simply not dumb enough to have missed 
something so fundamental. You are continually investigating 
new approaches and trying out the ones that make the 
most sense. None of the measures you've taken or are likely 
to take can actually make productivity soar. What they 
do, though, is to keep everybody healthy: People like to 
keep their minds engaged, to learn, and to improve. The 
line that there is some magical innovation out there that 
you've missed is a pure fear tactic, employed by those with 
a vested interest in selling it. 

2. Other managers are getting gains of one hundred percent or 
two hundred percent or more! 
Response: Forget it. The typical magical tool that's touted 
to you is focused on the coding and testing part of the life 
cycle. But even if coding and testing went away entirely, 
you couldn't expect a gain of one hundred percent. There is 
still all the analysis, negotiation, specification, training, 
acceptance testing, conversion, and cutover to be done. 

3. Technology is moving so swiftly that you're being passed by. 
Response: Yes, technology is moving swiftly, but (the high-
tech illusion again) most of what you're doing is not truly 
high-tech work. While the machines have changed enormously, 
the business of software development has been 
rather static. We still spend most of our time working on 
requirements and specification, the low-tech part of our 
work. Productivity within the software industry has 
improved by three to five percent a year, only marginally 
better than the steel or automobile industry. 

4. Changing languages will give you huge gains. 
Response: Languages are important because they affect the 

way you think about a problem, but again, they can have 

impact only on the implementation part of the project. 


LAETRILE 33 

Because of their exaggerated claims, some of our newer languages 
qualify as laetrile. Sure, it may be better to do a new 
application in PowerBuilder., for example, rather than 
COBOL, but even before PowerBuilder, there were better 
ways than COBOL: niche tools that make inquiry and update 
pretty easy. Unless you've been asleep at the switch for the 
past few decades, change of a language won't do much for 
you. It might give you a five percent gain (nothing to 
sneeze at), but not more. 

5. Because of the backlog, you need to double productivity 
immediately. 
Response: The much talked about software backlog is a 
myth. We all know that projects cost a lot more at the end 
than what we expected them to cost at the beginning. So the 
cost of a system that didn't get built this year (because we 
didn't have the capacity for it) is optimistically assumed to 
be half of what it would actually cost to build, or even less. 
The typical project that's stuck in the mythical backlog is 
there because it has barely enough benefit to justify building 
it, even with the most optimistic cost assumptions. If we 
knew its real cost, we'd see that project for what it is: an 
economic loser. It shouldn't be in the backlog, it should be 
in the reject pile. 

6. You automate everything else; isn't it about time you 
automated away your software development staff? 
Response: This is another variation of the high-tech illusion: 
the belief that software developers do easily automatable 
work. Their principal work is human communication 
to organize the users' expressions of needs into formal procedure. 
That work will be necessary no matter how we 
change the life cycle. And it's not likely to be automated. 


34 PEOPLEWARE 

7. Your people will work better if you put them under a lot of 
pressure. 
Response: They won't—they'll just enjoy it less. 

So far, all this is rather negative. If leaning on people is 
counterproductive, and installing the latest technological doodad 
won't help much either, then what is the manager supposed to do? 

This Is Management 

In my early years as a developer, I was privileged to 
work on a project managed by Sharon Weinberg, now 
president of the Codd and Date Consulting Group. She 
was a walking example of much of what I now think of 
as enlightened management. One snowy day, I dragged 
myself out of a sickbed to pull together our shaky system 
for a user demo. Sharon came in and found me 
propped up at the console. She disappeared and came 
back a few minutes later with a container of soup. 
After she'd poured it into me and buoyed up my spirits, 
I asked her how she found time for such things with all 
the management work she had to do. She gave me her 
patented grin and said, Tom, this is management." 

—TDM 

Sharon knew what all good instinctive managers know: The 
manager's function is not to make people work, but to make it possible 
for people to work. 


PART II
THE OFFICE ENVIRONMENT


In order to make it possible for people to work, you have to 
come to grips with those factors that sometimes make it 
The causes of lost hours and days are numerous but not so different 
from one another. They are mostly failures, in one form or another, 
of the environment that the organization has provided to help you 
work. The phone rings off the hook, the printer service man stops 
by to chat, the copier breaks down, the chap from the blood drive 
calls to revise donation times, Personnel continues to scream for the 
updated skills survey forms, time sheets are due at 3 p.mu, lots more 
phone calls come in,... and the day is gone. Some days you never 
spend a productive minute on anything having to do with getting 
actual work done. 

It wouldn't be so bad if all these diversions affected the manager 
alone, while the rest of the staff worked on peacefully. But as 
you know, it doesn't happen that way. Everybody*s work day is 
plagued with frustration and interruption. Entire days are lost, and 
nobody can put a finger on just where they went. If you wonder 
why almost everything is behind schedule, consider this: 

There are a million ways to lose a work day, but 

not even a single way to get one back. 

In Part II, we'll look into some of the causes of lost time and 
propose measures that you can take to create a healthy, work-conducive 
environment. 


Chapter 7
THE FURNITURE POLICE


Suppose that in addition to your present duties, you were 
made responsible for space and services for your people. You 
would have to decide on the kind of workplace for each person, 
and the amount of space and expense to be allocated. How would 
you go about it? You'd probably want to study the ways in which 
people use their space, the amount of table space required, and 
the number of hours in a day spent working alone, working with 
one other person, and so forth. You'd also investigate the impact 
of noise on people's effectiveness. After all, your folks are intellect 
workers—they need to have their brains in gear to do their 
work, and noise does affect their ability to concentrate. 

For each of the observed kinds of disturbance, you'd look 
for any easy, mechanical way to protect your workers. Given a 
reasonably free hand, you would investigate the advantages of 
closed space (one- and two- and three-person offices) versus open 
space. This would allow you to make a sensible trade-off of cost 
against privacy and quiet. Finally, you would take into account 
people's social needs and provide some areas where a conversation 
could take place without disturbing others. 

It should come as no surprise to you that the people who do 
control space and services for your company (particularly if it's a 
large company) don't spend much time thinking about any of the 
concerns listed above. They don't collect any raw data, they 
don't strive to understand complex issues like productivity. Part 

37



38 PEOPLEWARE 

of the reason for this is that they are not themselves doing the 
kind of work likely to suffer from a poor environment. They 
often constitute a kind of Furniture Police, whose approach to the 
problem is nearly the opposite of what your own would be. 

The Police Mentality 

The head of the Furniture Police is that fellow who wanders 
through the new office space the day before your staff is supposed 
to move in, with thoughts like these running through his head: 

"Look at how beautifully uniform everything is! You 
have no way to tell whether you're on the fifth floor or 
the sixth! But once those people move in, it will all be 
ruined. They'll hang up pictures and individualize their 
little modules, and they'll be messy. They'll probably 
want to drink coffee over my lovely carpet and even eat 
then- lunch right here (shudder). Oh dear, oh dear, oh 
dear..." 

This is the person who promulgates rules about leaving each desk 
clean at night and prohibiting anything to be hung on the partitions 
except perhaps a company calendar. The Furniture Police at 
one company we know even listed a number for spilled coffee on 
the Emergency Numbers decal affixed to every phone. We were 
never there when anyone called the number, but you could probably 
expect white-coated maintenance men to come careening 
through the halls in an electric cart with flashing lights and a siren 
going ooogah-ooogah. 

While on break at a seminar, a fellow told me that his 
company doesn't allow anything to be left on the desk 
at night except for a five-by-seven photo of the worker's 
family. Anything else and in the morning you'll find 
stuck to your desktop a nasty note (on corporate letterhead 
yet) from the Furniture Police. One guy was so 
offended by these notes that he could barely restrain 
his anger. Knowing how he felt, his fellow workers 
played a joke on him: They bought a picture frame 
from the local five~and-dime store, choosing one with a 
photograph of an all-American family as a sample. 
Then they replaced the photo of his own family with the 
other. Under the photo was what looked like a note 


THE FURNITURE POLICE 39


from the Furniture Police, stating that since his family 
didn't pass muster by the corporate standards, he was 
being issued an "official company family photo" to 
leave on his desk. 

—TRL 

The Uniform Plastic Basement 

To get a better feeling for the police mentality, look at the floor plan 
of Figure 7.1, now becoming common in organizations all over 
America: 


Figure 7.1. Typical office floor plan. 

This scheme deals forthiightly with the complicated question of who 
should have windowed space: no one. The trouble with windows 
is that there aren't enough of them to give one to every worker. If 
some people have windows and others do not, you'll be able to tell 
that you're in George's workspace, for instance, by simple observation. 
We can't have that, now, can we? 

But look at the side effect. The most frequently traveled paths, 
from elevator to cubicle or from cubicle to cubicle, do not pass in 


40 PEOPLEWARE 

front of any window. Where such floor plans are used, the windows 
are not utilized at all, the window corridors are always empty. 
We first encountered the window corridor plan on the twentieth 
floor of a new skyscraper—there were magnificent views in every 
direction, views that virtually nobody ever saw. The people in that 
building may as well have worked in a basement. 

Basement space is really preferable from the point of view of 
the Furniture Police, because it lends itself more readily to uniform 
layouts. But people work better in natural light. They feel better in 
windowed space and that feeling translates directly into higher quality 
of work. People don't want to work in a perfectly uniform space 
either. They want to shape their space to their own convenience and 
taste. These inconvenient facts are typical of a general class of inconveniences 
that come from dealing with human workers. 

Visiting a few dozen different organizations each year, as we 
do, quickly convinces you that ignoring such inconvenient facts is 
intrinsic to many office plans. Almost without exception, the 
workspaces given to intellect workers are noisy, interruptive, unprivate, 
and sterile. Some are prettier than others, but not much more 
functional. No one can get any work done there. The very person 
who could work like a beaver in a quiet little cubbyhole with two 
large folding tables and a door that shuts is given instead an EZ-
Whammo Modular Cubicle with seventy-three plastic appurtenances. 
Nobody shows much interest in whether it helps or hurts 
effectiveness. 

All this may seem a bit harsh on those solid citizens who plan 
America's office space. If you think so, consider one last manifestation 
of the mind-set of these planners. It is something so monstrous 
that you have to wonder why it's tolerated at all: the company 
paging system. Hard as this may be to believe, some companies 
actually use a public address system to interrupt perhaps thousands 
of workers, people who are trying to think, in order to locate one: 
BONG! [static] ATTENTION, ATTENTION! PAGING PAUL PORTULACA. 
WILL PAUL PORTULACA PLEASE CALL THE PAGING CENTER. 
If you position yourself well, you can sometimes see thirty or forty 
salaried workers raise their heads at the initial bong and listen politely 
through the whole message, then look down again wondering 
what they were doing before they were interrupted. 

Police-mentality planners design workplaces the way they 
would design prisons: optimized for containment at minimal cost. 
We have unthinkingly yielded to them on the subject of workplace 
design, yet for most organizations with productivity problems, there 


THE FURNITURE 

is no more fruitful area for improvement than the workplace. As 
long as workers are crowded into noisy, sterile, disruptive space,
it's not worth improving anything but the 



Chapter 8


"YOU NEVERGETANYTHING DONE
AROUND HERE BETWEEN 9 AND 5"


Part of the folklore among development workers in all sectors 
of our economy is, "Overtime is a fact of life." This implies that the 
work can never get done in the amount of time worth allocating for 
it. That seems to us a rather dubious proposition. Overtime is certainly 
a fact of life in the software industry, for example, but that 
industry could hardly have come through a period of such phenomenal 
prosperity if the software built on the whole weren't worth a lot 
more than was paid for it. How to explain then the fact that software 
people as well as workers in other thought-intensive positions 
are putting in so many extra hours? 

A disturbing possibility is that overtime is not so much a 
means to increase the quantity of work time as to improve its average 
quality. You hear evidence that this is true in such frequently 
repeated statements as these: 

"I get my best work done in the early morning, before 

anybody else arrives." 

"In one late evening, I can do two or three days' worth 

of work." 

"The office is a zoo all day, but by about 6 p.m., things 

have quieted down and you can really accomplish 

something." 


"YOUNEVERGETANYTHINGDONEAROUNDHERE..." 43


To be productive, people may come in early or stay late or even try 
to escape entirely, by staying home for a day to get a critical piece of 
work done. One of our seminar participants reported that her new 
boss wouldn't allow her to work at home, so on the day before an 
important report was due, she took a sick day to get it done. 

Staying late or arriving early or staying home to work in peace 
is a damning indictment of the office environment. The amazing 
thing is not that it's so often impossible to work in the workplace; 
the amazing thing is that everyone knows it and nobody ever does 
anything about it. 

A Policy of Default 

A California company that I consult for is very much 
concerned about being responsive to its people. Last 
year, the company's management conducted a survey in 
which all programmers (more than a thousand) were 
asked to list the best and the worst aspects of their 
jobs. The manager who ran the survey was very excited 
about the changes the company had undertaken. He 
told me that the number two problem was poor communication 
with upper management. Having learned 
that from the survey, the company set up quality circles, 
gripe sessions, and other communication programs. 
I listened politely as he described them in 
detail. When he was done, I asked what the number one 
problem was. "The environment," he replied. 
"People were upset about the noise." I asked what 
steps the company had taken to remedy that problem. 
"Oh, we couldn't do anything about that," he said. 
"That's outside our control," 

—JDM 

All the more discouraging is that the manager wasn't even 
particularly embarrassed about failing to take steps to improve the 
environment. It was as though the programmers had complained 
that there was too much gravity, and management had decided after 
due reflection that they couldn't really do much about it; it was a 
problem whose solution was beyond human capacity. This is a 
policy of total default 

Changing the environment is not beyond human capacity. 
Granted, there is a power group in almost every company, a Furni



44 PEOPLEWARE 

ture Police group, that has domain over the physical environment. 
But it's not impossible to make them see reason or to wrest control 
away from them. For the rest of this chapter, we'll present some of 
the reasons why you're going to have to do exactly that. In subsequent 
chapters, we'll give some hints about how to go about it 

Coding War Games: Observed Productivity Factors 

Beginning in 1977, we have conducted some sort of a public productivity 
survey each year. So far, more than three hundred organizations 
worldwide have participated in these studies. From 1984 
on, we have run our annual survey as a sort of public competition in 
which teams of software implementors from different organizations 
compete to complete a series of benchmark coding and testing tasks 
in minimal time and with minimal defects. We call these competitions 
Coding War Games. Here's how they work: 

. The basic competing unit is a pair of implementors from the 
same organization. The pair members do not work together, 
but in fact members work against each other as well as against 
all the other pairs. 
. Both pair members perform exactly the same work, designing, 
coding, and testing a medium-sized program to our fixed 
specification. 
. As they go through the exercise, participants record the time 
spent on a time log. 
. After all participant testing is completed, the products are subjected 
to our standard acceptance test 
. Participants work in their own work areas during normal work 
hours using the same languages, tools, terminals, and computers 
that they use for any other project. 
. All results are kept confidential. 
From 1984 to 1986, more than 600 developers from 92 companies 
have participated in the games. The benefit to the individual 
is learning how he or she compares with the rest of the competitors. 


"YOU NEVER GET ANYTHING DONE AROUND ..." 45 

The benefit to the company is learning how well it does against other 
companies in the sample. And the benefit to us is learning a lot 
about what factors affect productivitys factors discussed in the 
of this chapter. 

Individual Differences 

One of the first results of the coding wars was proof of a huge difference 
between competing individuals. Of course, this had been 
observed before. Figure 8.1, for example, is a composite of the 
findings from three different sources on the extent of variation 
among individuals: 


Figure 8.1. Productivity variation among individuals. 

Three rales of thumb seem to apply whenever you measure variations 
in performance over a sample of individuals: 

. Count on the best people outperforming the worst by about 
10:1. 
. Count on the best performer being about 2.5 times better than 
the median performer. 
. Count on the half that are better-than-median performers outdoing 
the other half by more than 2:1. 

50 PEOPLEWARE 

The top quartile, those who did the exercise most rapidly and 
effectively, work in space that is substantially different from that of 
the bottom quartile. The-top performers' space is quieter, more private, 
better protected from interruption, and there is more of it 

What Did We Prove? 

The data presented above does not exactly prove that a better workplace 
will help people to perform better. It may only indicate that 
people who perform better tend to gravitate toward organizations 
that provide a better workplace. Does that really matter to you? In 
the long run, what difference does it make whether quiet, space, and 
privacy help your current people to do better work or help you to 
attract andkeep betterpeople? 

If we proved anything at all, it's that a policy of default on 
workplace characteristics is a mistake. If you participate in or manage 
a team of people who need to use their brains during the work 
day, then the workplace environment is your business. It isn't 
enough to observe, "You never get anything done around here 
between 9 and 5," and then turn your attention to something else. 
It's dumb that people can't get work done during normal work 
hours. It's time to do something about it 


Chapter 9
SAVING MONEY ON SPACE


If your organization is anything like those studied in our last 
three annual surveys, the environmental trend is toward less 
privacy, less dedicated space, and more noise. Of course, the 
obvious reason for this is cost. A penny saved on the workspace 
is a penny earned on the bottom line, or so the logic goes. Those 
who make such a judgment are guilty of performing a cost/benefit 
study without benefit of studying the benefit. They know the cost 
but haven't any idea what the other side of the equation may be. 
Sure, the savings of a cost-reduced workplace are attractive, but 
compared to what? The obvious answer is that the savings have to 
be compared to the risk of lost effectiveness. 

Given the current assault on workplace costs, it's surprising 
how little the potential savings are compared to the potential risk. 
The entire cost of workspace for one developer is a small percentage 
of the salary paid to the developer. How small depends on 
such factors as real-estate values, salary levels, and lease versus 
buy tactics. In general, it varies in the range from 6 to 16 percent. 
For a programmer/analyst working in company-owned space, you 
should expect to pay $15 directly to the worker for every dollar 
you spend on space and amenities. If you add the cost for 
employee benefits, the total investment in the worker could easily 
be 20 times the cost of his or her workplace. 

The 20:1 ratio implies that workplace cost reduction is risky. 
Attempts to save a small portion of the one dollar may cause you to 
sacrifice a large portion of the twenty. The prudent manager could 

51



52 PEOPLEWARE 

not consider moving people into cheaper, noisier, and more crowded 
quarters without first assessing whether worker effectiveness 
would be impaired. So, you might expect that the planners who 
have undertaken a decade-long program to change our office space 
into the voguish open-plan format must first have done some very 
careful productivity analysis. Not to do so would have demonstrated 
an irresponsible unconcern for the environment 

A Plague Upon the Land 

Irresponsible unconcern for the environment is, unfortunately, the 
norm for our times. We show it in the despoliation of our natural 
resources, so why not in workplace design? In a prophetic science 
fiction story, John Brunner describes pollution of the air, soil, and 
water continuing through the end of the twentieth century. No matter 
how bad the pollution gets, almost no one complains. Like a 
vast herd of imperturbable sheep, the inhabitants of Brunner's world 
try to ignore the problem until, finally, all possibility for survival is 
lost. Then and only then do they take notice. Brunner called his 
book The Sheep Look Up. 

American office workers have barely looked up while their 
work quarters have been degraded from sensible to silly. Not so 
long ago, they worked in two- and three-person offices with walls, 
doors, and windows. (You remember walls, doors, and windows, 
don't you?) In such space, one could work in quiet or conduct 
meetings with colleagues without disrupting neighbors. 

Then, without warning, open-plan seating was upon us like a 
plague upon the land. The advocates of the new format produced 
not one shred of evidence that effectiveness would not be impaired. 
They really couldn't. Meaningful measurement of productivity is a 
complex and elusive thing. It has to be performed differently in 
each different work sector. It takes expertise, careful study, and lots 
of data collection. 

The people who brought us open-plan seating simply weren't 
up to the task. But they talked a good game. They sidestepped the 
issue of whether productivity might go down by asserting very 
loudly that the new office arrangement would cause productivity to 
go up, and up a lot, by as much as three hundred percent. They 
published articles, many of them crafted from the purest sculpted 
smoke. They gave their pronouncements impressive titles like this 
one from Data Management magazine: "Open-Plan DP Environment 


SAVING MONEY ON SPACE 53 

Boosts Employee Productivity." After that promising title, the 
author got right to the heart of the matter: 

The fundamental areas of consideration in designing an 
open-plan office within an information processing environment 
are: the system's electrical distribution 
capabilities, computer support capabilities and manufacturer 
and dealer service. 

Period. That's it. That's all of the "fundamental areas of consideration." 
No mention of the fact that a person is going to be trying to 
work in that space. 

Also missing from that article and from others like it is any 
notion of what employee productivity is all about. There was no 
evidence in the Data Management article to support the title. The 
only method we have ever seen used to confirm claims that the open 
plan improvesproductivity isproof byrepeated assertion. 

We Interrupt This Diatribe to Bring You a Few Facts 

Before drawing the plans for its new Santa Teresa facility, IBM 
violated all industry standards by carefully studying the work habits 
of those who would occupy the space. The study was designed by 
the architect Gerald McCue with the assistance of IBM area managers. 
Researchers observed the work processes in action in current 
workspaces and in mock-ups of proposed workspaces. They 
watched programmers, engineers, quality control workers, and 
managers go about their normal activities. From their studies, they 
concluded that a minimum accommodation for the mix of people 
slated to occupy the new space would be the following: 

. 100 square feet of dedicated space per worker 
. 30 square feet of work surface per person 
. noise protection in the form of enclosed offices or six-foot 
high partitions (they ended up with about half of all professional 
personnel in enclosed one- and two-person 
offices) 



The rationale for building the new laboratory to respect these 
minimums was simple: People in the roles studied needed the space 
and quiet in order to perform optimally. Cost reduction to provide 
workspace below the minimum would result in a loss of effectiveness 
that would more than offset the cost savings. Other studies 
have looked into the same questions and come up with more or less 
the same answers. The McCue study was different only in one 
respect: IBM actually followed the recommendations and built a 
workplace where people can work. (We predict this company will 
gofar.)

How does the rest of the world match up to IBM's minimum 
standard workplace? Figure 9.1 shows a distribution of dedicated 
space per person computed across participants in our 1984 and 1985 
surveys. 


DEDICATED SPACE 

(SQUARE FEET/PERSON) 

Figure 9.1. Range of dedicated floor space. 

Only 16 percent of participants had 100 square feet or more of 
workspace. Only 11 percent of participants worked in enclosed 
offices or with greater than 6-foot high partitions. There were more 
participants in the 20-to 30-square-foot group than in the 100square-
foot group. (With less than 30 square feet, you're trying to 
work in a total floor space less than the table space provided at Santa 
Teresa.) 


SAVING MONEY ON SPACE 55 

Across the whole Coding War Games sample, 58 percent 
complained that their workplace was not acceptably quiet; 61 percent 
complained that it wasn't sufficiently private; 54 percent reported 
that they had a workplace at home that was better than the workplace 
provided by the company. 

Workplace Quality and Product Quality 

Companies that provide a small and noisy workplace are comforted 
by the belief that these factors don't really matter. They explain 
away all the complaints about noise, for instance, as workers campaigning 
for the added status of bigger, more private space. After 
all, what difference could a little noise make? It's just something to 
help keep people awake. 

In order to determine whether attitude toward noise level had 
any correlation to work, we divided our sample into two parts, those 
who found the workplace acceptably quiet and those who didn't 
Then we looked at the number of workers within each group who 
had completed the entire exercise without a single defect. 

Workers who reported before the exercise that their 

workplace was acceptably quiet were one-third more 

likely to deliver zero-defect work. 

As