Peopleware is written as a series of essays on the various ways that software companies and projects go right and wrong. Each chapter has some prescriptive advice that could be used in order to begin a sensible reconstruction of a project, a division, or a whole organization. This review (Part I) will focus more on the first part of the book – management of the human resource.
Compared to typical leadership positions, managing software products require a lot of extra skills. The technicality is different: using literally no prime materials, great systems must be created in order to support the entire process of a business. Technology is always evolving and the workers (in this case developers and testers) have no other option than to keep up with it. It is usually hard to estimate the time necessary to complete a product release (because it is always something new about it that was never done before) and each new task or project has its own challenges.
Depending on the type of leadership position you hold, your responsibilities will include more or less of the following: understanding the business of the client and the need of the market, adjusting the client’s expectation, understanding the technical issues your team encounters and create a good working atmosphere, manage and analyse the risks involved, stay up to date with the latest trends in technology and always keep an eye on the big picture.
But the most important resource in software development is (still) the human resource. Helping people grow and achieve their goals, evaluate them and provide the best possible feedback, manage conflicts inside the team, providing each teammate with the appropriate space and tools needed to complete the job and create a great community in the process may be the most challenging part of the software management.
But consider for a moment 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 information and our work into modular pieces and clearly exposing our ideas and results. Then, 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 always work this way, and we see that as soon as we are hit by the very non-modular character of the human resource: disciplined self-organized engineers will still encounter a challenge in organizing a group of people.
For several decades, Tom DeMarco & Timothy Lister conducted annual surveys of more than 500 real-world development projects and their final results. They observed that about 15 percent of all projects studied came to naught: They were canceled, aborted, “postponed” or they delivered products that were never used. For bigger projects, the odds are even worse. Fully 25 percent of projects that lasted 25 work-years or more failed to complete.
The cause of failure most frequently cited by our survey participants was “politics.” 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.
I. Managing the human resource
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, and part of this phenomenon is due to the upbringing of the average manager which was schooled in how the job is done, not how the job is managed.
The major problems of our work are not so much technological as sociological in nature
1. What business are we in?
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 they are falling in the “high-tech” trap thinking that more automation will solve all their issues. However, most of the time, the managers of software products are not in the high-tech business (which is reserved to the few who really create the devices, systems and tools that the others apply). Since they go about this work in teams and projects and other tightly knit working groups, they are mostly in the human communication business. In this case, the successes stem from good human interactions by all participants in the effort, and the failures stem from poor human interactions.
The following short story from the book best exemplifies this concept:
In my early years as a developer, I was privileged to work with Sharon, 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.”
Tom DeMarco & Timothy Lister – Peopleware
2. Key principles in managing software
Taking into account the main differences between management in general and the strenuous job of software management, we can identify the following key principles:
Key Principle 1: How to handle errors as a leader
Fostering an atmosphere that doesn’t allow for error simply makes people defensive. They don’t try things that may turn out badly. This defensiveness is encouraged when the process is systematized, when rigid methodologies are imposed so that staff members are not allowed to make any of the key strategic decisions lest they make them incorrectly – and this is a sure way of killing creativity.

The solution to this 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.
Key Principle 2: Manage productivity expectations
Pushing software engineers to always exceed past productivity may become counterproductive. This attitude might always 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. You seldom need to take Draconian measures to keep your people working; most of them love their work. But this does not mean you shouldn’t keep an eye on the progress that is being made – the project manager should always be up to date with the status of the project.
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.
Tom DeMarco & Timothy Lister – Peopleware
Key Principle 3: Good leaders identify uniqueness

Each person has unique abilities that can help in achieving the goal of the team. One may be introverted but more creative, another one can be very focused and detail-oriented and you, as a manager, probably have the very skills that can help you recognize these traits. Use them intelligently, in order to grow you colleagues as a team and also as individuals.
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.
Key principle 4: Understand the dynamics of development
We tend to forget that we work on our projects in order to someday, finish them. The projects come and go, but the people who helped building them may still be available, and we managers still have to provide what is best for their growth. So 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 fits into the effort as a whole.
For example, there could be one person in your team that seems not to be a great developer or tester, and yet, all the projects he worked on were a tremendous success. Teams naturally jell better when he is there, he helps people communicate with each other and get along. Projects are a lot more fun when he is part of them. This type of person is considered a catalyst – a very important resource since 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.
Key principle 5: The importance of planning
If you are charged with getting a task done, what proportion of your time ought to be dedicated to actually doing the task? Not 100 percent. There ought to be some provision for brainstorming, investigating new methods, figuring out how to avoid doing some of the sub-tasks, reading, training, and just goofing off. The time we spend in doing estimations and breakdown is a great investment in the success of the release.
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 team night out or some such affair to help the individual participants knit into an effective whole. We are so single mindedly oriented toward doing something, so that we spend a scant 5 percent of our time on the combined activities of planning, investigating new methods, training, reading books, estimating, budgeting, scheduling, and allocating personnel.
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.
Tom DeMarco & Timothy Lister – Peopleware
3. How management theory affects the life of the employee
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?
—Billy Joel, “The Stranger”
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.
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, you don’t make time for your children, your spouse is starting to look elsewhere.”
There are managers who take a pride in having employees who want to work overtime and not get payed for extra work. Do not be one of them. A day has a limited number of hours, and, unfortunately (at least for now), we all have a limited amount of days in this world. The days when we are healthy and able to do and experience a lot of things we want are even more limited. Your people are very well aware of the one short life that each person is allotted and sooner or later they will come to the conclusion that there has got to be something more important than the job they’re working on.

Think of ways to make your team more productive during the work hours and limit the amount of required overtime as much as possible.
Overtime and workaholics
Overtime for salaried workers is a figment of the naïve manager’s imagination. There might be some benefit in a few extra hours worked on Friday evening 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. The best practice would be to have more or less an hour of undertime for every hour of overtime. The trade-off might work to the manager’s advantage for the short term, but for the long term it will cancel out.
Nobody can really work much more than forty hours a week, at least not continually and with the level of intensity required for creative intellectual work. Think of overtime as 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.
Tom DeMarco & Timothy Lister – Peopleware

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 “Vienna waits for you” message above comes through to even the most dedicated workaholic.
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 may not go to the boss and explain calmly and thoughtfully that things have to change in the future – he can just quit.
Workaholism is an illness, but not an one like alcoholism that affects only the unlucky few. It is more like the common cold: everyone has a bout of it now and then. No matter how desperately you need them to put in all those hours, you can’t let them do so at the expense of their personal lives because the loss of a good person isn’t worth it.
How can you help solve all this issues? The answer is:
The investment in meaningful productivity
Historians long ago formed an abstraction about different theories of value: Spanish Theory of Management, 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 of Management which held that value could be created through ingenuity and technology. So the English had an Industrial Revolution, while the Spaniards 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.
Tom DeMarco & Timothy Lister – Peopleware
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.
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.
- Standardize procedures.
Any of the above measures can potentially make the work less enjoyable and less interesting. Hence, the process of improving productivity risks motivating employees to look for more satisfying work elsewhere.
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 and so it is hard to tell what is the cost of replacing an experienced worker.
The Eagle project at Data General was 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 performed, and cost is the total cost, including replacement of any workers used up by the effort.
Tom DeMarco & Timothy Lister – Peopleware
Chances are, you’ve known one or more Spanish Theory managers during your career, but 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. When we do this we 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 of their own work experience.
4. Estimations and Quality
The software business is distinctly renowned for the difficulty of keeping up with the initial estimations while also providing great quality products. In other verticals like construction work or manufacturing of any kind, things are a bit simpler: pretty much all managers and clients know what needs to be done and what is the cost for that. It has been done before, the materials are the same, you still have to factor in the human resource and analyse possible risks, but the job seems straightforward. We are usually creating stuff that needs to be revolutionary and we do not know exactly when we can deliver and if the final product will really catch with the public. Keeping up with both estimations and quality standards may appear really hard.
The Project Management Triangle

Perhaps you are already familiar with the (incomplete) theory of the Project Management Triangle – that you have to choose between high quality work and time, if you want to keep the cost fixed. But is that really true?
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.
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.
Tom DeMarco & Timothy Lister – Peopleware
Manager vs Developer Perspective on Quality
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. But they also have to take into account that 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 and not the quantity. Even if managers understand that turning out huge amounts of mediocre stuff may be just what’s required for a given situation, for some reason, the developers find very little satisfaction in this way of working.
The developers’ 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 working on other projects. This is invariably a higher standard than what the market requires or what the client is willing to pay for.

Have you ever thought about ways of how you can meet the client’s expectations with a level of quality also accepted by the team without loosing morale? How would you approach it?
The manager understands the client’s perspective: 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, so the app owner may see this as a good trade-off. But allowing the standard of quality to be set by the buyer, rather than the builder, is what can be called 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. But in the long run, market-based quality costs more, and we can see that looking at the Japanese system.
Quality, far beyond that required by the end user, is a means to higher productivity.
Tom DeMarco & Timothy Lister – Peopleware
The Japanese System of productivity

Ask a 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.” So the nation that is an acknowledged quality leader can also be known for its high productivity.
But how is it possible? Isn’t this contradicting the Triangle Theory presented previously? Could higher quality really coexist with higher productivity?
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
Denji Tajima and Tomoo Matsubara – two of the most respected commentators on the Japanese phenomenon
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.
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.

Reflect on the following idea: how would the productivity be affected if you would grant your team veto power for delivery?
Estimations
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.
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;
- 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 to care 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, he needs reassignment.
Giving estimations is pretty hard in the software industry, but many times, for different reasons, it is also a must do. Estimations help the managers and clients to know what to expect. Having the work divided in tasks that are estimated helps painting the bigger picture for all the parties involved, and thus it will be easier to track the progress or shift course.
Developers and testers also grow by doing estimations: they become more responsible, more aware of their impact, and with experience – better developers and mentors to other people. But how do we reconcile the deadlines created by the estimations with the mental pression of having to achieve them, knowing that in the software business some important details can easily be overlooked?
We have already covered the importance of planning and taking the proper amount of time to understand what needs to be done, what are the priorities and analyse the risks. But going beyond that, when are the individuals most motivated to complete a task, given the estimations?
Two respected researchers at the University of New South Wales, Michael Lawrence and Ross Jeffery, ran annual surveys through the eighties and nineties. They measured live projects in industry according to a common data collection standard. Each year they focused on a different aspect of project work. The 1985 survey provided some data that reflects on the inapplicability of Parkinson’s Law, and the results about estimations can be found below:

Most of the data from the table above is pretty much common sense: a programmer is more productive if he has to meet his own estimations rather than the ones imposed by his supervisor. The system analyst is the one who knows best the specs and is an expert in giving estimations (not so optimist as a developer, not so cheap as a manager). What may come as a surprise to some, is that the productivity of the developer is highest when he does not have any time pressure and usually that comes with an increase in quality too.
So maybe the best approach is to still have the estimations to help with the progress tracking, but do not impose hard deadlines. In the case estimations were exceeded, try to find out why in order to avoid the same mistake in the future, and be as transparent as possible about this with everyone involved (the task priorities and overall direction of the project may change because of this).
In our modern times we discover more of a variation of Parkinson’s Law that is frighteningly true in many organizations: Organizational busy work tends to expand to fill the working day.
Tom DeMarco & Timothy Lister – Peopleware
This effect can start when the company is founded, and become worse every year. If the Dutch East India Company (founded in 1651 and once the largest company in the world) were still around, its employees might well be spending forty hours a week filling in forms. Notice that in this case, it’s the company that exhibits Parkinsonian behavior rather than its employee
Ok