Which management book would you recommend to read for a fresh Team Leader?
closed as off topic by Mark Trapp Nov 22 '11 at 17:28
Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined in the FAQ. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about closed questions here.
|
Peopleware: Productive Projects and Teams comes to mind. The first chapter of the book claims,
The book approaches sociological or ‘political’ problems such as team ‘jelling’, quiet in the work environment, and the high cost of turnover.
|
|||||||||||||||
|
|
Managing Humans, aka the collection of managerial stuff from Rands In Repose, is worth the read, and funny to boot. A ton of truth concentrated down to its essence. |
|||
|
|
|
Rapid Development by Steve McConnell. The reason I go for this over PeopleWare is that there are a few more things in here you might actually be able to implement as a team leader. When you're a team leader (with the lack of clout that normally comes with) much of PeopleWare is largely aspirational as you're not going to be able to significantly influence working environment, salaries and recruitment and so on. I guess it depends on whether you're looking for something on development process or on management and leadership though. While I've not read it I like the look of The First 90 Days which someone has recommended. Alternatively I quite like The One Minute Manager though plenty have issues with it (largely that it's told as a story and that it's content is obvious - which I agree with but we frequently miss the obvious so reminding ourselves from time to time is no bad thing and whatever you think of it it is at least very short). |
|||||
|
|
The Mythical Man Month by Fred Brooks has a lot of great what-not-to-dos. That and Peopleware are the two that define software project management. |
|||||||||||
|
|
If you're a new Software Team Leader, I'd recommend: It is written from the perspective of "I've just been made a team leader - now what?" and has lots of practical scenarios presented in a clear manner. It also has good references within each section so it is useful as an ongoing reference book.
|
|||
|
|
|
AntiPatterns in Project Management is a wonderful list of ways to do things wrong. It's a great list of things to avoid. |
|||
|
|
|
Well, the good ones listed are already pretty popular with most programmers. How about this one: The No Asshole Rule by Bob Sutton. |
|||
|
|
|
I would actually argue for Software Estimation: Demystifying the Black Art or something along those lines. Your management style, while it can be adjusted, is largely set by this time. You can always learn to do things better, faster but your style is really who you are. Some people are opinionated jerks, others like to scream and yell while other listen and build consensus. If you have been developing for any length of time those personality traits are either pretty much set or fairly visible. You new position is going to require a lot of scheduling: your time and other people's time. To succeed you better get it right (or mostly right). Your status as a freshly minted Team Leader will be determined by your ability to deliver projects on time. |
|||
|
|
|
Your own. Train your leader by a series of discussions and mentoring sessions, and have your trainee keep a private journal of situations, responses, and successes or failures. Essentially, they will write their own book. This exercise is not so much for the book itself or reference- it is to encourage the act of reflection. Then, after the freshly-minted leader has a grasp of the issues, select some of the great books posted in other posts. My point is that you should have some experience with leadership and management before you go reading books about them, simply because you won't know enough about the subject matter to really understand, appreciate, and relate to what you've read. For example, you wouldn't advise someone to read Code Complete before they wrote their first line of code, would you? The same applies here. Get your feet wet so you have something to relate to, and then go for the books. |
|||
|
|




