Customer Reviews

The Accidental Project Manager: Surviving the Transition from Techie to Manager

5 star:		(4)
4 star:		(1)
3 star:		(1)
2 star:		(0)
1 star:		(1)

 

 

Years ago Jerry Weinberg told me that virtually all managers feel like imposters when they first begin managing. I certainly remember feeling that way in my first managerial assignment. Of course you can never reveal the feeling to those around you, that wouldn't be playing the game. While we're at it, you often can't ask your peer managers for much advice and guidance either. It's dumb, but for all the talk about "management teams," peer managers are more likely to be your competitors than your coaches. So where do you turn for sensible advice? I suggest Patricia Ensworth's thoughtful book for the first time manager. I suggest it for second and third time managers as well. She lays out the problems and has at least something sensible to propose for each one. I wish I'd had this book in hand the day I was promoted into management. It might have made the next five years a lot easier. Tom DeMarco

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.

The better title for this book would have been "The Accidental Project Manager: Project Management at a Glance".

The book briefly describes all aspects of the project management, immediately and without having to make a close study. But the drawback of the book is that it doesn't point to further reading, doesn't have bibliographic reference. After reading this book, the techies who accidentally become project manages are still at a loss. Taking literally all the recommendations given in this book, the newbie-manager may cause the first project to failure.

However, the information given in this book is easy-to-consume and is mostly truthful. The book exposes the points of convergence the techie might lack, and motivates further reading. I would recommend Steve McConnell's "Rapid Development" and Alistair Cockburn's "Agile Software Development", as well as "Peopleware" by Tom Demarco and Timothy Lister. The three books above mentioned give lots of references, and are good roadmaps of the accidental project manager.
The better title for this book would have been "The Accidental Project Manager: Project Management at a Glance".

The book briefly describes all aspects of the project management, immediately and without having to make a close study. But the drawback of the book is that it doesn't point to further reading, doesn't have bibliographic reference. After reading this book, the techies who accidentally become project manages are still at a loss. Taking literally all the recommendations given in this book, the newbie-manager may cause the first project to failure.

However, the information given in this book is easy-to-consume and is mostly truthful. The book exposes the points of convergence the techie might lack, and motivates further reading. I would recommend Steve McConnell's "Rapid Development" and Alistair Cockburn's "Agile Software Development", as well as "Peopleware" by Tom Demarco and Timothy Lister. The three books above mentioned give lots of references, and are good roadmaps of the accidental project manager.

Great book! I wish I had this when I first transitioned to Management. Although I've been in PM for over 15 years, I still found Ensworth's advice quite helpful and thought provoking. I plan to recommend this book to every new Manager, developer, and programmer that I know.

This book is very clear and easy to read and is very well pitched for the new project manager. It is specifically targeted at people who work in organisations that don't produce software as a product, i.e. people in corporate IT departments, because a lot of the book is about analysing and gathering information, in a way you just can't do if you're tendering for work. It assumes you have a large and well-funded team (e.g. 4 developers, 3 testers, a technical author, etc.), but I think a lot of the advice would be equally applicable in smaller teams (e.g. the different roles you need to fulfill). It's lightly written with plenty of humour.

This book gives a good base for IT professional that became a new project manager to work with. Even though some of the enviornments and situations in the book does not exist in new or small companies, but it paints a good picture for the new project manager of what needs to be done and the process to do it. I recommend this book highly to any new IT professionals that became a project manager.

WOW, what a fantastic book, loaded with valuable info. After reading this you can build your own 'flight checklist' for all future projects. This book provides countless tips in how to manage a development team, gotcha's to look out for and several hints on advanced CYA techniques.
A must read for all team leads and managers whether you are a newbie or been leading teams for years.