I recently read Peopleware 3rd Edition by Tom DeMarco and Timothy R. Lister. In this book the authors share their experiences from their consulting work at various software companies.
The book is divided in six parts ranging from setting up proper workspaces, how to grow successful teams, and the underestimated value of Human Capital. Let’s dive in for a summary.
Managing Humans
The first part of the book focuses on managing people and describes common mistakes (new) managers make and how they can approach things differently.
Some managers approach managing a software team as production work. They micro-manage, they try to minimise mistakes, and want 100% doing from their team members. But software development is not production work and has to be managed almost the opposite. Production work is done in a controlled environment where all the variables are known, so you can optimise them. Development work is not like that; it’s an exploration of unknowns and uncertainty, which you should approach iteratively. Instead of minimising mistakes at all costs, one should encourage people to make mistakes and to learn from them. And besides coding, developers also need time to brainstorm, explore new methods, reading, training and just goofing off.
The book describes, what they call, the Spanish Theory Management. A management style where you to get people to do unpaid overtime and try to squeeze every bit of productivity out of them. This will cost people their personal live and eventually lead to burn-out or makes them quit.
“People under pressure don’t work better-they just work faster.”
Many organisations put their teams under pressure to deliver new features faster and faster. They lose their sight on quality, with all its consequences:
- People lose their self-esteem, as this is often linked to the quality of the product or features-not quantity.
- A culture of high quality results in high job satisfaction.
- A policy of “Quality-If Time Permits” will assure that no quality at all sneaks into the project.
The book also describes Parkinson’s Law: the only way to get work done at all is to set an impossibly optimistic delivery date (deadline). Many managers suffer from this law. The only way where this is going is frustrated developers and decreased productivity.
The manager's function is not to make people work, but to make it possible for people to work
Work environment
Part 2 is about the work environment. Some key takeaways that I found interesting.
- Offices are often designed to be noisy and disruptive. The opposite of what you want for knowledge workers.
- Software developers prefer to stay in the flow. Interruptions from a noisy office, phone calls, or direct messages prevent developers to reach and stay this state, having a negative impact on productivity.
- The team should be involved when planning the workspace. There should be windows and preferably have indoor -and- outdoor space to wonder. There should be different types of rooms, some public, some private.
- Some managers might argue: “Walls and doors prevent interaction between people.”. Just no.
Hiring The Right People
Part 3 is about hiring new people for the team. Some takeaways I noted:
- Hire people for their skills, not for their appearance
- Companies should be more inclined to let leadership arise naturally
- Team jell takes time, during which the team shouldn't change too much.
- Turn-over is extremely costly. Finding new candidates, recruitment fees, the time it takes to onboard them. And that’s only the visible cost. Then there is the negative mental impact on other workers, when turn-over is high. People will be short-sighted and lose loyalty to the organisation.
Jelled Team
Part 4 introduces the concept of a Jelled Team. A group of people so strongly knit that the whole is greater than them sum of the parts. This is what we nowadays call a high-performing team. Some indicators of a Jelled Team are:
- Low turn-over
- Strong sense of identity, with cool nicknames
- Sense of eliteness. Team members feel they’re part of something unique.
- A joint ownership of the product they built
- Great enjoyment in their work
A Jelled Team isn’t build-it’s grown. A delicate process, where you enrich the soil, plant the seeds, you water accordingly, and wait. If you’re lucky it comes up roses and you’ll be fine, but next year you’ll be sweating it out again.
Jelled Teams are also easily killed by:
- Defensive management
- Bureaucracy
- Bad work environment
- Quality reduction of the product
- Phony deadlines
- Fear of management for Jelled Teams
- Overtime
Chemistry for team formation:
- Cult of quality: Demand high quality
- Closure: During the project, so everyone know they are going in the right direction.
- Eliteness: make the team feel elite/unique
- A manager can't be part of the team.
Culture
Part five is about organisational culture, referred to as Fertile Soil. One of the chapters dives into common problems with meetings, which resonated very well with me. It touches on the following issues with meetings:
- People have their laptop or phone open. They are effectively escaping the meeting.
- Too many meetings. Meetings are for talkers; for those who want to climb the corporate ladder.
- Working meetings vs ceremonies. The latter ends by the clock. The first when a decision has been reached.
- Too many people in meetings
- Conferences: sessions and talks can be a chore, but the most value is in the interstices, the common areas before/after each talk, the coffee breaks, the lunch lines, etc.
Prescription for Curing meeting-addicted orgs:
- Limit number of people at meetings
- Apply the “what ends this meeting?" test for each meeting.
- Instead of ceremonies, move to one-on-one conversation. Or encourage open-space networking to give people a change to have unstructured interaction.
In chapter 35 it touches on Organisational Learning, which gave me the following insight:
Learning is limited by an organisation’s ability to keep its people
Retaining Talent
The final part, called “It’s Supposed to Be Fun to Work Here”, is short and is essentially about retaining in-house talent. Some takeaways for me are:
- A project tournament (or hackathon) will help in bonding: Participants will look back on a fun time; It will be rememberable.
- If you have a self-motivated super achiever in your organisation. Have the person define his/her own job. The book calls these workers “Free electrons”, since they have a strong role in choosing their own orbits.
- If things are wrong in your org, people know. Sometimes they just need a little catalyst: Holgar Dansk, the sleeping giant, to make impactful change happen.
Conclusion
I found reading Peopleware to be very insightful. Even though the first edition was published in 1987, I still find it very relevant in today's world of software companies. For example, the book discusses interruptions originating from phone calls, which are killing for productivity. This can easily be translated to newer mediums like real-time chat apps.
I would recommend this book to software engineers transitioning to engineering manager.
