|
10 of 11 people found the following review helpful:
1.0 out of 5 stars
Lacking a great deal., 19 Sep 2003
The book aims at helping techies which becomes a manager for the first time---helping them though their first project as a manager. However, the book has a very narrow perception of what constitutes being a manager.The focus includes defining the end-users, testing/Q&A, scope of the project, figuring out available and needed (non-people) resources, It provides you with a lot of forms to fill out; forms which have been made for the book, not real world examples. However, it lacks almost everything when it comes to dealing with other people---which is most of what a manager do. The only stuff it has is the "have pizza in the conference room" and "get rid of the lonely cowboy". So I'm left with a lot of unanswered questions: How do I deal with the politics of management. How do I deal with my new manager (a step up in the hierarchy), which surely must be different from when I was a techie myself and had a half-techie manager. Which political games could I expect to be part of. How should I deal with them? How could I avoid dealing with them? In which areas can I expect to be allowed to behave differently? And it lacks: How do I deal with my techies? How do I deal with the bright star which can turn out 5-10 times as much/better code as the other coders, but is a bit special? How do I deal with the "steady Eddie" programmer (the vast majority) which follows directions but lacks creativity, intuition. How do I deal with the clueless wannabe which takes more time than he gives back (what if management doesn't let me fire him? What if management won't accept the notion that he is less than non-productive?) How do I get all those people, which are very different, to work together? How do I setup working conditions so each of those fit into their niche? How do I get them to understand (or at least accept) that they have to work with people which are very unlike themself (or unlikable)? How do I evaluate how much they are actually working, besides at blocking websites, reading all cvs commit emails, basically reading "over the shoulder" all the time? How do I inspire them those who can be inspired, and how do I threat those who need to be so? How do I figure out if somebody is working too much, and be sent home so he doesn't burn out? If all what you have are bright and self-manageable people, you are much better of reading "Peopleware" by Tom Demarco. For the less-than-bright coders, I still don't have any clue. By ignoring the people-aspect, the book becomes a "how do I do a project without a manager and without anybody to help me" dummies book for a coder which have serious trouble working on his own, and can only do it by filling out forms.
|