Book Review: Peopleware

I don’t recall, exactly, what prompted me to pick up and read this book again in May of this year. I first read it many years ago–probably when the first edition (1987) was new. I imagine someone referenced it at this year’s NIWeek conference. It might have been Steve Watts, who has been known to suggest that software engineering is somehow related to people.

And indeed it is. This book is quite aligned with my management philosophy that software developers are people, too. Many of them darn smart, good, and interesting, worth cultivating as humans, and not just churners out of code.

Build teams to last…

I tend to favor efforts that benefit the long term view–even at the (hopefully limited) expense of the short term. The best way to build good software is to grow a team that knows how to build good software–that is, you should invest in your people.

We stopped talking about building teams, and talked instead of growing them. The agricultural image seemed right. Agriculture isn’t entirely controllable. You enrich the soil, you plant seeds, you water according to the latest theory, and you hold your breath. You just might get a crop; you might not. If it all comes up roses, you’ll feel fine, but next year you’ll be sweating it out again. That’s pretty close to how team formation works.

— Peopleware, by Tom DeMarco

Let’s obsess for a moment about the short term. “We have product to get out the door. Our customers depend on it. Our company depends on it, or we’ll go out of business.” To be clear, I in no way suggest we eschew market realities. What I don’t like is when cutting corners becomes a way of life.

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.

…

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.

— Peopleware, by Tom DeMarco

Good software developers are craftswomen and craftsmen. They want to create code they are proud to put their name on. One sure way to get them to leave your company is to prevent them from being good builders. If they are not proud of their work, they will go somewhere else where they can be.

Software doesn’t always need to last…

In some companies, the schedule tensions pervade all sorts of decision-making:

Perversely, the more marginal the benefit carried by the project, the more important it is to deliver it cheaply. It’s no surprise that cheap delivery to hide lousy benefit is not a great motivator, so executives in this position might find themselves saying, “This work is so important that we must have it done by January first.” What they really mean is, “This work is so unimportant that we don’t want to fund it beyond January first.”

— Peopleware, by Tom DeMarco

I’ve certainly faced this scenario:

Stakeholder: “If you can’t do this in the next month, it’s not worth doing.”

Me: “My team says it will take us two months, so we won’t do it.”

Stakeholder: “Wait! But I want it!”

Me: “?”

At this point, you have to dig deeper. Is it worth it to provide a smaller-scoped product that meets the deadline? Is there long-term value that makes a two-month investment worth it? Hopefully, your stakeholder will engage in a reasonable negotiation.

There’s a danger, of course, that you’ll get replaced with someone who will make promises their team can’t uphold. The choice is yours. As for me, I stand with my team.

We also need to avoid the opposite problem. I’ve been on projects that take way too much time and energy.

I worked at one company that was spending years to build a new software platform–thirty interdependent scrum teams crafting a bold new vision. Great ideas, but nothing was in production and everybody was frustrated. They’d have been better off to set aside one or two teams with the goal of getting something into production quickly, and then iterating and iterating to move forward.

As my friend Fabiola once tweeted:

Teach your teams about your business…

The way you make all of this successful is by instilling the right values and the knowledge in your team members. Give them the right skills, sure, but also teach them how to make good business decisions. Keep them informed about what customers need and what the business needs, and then give them authority to decide what to do.

When I worked at athenahealth, we used to go on “site visits” to talk to the people doing the work. It wasn’t a sales call; it was to talk to the person who used our specific feature every day. We always learned a lot–often about our missed assumptions.

As I’ve often said, the vast majority of software feature decisions are made by the developers writing the code. These are the moment-by-moment decisions–“I could write it this way, or that way.” Should I write this code for simplicity, or future flexibility? For utmost performance? For all of the above? These are not the big questions answered by product managers or people managers. But they can have a large impact on maintainability and cost of future change. So, the better the developer understands the customers and their needs, the more likely they are going to make wise decisions at the point where it’s cheapest to make them.

Trust…

As I like to do, let’s bring this back around to culture.

Important in all of this is trust. I once knew a software leader who seemed not to trust the vast majority of his organization. Lots of micromanaging. Productivity suffered because teams weren’t allowed to solve their own problems. This led to lots of blame. (And to layoffs and the eventual ouster of this software leader.)

[Many] managers err on the side of mistrust. They follow the basic premise that their people may operate completely autonomously, as long as they operate correctly. This amounts to no autonomy at all. The only freedom that has any meaning is the freedom to proceed differently from the way your manager would have proceeded. This is true in a broader sense, too: The right to be right (in your manager’s eyes or in your government’s eyes) is irrelevant; it’s only the right to be wrong that makes you free.

— Peopleware, by Tom DeMarco

Parting words:

If you’ve got decent people under you, there is probably nothing you can do to improve their chances of success more dramatically than to get yourself out of their hair occasionally.

— Peopleware, by Tom DeMarco

My Goodreads review is below:

My rating: 5 of 5 stars

This book is very much in line with my people over process (and people over product) management philosophy. For managers (like me) who are high in empathy, you’ll find yourself highlighting passages and nodding in agreement all the way through the book. Not sure how it plays to managers for whom empathy isn’t high on the priority list.

Originally published in 1987, 3rd edition in 2013, it’s a bit dated—ringing telephones and paging systems aren’t the interruptions of today. But this doesn’t detract from the overall message. I’ve worked in billion-dollar companies and a small startup, and this book seemed relevant to both experiences.