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.
[…] Coding vs Non-Coding Project Managers | Anyway 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. (tags: agile Product_Management development) This was written by Chuck Allen. Posted on Tuesday, August 11, 2009, at 10:05 am. Filed under Uncategorized. Bookmark the permalink. Follow comments here with the RSS feed. Post a comment or leave a trackback. […]
That’s an interesting observation. Part of why I’ve chosen to be a “coding manager” is because I know in order to maintain an atmosphere where I can lead by example I have to be hitting the code. Especially when I’m trying to drive “new” things like test driven design, code reviews, etc.
However, I’ve also made sure that everyone in the company knows that if they want to interrupt someone on my team, they interrupt me. Then we figure out when we can get some of the devs time if they urgently need it. Say, just before (or after) our morning Scrum meetings so that the makers can spend the next 2–3 hours pushin’ code through.
I admit, it’s kind of crazy doing both Makers and Managers schedules. I have a hard time balancing them both and it’s quite often where I get the feeling that I’m slipping in one responsibility or the other. Long term, I don’t think it’s a sustainable position if I want to maximize the teams abilities and potential.
I wholeheartedly agree with this post. The notion of a “coding manager” is a fantasy for an organization that wants to be around for the long term. What such employers want is somebody capable of holding down 2 jobs (with the hours to match). This works in the short term, but you can’t build a long career or business on that. Paul Graham described that in his essay where he did the manager work between 12PM and 5PM, and the coding work between 7PM and 3AM. i.e. 2 jobs.
However, if you are an investor, these kinds of coding managers are ideal. It helps reduce costs of a startup, and since most startups only last a few years (because they fail, or grow), you don’t have to worry about burning out your long-term asset (the coding manager), or the burnout will come when somebody else is running the show.
[…] had a couple of interesting comments on my piece about Coding vs Non-Coding Project Managers; in my case it was the way things worked out rather than a deliberate […]