Pair programming meets pair managing

I’m a believer in pair programming. I understand it doesn’t work for everyone, and I would advise people who do enjoy it to make sure they are still spending time sweating (and drinking and swearing) their way through hairy technical problems. Someday[1] I’ll write a post fleshing out my thoughts on pair programming, but today I’d like to talk about pair project managing.

Here’s where I’m coming from. As a project management minded developer I am often frustrated by programmers who don’t understand the project management side of their work or the associated business implications. I’m also frustrated by project managers (and people in “business” roles) who don’t understand software development. What’s worse is the sense of deliberate ignorance that comes in when one side actively avoids learning about, or admitting knowledge of the other. You can be a good engineer without understanding project management, and you might even be able to be a good PM without understanding development, but it sure seems like everyone would be better off if they understood the other side a little better.

There’s another issue that comes up regarding project managers. If you need a wall built and you hire someone to lay bricks their contribution is evident in the quality and growth of the wall. If you need the wall built faster you can divide it up into sections and have one or two brick layers work on each section. However, as famously explained in The Mythical Man Month, there’s a limit to how much production gain you can get out of throwing more people at the problem. At some point communication and coordination, not brick laying speed becomes the choke point. This is when you bring in a supervisor. Their role isn’t to lay bricks, but to help the brick layers work more efficiently and keep everyone’s objectives in line. In my (admittedly overly simplistic) characterization of things. These supervisors are the project managers, they don’t actually “produce,” “build,” or “create” anything, but they can be essential in a project’s success. However, when you have the choice between bringing another developer into you team, or project manager what’s the cut off point when the project manager will result in your “wall” getting built faster and better?

There isn’t a hard cut off. Queue the sad trombone.

If you are in this situation, and on the fence, consider this:

Pair project management

In pair project management you bring on an additional developer that has interest in the project management side of things, and you select one of your existing team (who is also interested in project management) to take on project management for the next project. This programmer is no longer accountable for producing project code (though they are welcome to engage in low priority bug fixing as time permits). Their main responsibility becomes running the project. Your new developer (who is also interested in project management) takes on a backup project manager role. They fill in when the primary is absent, and assist the primary as need be. Their primary responsibility remains project code development. At the end of your project, the two switch roles and the cycle continues.

Here’s why this is good.

  1. Programmers like to code. This makes sure they get to spend a lot of time coding.
  2. Programmers like to learn. This lets them learn a new skill by doing (project management).
  3. It’s easy to get out of touch with programming if you aren’t doing it. This keeps your project managers engaged in the code, and honing their skills on two fronts.
  4. The point at which you need someone doing project management as a primary responsibility is likely before the point that you have enough project management work to fill up a full time role. That spare time is at best wasted and at worst used to interfere with the developers who are busy.

Has anyone tried this? Any stories of how this played out in the “real world”? I’d love to hear about it!

  1. I’m a programmer, so you know what that means…