Blog :: Managing Programmers is like...

Once again time has been slipping through my fingers. I've got lots to talk about, but haven't been disciplined enough to post all my pent up thoughts. Glad to see I'm not the only one with a bunch of items marked "Keep New" in Bloglines till I can get around to writing about them.

I've been thinking about Management lately. I read Rands in Repose who often writes about managing programmers and
of course Joel on Software frequently talks about management issues (the conclusions to Joel's Essay on Context Switching should be memorized by anyone managing programmers. I'm serious.) More recently I have been spurred by reading Fred Brook's Mythical Man Month. Brook's lessons are less relevant to me (a web programmer working on small teams using dynamic languages) than to his original target audience (large teams writing operating systems in machine  or assembly language). It's been interesting reading even when not applicable, however, and its got me thinking more about management in the software industry.

When it comes down to it, once a project is started a manager can do almost nothing to positively affect the progress of the job. I don't mean that a manager has no effect or that there is no difference between managers! Far from it; what I mean is that managers cannot positively impact progress, they can only remove impediments that may prevent or hinder progress. Or they can add them.

I know you're thinking of objections already. A manager could motivate the people working on the project. Or add more people to the team! Or ... Well, actually that's about it, and neither option is actually as effective as it appears. First the manpower issue: per Brooks, adding manpower to a project can actually delay its completion! You'll have to read the book to see why in detail, but in brief, explaining/training the new help on the details of a project can actually take as much time as you gain by the additional production (if any). This is of course if the project is completely inter-related (and most software is); if there are portions that are completely separate additional manpower could of course speed there completion without affecting the productivity of the existing programmers. So what about motivation?

Once again, motivation is not really susceptible to short term managerial control. As Joel on Software notes in another absolutely essential article, motivation basically doesn't work. According to Alfie Kohn, writing for Harvard Business Review "at least two dozen studies over the last three decades have conclusively shown that people who expect to receive a reward for completing a task or for doing that task successfully simply do not perform as well as those who expect no reward at all." This basically makes sense: if you give me monetary bonuses regularly I come to expect them, to feel that I deserve them and that I am cheated if I don't get them. If you give me coffee mugs or plaques or (dare I say it) pins with slogans on them, I feel insulted. You really think the difference between me doing a good job and a bad one is this pin?

Ah well. More anecdotally, my experience is that analytical personalities (geeks and engineers) tend to react very negatively to perceived attempts to manipulate them. And they perceive "motivation" as exactly that.

So what can a manager of a software project do? Ideally, nothing. Nothing at least, that the programmer is aware of. Behind the scenes, the manager should be clearing obstacles that prevent programmers from doing there jobs. If you've read the links you know that context switches are killers to productivity. Meetings? Progress Reports? All come at the expense of productivity and a good manager will know when it is a price that must be paid and when it is not worth it.

I meant to tell a story. This story happens to be true and is a good example of the unintended consequences of active managing. When I first got out of college I worked for a dot bomb; one of those internet companies with a little VC, big ideas, and a dubious business plan. Now initially we had a very small team: I was the second most senior programmer and we had a room of about 8 or 9 programmers and graphics designers working on databases and flash applications. Because we were so small, we were pretty informal and initially we filled out time cards by hand. My immediate boss was sort of in charge of making sure people were honest about the hours they worked, but we tried to be flexible with people's time. If you marked your card 8-5 but you actually worked 8:30-5 with a half an hour lunch break, hey that was fine with us.

Eventually, our manager got irritated by people coming in at different times and brought in a time clock. No more flexible accounting, from now on you punch your card when you sign in and out and you only get paid for the hours you actually worked.

This of course, could only end badly. As it happened most of the programmers were working an extra 10-20 minutes a day. We were tackling some semi-interesting problems and people were enthusiastic; sometimes showing up a little early to informally meet and brew the day's first pot of coffee, more frequently working on "just this last bug" untill 5:20 instead of racing out the door at 5pm. Two weeks after the time clock was introduced, the two senior programmers were again called on the carpet, this time because people were working too much. Apparently people had to be paid in quarter hour increments and so everybody was getting paid 1/2 an hour of overtime every day. Accounting didn't like this much. The new rules were: if you came in early, wait untill it was actually 8 o'clock before clocking in. Likewise, if you were going to leave at 10 after 5, clock out right at 5 and go back to doing whatever you were doing.

This of course provoked much grumbling and many complaints from people who arrived early, forgot to clock in right at 8 and were being docked 15 minutes pay despite actually being here. Eventually the senior programmer aquired a key to the time clock and we went back to the old system: hourly employees worked an average of at least eight hours a day and we forged all the time cards to say 8-5 with an hour lunch break. We had finally arrived back at the old system, with the extra baggage of 3 or 4 meetings, recriminations between departments, and a new daily 10 minute task that reduced the Senior programmer to the role of secretary/forger.

Moral of the story? I don't know, it seemed like a good story to tell! It illustrates nicely, however, my current philosophy on programmer management: at the level of the trenches, dealing with people actually writing code, managers ought to fire and forget. Assign a single task and wait to hear back that it is completed (insert all necessary caveats about passing on information, coordinating resources, etc, here). Any temptation to manage things in an active way... Will probably work out about as well as the time clocks did...

Posted on Jan 21st 2006, 08:42 PM