Aug 112009
 

In my posting about becoming a Scrum Master, I talked about teams with non-coding project managers often being more effective than teams with project managers who also code. It seems that that’s a minority view; most companies appear to assume that any project manager should also actively code. I agree that any project manager in the software industry should have a coding background; if you haven’t been in the line of fire for a customer deliverable, or a demo for a conference, then you don’t understand the needs of the coders on the team. You also won’t understand when they’re pulling the wool over your eyes, or making excuses because they don’t feel like doing some boring but necessary task.

In a mid-sized to large company, a project manager does the boring stuff, talking to legal about copyright or licensing (for open source projects in particular), talking to sales people about when the project might become a product they can sell to their customers, making sure the various parts of the team not only talk to each other, but understand each other, and making sure the various parts of the project mesh together. A project manager makes it possible for the team to work as efficiently as possible. This might mean shielding them from a manager who wants to change requirements every day (one of the good things about Scrum, BTW, is the system for making sure that doesn’t happen), or scheduling the security reviews for the right phase of the product design and release cycles.

In a small company, the project manager is often also the product manager, doing all of the above as well as talking directly to customers, taking part in online discussions, attending conferences, and taking part in relevant standards activities.

All of these are necessary activities, and they all involve meeting with other people, whether in person or via some other communication mechanism. They aren’t tasks that require you to shut yourself away and think for hours, unlike, say, designing the server-side architecture, or hunting down a recalcitrant bug. Paul Graham recently wrote a relevant piece entitled Maker’s Schedule, Manager’s Schedule. Using this terminology, each team member is a maker. It’s the project manager who takes care of the manager’s schedule on behalf of everyone else, it’s the project manager whose schedule is interruptible. The project manager doesn’t have the luxury of looking forward to a whole day of uninterrupted work, the time to get deep in the zone, the ability to ignore the phone and email. A lead developer will get more done, and the team as a whole will get more done, if s/he doesn’t also have to worry about HR issues, or negotiating an NDA, or telling a sales person why that large feature for one customer can’t be added between now and tomorrow morning.

/* ]]> */