“The major problems of our work are not so much technological as sociological in nature.”

Peopleware gets straight to the point early in the first chapter by highlighting this quote as the book’s “underlying thesis.” Peopleware is about software development, but focused on the social challenges such as team building, team organization, communication, morale, motivation, and so forth. Unfortunately, projects are often managed as technical problems with a wealth of focus on spreadsheets, resource allocation charts, bug count graphs and all manner of technical artifacts. When such projects run into difficulty, a common response is to actually ramp up such technical focus by updating reports and charts multiple times a day as if increasing their frequency will somehow effect change in the data source. Data is valuable, but no matter how often one takes a patient’s temperature, the act of taking the temperature doesn’t address the underlying illness.

Peopleware is authored by Tom DeMarco and Timothy Lister and first published in 1987, then updated with a 2nd edition in 1999. The book’s anecdotal style makes it an enjoyable way to absorb the material, but the many studies and papers referenced make it clear this is a serious topic with more than anecdotal data behind its message. In many ways, Peopleware delves into the social aspects of software development that were core concepts behind the agile software process movement that started to gain traction in the early 1990s.

People obviously vary and, therefore, Peopleware’s advice will be somewhat controversial and not all points are going to apply equally to all organizations. However, the material as a whole drives home the fact that our most important concerns and highest risks stem from social factors and the most successful projects focus on those throughout.

Part 1: Managing the Human Resource

Communication: “we are mostly in the human communications business”

We communicate with customers to understand the problem, which gets communicated to the architects who create their solution, which is then communicated to the developers. We have similar communication paths for QA, technical documentation and areas outside of “R&D” (such as marketing). At each level, the quality of our interactions determines how well the product meets the user’s need and thus our success in a project depends on good communication. Unsurprisingly, failures in communication tend to lead to failed projects.

Overtime: “The realization that one has sacrificed a more important value (family, love, home, youth) for a less important value (work) is devastating.”

Overtime is often closely related with the desire for higher productivity, with overtime being a fallback strategy to accomplish more in a day. Unfortunately, overtime is typically counterproductive. Overtime only works well for manual tasks. Creative work, which describes most tasks in creating software, is largely a mental effort (see Software Creativity by Robert Glass) and studies have shown repeatedly that the ability to do complex mental work breaks down past a certain point each day.

Aside from the drawbacks of simple mental exhaustion, long hours tend to reduce people’s social graces. Communication gets harder as people become tired, edgy and impatient which creates a serious project risk given how critical communication is to a successful project. Other problems also rear their head like morale and turnover. It can make sense to push hard on a weekend to make a Monday deadline, but it’s important to realize that the productivity is simply borrowed from the future rather than a net gain.

Part 2: The Office Environment

The Workspace: “Almost without exception, the workspaces given to intellect workers are noisy, interruptive, unprivate, and sterile.”

Despite the fact that software is largely a mental effort, engineering workspaces don’t tend to encourage thought. They tend to be cramped with little desk space to spread out notes or quiet areas to think. If you find people purposefully working very late, or early, or at home, or grabbing an empty corner meeting room, that’s a sign their actual workspace isn’t conducive to the work to be done. In productivity studies, Peopleware found that the best workers have work environments “that are quieter, more private, better protected from interruption, and there is more of it.” There’s also another surprising benefit. Workers in quieter spaces not only got more done, but were statistically likely to produce fewer bugs. The cost of the worker is many fold that of the physical space, so improving the work environment is one of the highest return investments a company can make in its productivity.

Flow: “…for anyone involved in engineering, design, development, writing, or like tasks, flow is a must.”

There’s a rule of thumb that it takes around 15 minutes to get fully enmeshed in a mental task. After that point, you’re at full speed and highest productivity: a state of flow. Interruptions reset that 15-minute clock by varying degrees and an environment full of interruptions can make it impossible to ever reach a state of flow. Additionally, workers subject to constant states of no-flow report the highest levels of job dissatisfaction. While managers often live in a state of no-flow as the nature of their job, the best managers understand it’s in their own interest to protect the flow state of their team.

Part 3: The Right People

“It would be ludicrous to hire a juggler without seeing them perform.”

Amazingly enough, it’s not uncommon that interview candidates are never actually asked samples of their work, but some people can talk an awfully good game even if they can’t perform. Given people can vary in productivity by 10:1 or more (the ratio varies, but has been verified by multiple studies), the right people are worth many times their salary. So, how do you find the right people? First, it’s critical to see samples of their work such as code, project plans, test plans, etc. Second, as we saw above in “The Office Environment,” the right people need the right work environment. And third, we need to be open to more than one right answer. There is a tendency to empathize with those who think as we do, and thus we favor solutions that mimic our own; but all software positions (QA, development and management) take creative effort and there can be multiple ways to effectively solve a problem. The team with a variety of styles has the flexibility to solve a wide array of problems.

Part 4: Growing Productive Teams

The Jelled Team: “The purpose of a team is not goal attainment, but goal alignment.”

The top teams have a synergy that makes them stronger than the talents of the individuals. Though this mantra is often touted in sports, it’s a phenomenon that can happen with any team when they start to come together and perform at a higher level. The personnel haven’t changed, but suddenly the team is reaching new heights of productivity. Peopleware calls that phenomenon “jelling” and in many ways it’s the manager’s top priority.

Jelling occurs when the team is aligned on a goal. It might be a goal as simple and intangible as enjoying success together. It could be pride in creating a rock-solid system or novel user interface. Frequently, this isn’t the corporate goal, but something intrinsic and meaningful to the team members rather than something extrinsic such as the next quarterly revenue goal or an externally imposed target date. Jelled teams have a sense of identity, a sense of eliteness, and a feeling of joint ownership.

Once you get a jelled team, keep them together. It might be tempting to split these “elite” people across different projects later, but that’s breaking up the championship team.

Teamicide: “You can’t make teams jell. You can hope they will jell; you can cross your fingers; you can act to improve the odds of jelling; but you can’t make it happen.”

Jelling is akin to a chemical reaction that just takes time to occur, but it’s a fragile process that can be disrupted by various social problems. Peopleware calls out seven primary causes of “teamicide”: defensive management, bureaucracy, physical separation, time fragmentation, quality reduction, phone deadlines, and clique control. Teamicide alone could be the subject of an entire blog, but a common theme is the need to trust the people hired to do the job. This means trusting them to know when code, tests, builds, or any other technical task need to be done. People like to earn trust and reward trust given. Micromanaging whether a group can add a unit test or refactor a class shows a lack of trust in their judgement. Unrealistic or phony deadlines create a loss of faith in management’s integrity. Such teamicidal actions will kill any possibility of a jelled team.

Every team will make mistakes – it’s the nature of creating something new; but if a company has hired the right people and provides a good environment, they will succeed. If the company hired the wrong people, no amount of management intervention will help.

Part 5: It’s Supposed to be Fun to Work Here

Most people who choose software for a career enjoy the challenge. There’s surely some agony in it since challenge always comes with risk, but there’s also the excitement of working together to create something that didn’t exist before. Even in the top jelled teams though, the day-to-day activities can become a grind, particularly if you’re working on the same product over many releases. The team needs a little chaos, something to stir the pot. This observation leads to what Peopleware calls the “constructive reintroduction of small amounts of disorder,” such as pilot projects, training, trips, brainstorming, and so forth. Give teams and/or individual members the latitude to periodically stretch outside their day-to-day routine and come back reinvigorated. Google’s well known 20% “side project” rule is one example of a way to address this need.


Peopleware easily tops my recommended book list for anyone in the industry and I consider it a must read for anyone in, or aspiring to, software management. With the technical focus in software, it’s easy to forget the human element and with so many software managers coming from the technical ranks, it’s tempting to fall back on the technical skills that served so well before moving to management. Unfortunately, the skills needed in software management are dramatically different from those needed in software creation. Peopleware shows us those differences in a way that helps view the challenges of software development from a new perspective.