I work for a large company. Thus, there are "leadership seminars" with "team-building exercises." I attended one of those. I was confessing this to some friends on Saturday, and one of them knew exactly what I meant; he asked, "Were there ropes to climb, among trees?" Yes, yes there were. The ropes didn't teach me much about leadership or people skills or teams. Why not? Because belayed rope-climbing is too similar to belayed rock-climbing. The beginner's lesson of rock climbing which is pertinent to leadership/people/teams is: Once you learn that you can trust your belayer, you make rapid progress by putting your energy into climbing instead of clinging. Thanks to Chuck Groom, I'd already learned that. So the ropes were fun but... Well, I didn't learn much there. For more insights on people, I guess I'll keep talking to them. And reading. E.g., I got around to reading Peopleware.
This book is a classic, by which I mean you've already heard most of what it has to say about managing software development. You've heard it second-hand. Reading the book itself is a little strange. Parts of it make little sense unless you drag up history, let your brain nestle into an old mindset.
Why does the book rail against Productivity? Why does it equate productivity with burnout and overtime? Doesn't improving producitivity mean setting up better tools and processes so that people can work more efficiently? Well... back in the day, "Productivity" meant that folks should work longer hours. Japanese car companies were out-producing American car companies. American executives went to visit Japanese executives and noticed that Japanese office workers stayed in the office long hours. (They didn't notice that Japanese assembly line workers were better trained, were encouraged to improve processes, and... Ahem, anyhow.) They came back and said that we should all work harder. Never mind that those Japanese sararimen weren't getting much done. Thus, Peopleware pointed out that short-term benefits from working long hours were offset by folks burning out--something that seems pretty obvious in hindsight, but perhaps seemed less obvious at the time.
They pointed out that projects that operate without time estimates are the most productive.
They pointed out that programmers need to focus and can do so best in offices with doors that close. They spoke out against distractions. In hindsight, I think they overstated the value of closed offices--over-emphasizing bursts of focused work vs. encouraging folks to talk to each other and exchange ideas--at the time, cubicle-bound programmers were subject to plenty of distractions that weren't useful conversations with coworkers.
They talked about how to prevent folks from having their conversation broken by the telephone. People still used voice communication back then. It was sort of like text-messaging, only... Oh, never mind. You kids today will never understand how rough we had it back then.
They talk about Christopher Alexander, the Design Pattern guy. Back when Design Patterns were architecture architecture instead of software architecture. I wonder if this book is what introduced so many software weenies to design patterns.
They talk about Teams, about complementary skills, about people learning to work with each other. Back in the day, did managers feel like workers were interchangeable? I don't know. There's a bulleted list for team formation.
- Make a cult of quality.
- Provide lots of satisfying closure.
- Build a sense of eliteness.
- Allow and encourage heterogeneity.
- Preserve and protect successful teams.
- Provide strategic but not tactical direction.
These seem like things that most of my managers have tried to do. Like I said, you've probably seen most of what this book has to say, you've picked it up second-hand.