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:
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.
Has anyone tried this? Any stories of how this played out in the “real world”? I’d love to hear about it!