Arguably the most critical component of a software application are the people who build it. If the team doesn't get along, or lacks the drive to learn new things, then the team will eventually fall apart, and the project will come tumbling down shortly thereafter. Therefore while technical books are important, "people" books are important too. With that in mind, I just finished reading "Bringing Out the Best in People" by Alan Loy McGinnis. It was a good, easy read. He wrote it in the mid 80's, but as human nature hasn't changed much since then, it's still very relevant.
He offers 12 main points, including:
"Expect the best from people you lead" - I interpreted this as giving people the benefit of the doubt, and encouraging them to tackle difficult problems that bring out their best talents.
"Create an environment where failure is not fatal" - I've seen many ex-consultants who are terrified of failure. "One wrong mistake on this project, and I get replaced with a new contractor, so I better not screw anything up". Such fear paralyzes any normal person because you can't take any risk. But software is an innovative field, and innovation requires risk. Therefore having the schedule allow for some flexibility and giving people second chances are good things.
"Place a premium on collaboration" - Some management structures over-emphasize "the star". Who single-handedly wrote the most code? Who fixed the most bugs? Who built the toughest features? The problem with over-emphasizing the individual (at the expense of the team) is that it often pits the individual members against each other. Then you get team members quietly asking themselves dangerous questions like "Why should I fix your bug." Think of basketball - yes there are stars, but the coach just wants to win the game - the coach doesn't care who the star is.
There's a lot to discuss about it. In short, it's nice to balance all the technical reading with a "people" book.