The difference between good and bad project managers
Throughout my career working in the web development industry, one of the most interesting aspects is the dynamic between the project manager and the development team members.
Developers can tell when they have a good project manager on board with them . They look forward to the chance of working with them. You are:
- comfortable and conversant with technology. Ideally you ought to have some technical experience behind you.
- you exercise courage and patience when interfacing with the business and technical personnel. You can handle whiny programmers, unrelenting clients, and the crushing weight of looming deadlines and you make it look easy.
- you are constantly looking for and communicating solutions to decrease the burden of the programming team. We understand that you’re not on the same level as the dev team technically. Get involved anyway. You’ll only sound stupid the first few times but you may be able to catch a glimpse of how hard the problem truly is. This also takes a bit of courage.
- you act as a buffer for the development team. Great project managers are resilient and don’t fold under pressure.
The development team can very quickly peg a bad project manager as well. Don’t let this happen to you. As soon as a project manager is seen as not being effective at their job, the word spreads through the development team(s) like wildfire.
Want to get on the development team’s bad side? All you have to do:
- is not know what your team members are doing at any given point in time.
- manage multiple teams assigned to the same project and stare at us blankly when asked where the other team is on their deliverable items.
- don’t ask questions about the technology. In fact, remove yourself from as many technical related discussions as you possibly can. This is a very good move. Especially for you.
- compare our progress with your other successful software projects and inquire innocently why it’s taking so long for our team to finish.
- be at a level technically where even spreadsheets are a black art to you.
- pretend to listen to important developer feedback and then inform the development – yet again – about the fast approaching deadline as if we were all oblivious to begin with.
And there you have it. If you have most of the qualities of a good project manager, that’s great. Know that even if your team doesn’t necessarilly shower you with praises every day, they do have that respect and will readily give you their valuable time to hear your feedback. By reading this, you realize that you’ve got some qualities of a bad project manager, get better. Fast. Start now. Engineers are a very forgiving type of people. If we realize that there is a willingness to change on your part, most of us will see that and help you along. In fact, I think that there are times when developers need to step up and make sure that project managers are meeting the expectations of the entire team as well. As a developer, what would you suggest your project manager do?
Great post. Project managers also should put as much faith in the word of their developers as they do their clients. Both parties should get equal respect until their actions determine otherwise.
Seth
8 Jan 09 at 6:13 pm
Thanks Seth. I agree with you. To take your point one step further, I think developers should strive to give accurate time estimates. This builds trust between management and developers. Whichever side of the fence you fall on it isn’t easy.
bensan
9 Jan 09 at 12:28 am
I’m happy to have worked with a really excellent project manager for the past eight months.
On the time estimate thing, a constant difficulty I’ve found is that, without having first completed a project it’s exceedingly difficult to always give accurate estimates because every project will have its surprises, be it a data feed that doesn’t clearly provide the data as advertised, or a plugin that you get 80% done implementing only to realize that a core flaw means it needs to be rewritten. What I’ve found greatly helps with this is keep a high level of communication with the project manager so they can make the judgement call on how to proceed; while it has taken me a while to grasp this and follow through with it, I’ve found it *really* relieves tension in the group.
Damien
14 Feb 09 at 5:59 pm
Improved time estimations are another reason why we should encourage Bonnier to implement SCRUM across all our web projects. It encourages the developer to constantly re-evaluate the estimate of a task that is currently in progress. If he didn’t see a roadblock in the way when the task was started (which is quite normal when creating software), he can re-estimate. It’s a beautiful thing!
bensan
14 Feb 09 at 8:40 pm