Day: August 11, 2009

In my post­ing about becom­ing a Scrum Mas­ter, I talked about teams with non-cod­ing pro­ject man­agers often being more effect­ive than teams with pro­ject man­agers who also code. It seems that that’s a minor­ity view; most com­pan­ies appear to assume that any pro­ject man­ager should also act­ively code. I agree that any pro­ject man­ager in the soft­ware industry should have a cod­ing back­ground; if you haven’t been in the line of fire for a cus­tom­er deliv­er­able, or a demo for a con­fer­ence, then you don’t under­stand the needs of the coders on the team. You also won’t under­stand when they’re pulling the wool over your eyes, or mak­ing excuses because they don’t feel like doing some bor­ing but neces­sary task.

In a mid-sized to large com­pany, a pro­ject man­ager does the bor­ing stuff, talk­ing to leg­al about copy­right or licens­ing (for open source pro­jects in par­tic­u­lar), talk­ing to sales people about when the pro­ject might become a product they can sell to their cus­tom­ers, mak­ing sure the vari­ous parts of the team not only talk to each oth­er, but under­stand each oth­er, and mak­ing sure the vari­ous parts of the pro­ject mesh togeth­er. A pro­ject man­ager makes it pos­sible for the team to work as effi­ciently as pos­sible. This might mean shield­ing them from a man­ager who wants to change require­ments every day (one of the good things about Scrum, BTW, is the sys­tem for mak­ing sure that does­n’t hap­pen), or schedul­ing the secur­ity reviews for the right phase of the product design and release cycles.

In a small com­pany, the pro­ject man­ager is often also the product man­ager, doing all of the above as well as talk­ing dir­ectly to cus­tom­ers, tak­ing part in online dis­cus­sions, attend­ing con­fer­ences, and tak­ing part in rel­ev­ant stand­ards activities.

All of these are neces­sary activ­it­ies, and they all involve meet­ing with oth­er people, wheth­er in per­son or via some oth­er com­mu­nic­a­tion mech­an­ism. They aren’t tasks that require you to shut your­self away and think for hours, unlike, say, design­ing the serv­er-side archi­tec­ture, or hunt­ing down a recal­cit­rant bug. Paul Gra­ham recently wrote a rel­ev­ant piece entitled Maker­’s Sched­ule, Man­ager­’s Sched­ule. Using this ter­min­o­logy, each team mem­ber is a maker. It’s the pro­ject man­ager who takes care of the man­ager­’s sched­ule on behalf of every­one else, it’s the pro­ject man­ager whose sched­ule is inter­rupt­ible. The pro­ject man­ager does­n’t have the lux­ury of look­ing for­ward to a whole day of unin­ter­rup­ted work, the time to get deep in the zone, the abil­ity 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 does­n’t also have to worry about HR issues, or nego­ti­at­ing an NDA, or telling a sales per­son why that large fea­ture for one cus­tom­er can­’t be added between now and tomor­row morning.