August 29, 2017 | 7 min Read
One of the best books I’ve ever read is Peopleware, by Tom DeMarco and Timothy Lister. It’s a well known book in the software development industry, and even if it focusues more on managers than “creative” roles (designers, developers, etc), I think that anyone working in this field should read it.
According to Wikipedia, peopleware can refer to anything that has to do with the role of people in the development or use of computer software and hardware systems. This includes topics as developer productivity, teamwork, group dynamics, project management, organizational factors, human interface design, and human-machine-interaction.
The book was published in 1987 but it’s still a must read today for a very simple reason. I’m quoting a passage from the book to highlight it:
The major problems of our work are not so much technological as sociological in nature.
The entire book aims to replace the manager-as-strategist view with the folling simple – yet surprisingly hard to achieve – formula:
People don’t change that much, so if they are not right for a job from the start, they will likely never be. DeMarco and Lister stress this fact because when it comes to hiring, rules of common sense are often suspended. They illustrate this by depicting a scenario where a hiring manager needs to hire a juggler:
Candidate: Umm… don’t you want to see me juggle?
Manager: Gee, I never thought of that.
The book suggests a few hiring strategies, like asking potential candidates a portfolio. However, I would say that it focuses more on how to keep people rather than find them.
Retaining employees should be a matter of utmost importance not only because finding new people requires time and resources, but because the organization itself learns from its people.
For a company, a great way to achieve a low turnover* (i.e. keeping people) is to invest heavily in personal growth and to provide a great sense of direction to its employees. This results in a good job satisfaction and a strong binding effect.
In the short run it might be cheaper to fire the person who needs retraining and hire someone else who already has the required skills. Most organizations do just that. The best organizations do not. They realize that retraining helps to build the mentality of permanence that results in low turnover and a strong sense of community. People tend to stay at such companies because there is a widespread sense that you are expected to stay.
Learning is limited by an organization’s ability to keep its people. When turnover is high, learning is unlikely to stick or can’t take place at all.
*A low turnover rate is not necessarily a good thing though. See this article for a different, interesting perspective.
Many, many books today talk about effective teams, often citing examples from the military. They say that best teams are rather small in size (e.g. 6 - 13 people), they don’t really need a boss and are essentially self-driven. I think that Peopleware nailed it down 30 years ago:
the structure of a team is a network, not a hierarchy
On the best teams, different individuals provide occasional leadership, taking charge in areas where they have particular strengths. No one is the permanent leader, because that person would then cease to be a peer and the team interaction would begin to break down.
Today the typical team of knowledge-workers has a mix of skills, and most of the time there isn’t a single coach that mastered all of the technologies the team has to work with. Team members themselves provide most of the coaching to other team members. The authors use the expression “a basic hygienic act of peer-coaching”. In great teams this is going on all the time: team members sit down in pairs to transfer knowledge. There is always one learner and one teacher, and their roles tend to switch back and forth over time.
The authors found out that office spaces of top performer teams are quieter, more private, better protected from interruption. This seems to me a great point against open office spaces that are so popular today. However, DeMarco and Lister also admit that a meaningful measurement of productivity is a complex and elusive thing. A soft science they say, and it has to be performed differently in each different work sector.
They also describe the ideal conditions that allow a team to reach flow, a concept introduced by the Hungarian psychologist Mihaly Csikszentmihalyi. In this state of mind a person achieves a deep, nearly meditative involvement, he experiences a gentle sense of euphoria and is largely unaware of the passage of time.
For anyone involved in engineering, design, development, or writing, flow is a must, and only when he enters flow state his productivity is maximized.
If you have been in this state before, you know what I am talking about. If not, have a look at this piano performance by Peter Bence. Can you see how completely immersed in the music he is? He looks like he is in ecstasy.
Peopleware is definitely against micromanagement and “carrot and stick” approaches.
Most of creative people (e.g. designers, engineers) love their work, so a manager doesn’t really have to adopt strict measures to keep these people working. In fact, he may even have to take steps to make them work less, and thus get more meaningful work done.
Leaving people “loose” doesn’t mean restraining from measuring their performance. Even if you are not sure, you should start nonetheless, because according to the Gilb’s Law anything you need to quantify can be measured in some way that is superior to not measuring it at all.
The authors advocate the rise of an “invisible manager”, someone who stands somewhere behind the scenes, observing that things are alright, and acts on things which aren’t. Such manager can manage a team without the team members knowing they’ve been “managed”.
The manager’s function is not to make people work, but to make it possible for people to work.
For a manager is essential to read and internalize the seven false hopes of software management. I particularly like the number 5: Because of the backlog, you need to double productivity immediately. I struggle with this rule every time I want to start a small personal project. I have a Trello board with more than 100 items in my “Backlog” list. I know I would have fun in doing them, but I also know that I don’t have the time for doing even half of them. And when something ends up in a Backlog, it’s hard to prioritize it and/or think of it as a potential loss of my leisure time.
A manager might jeopardize product quality by setting unreachable deadlines. He might think of it as a challenge for his workers to strive for excellence, while experienced workers might realize that they will need to sacrifice the quality of the product and their own job satisfaction. In fact, employees are often as eager as managers to get the job done, provided that they don’t have to compromise their standard of quality.
People under time pressure don’t work better, they just work faster.
The authors are pretty critical of methodologies. They say that methodologies aim to achieve a convergence of methods, which by itself would be a good thing. There are better ways to achieve convergence of methods though:
Every other day we read articles against unnecessary meetings. Take for example this recent piece about Jeff Bezos’s two pizza rule for meetings. I think most of these articles do not add much value to what the authors of Peopleware wrote 30 years ago: regular meetings are most likely unnecessary.
There should be a meeting only when it’s actually needed. There must be a real reason for all the people invited to think through some matter together. The purpose of the meeting is to reach consensus. Such a meeting is, almost by definition, an ad hoc affair.
Any regular get-together is […] somewhat suspect as likely to have a ceremonial purpose rather than a focused goal of consensus.
When people’s time is wasted in unnecessary meetings or by early overstaffing, they’ll know it. They’ll be frustrated and they’ll know why.
I really like the fact that the DeMarco and Lister say that managers should really worry about workaholism. I think it’s very wise. A workaholic employee is a problem not only for himself, his family and collegues, but for his manager too. Sooner or later he will realize that he has got his value system wrong, and the consequences of this realization will be devastating for him.
I think this quote on burnout is a masterpiece:
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.
Give up your tech news for a couple of days and read this book instead! It’s well written and gets to the point much better than most of the blog posts that you can find out there. It does not delve deep into group dynamics, project management or technical topics, but it can teach you timeless lessons for your career and life in general.