.comment-link {margin-left:.6em;}

Uncommon Sense (for Software)

This blog has been moved to www.UncommonSenseForSoftware.com.

Friday, February 10, 2006

In Software Project Management, Size Doesn't Matter

A few months ago, I was discussing project management with someone from the financial sector. This person, who is rather good at his own line of work, admitted he didn't know much about project management (but had some clients that did). We were talking about some new ways of looking at project management, particularly, the domain specific approach that I often advocate. Wanting to test my theories, he picked up the phone and proceeded to call one of his clients, whom he knew to be a real top-notch expert in project management. What is interesting is that this project manager client of his was perceived to be an expert not because of any particularly extraordinary skills he had displayed, or even a long list of stellar accomplishments but rather, because he managed really BIG projects - like 4 years, 200 people, $50 million projects. Big ones.

At first, I didn't even think twice. Of course, I thought, I suppose you would have to be really good to handle those kinds of projects. I mean, if co-ordinating 10 people is tough, 200 must be about 20 times tougher. A lot of people would certainly reason this way. After meeting this manager, which was a rather familiar experience (nothing much new), it triggered a line of thinking:

It is often far more difficult to manage a 10 person project than a 200 person project.

Let me explain. It's not that I'm saying that the person managing the 10 person team is more important that the person managing 200 people on a $50 million project. I'm not equating difficulty with importance - and by difficulty, I'm talking about the project management responsibilities, not other duties they may have to perform.

Speaking with this project manager in particular gave me deja vu. It was more like speaking with a CEO than a project manager.

In chatting with any "project manager" with a team size of 100 or so people, what you quickly realize is that they're not project managing anymore at all. They're more like a CEO, involved at the capital allocation level, for multi-year operations. They are running an organization. They're tuned in to major technological shifts and trends, like "If we bet the farm on Lotus Notes, will it still be the platform of choice when we finish in 4 years?" Heh heh. Oops. When you're talking about a project that big, the head honcho is managing managers, who possibly manage other managers, who have team leads, who lead the people actually producing the work. They are more like mentors to the managers who are actually managing. The organization is large enough then, that it becomes really difficult to see the direct impact that the top decision maker is having on the success or failure of the project. I liken it to riding (or steering) the wave, rather than causing it directly. How many debates have you heard after some political or fortune 500 scandal where hoards of people say things like, "Well, you can't blame the top dog for something that some underling in another office did. It's not his fault." There you have it, by popular opinion, less direct accountability for large teams. If you can't blame the top dog for failures, then how can you attribute success to him?

Life in a small team however (say 10 people), is much more likely to give you a heart attack. There's nowhere to hide. The pace is way faster. It's very easy to see the direct impact (good or bad) that each person is having on a daily basis. When you're managing a software team of less than 10 people, chances are, you're not just the manager, but one of the developers as well (or at least a designer or architect). The dynamic of a 10 person software team is much more clear - one person managing, and 9 people producing. I think it's at about 10 to 15 people, where it is no longer practical for a manager to even touch the source code - in fact, it can be down right dangerous. Coding is not something you should dabble in. Either let it consume you and be really good at it, or don't touch it. After 15 or more team members, it's quite likely that there will be a lot more delegation. At 15, you may have 1 manager and 1 technical team lead. At 35, you probably have a Director or a couple managers and a couple technical team leads. At 100, well, you get the picture. With each round of delegation (which IS necessary by the way), some amount of pressure, and direct accountability is taken away from the top dog. I'm not just theorizing here, I've actually experienced it. While I haven't managed a 100 person team yet, I can already see the difference between 10 and 35 developers, team sizes I have managed. To manage 35 developers you really need to break them up into teams of 5 to 7, with technical team leads, and a manager or two. So even at 35, there's a couple degrees of separation between the top policy maker, and the folks actually producing code.

In that awkward team size of about 10 developers, you're likely to be as much a producer as a manager. It's really tough to be great at both. Just like you shouldn't dabble at coding, dabbling at managing just makes you a manager with a disadvantage. It's at the point in time where it is clear to everyone around you that it is no longer practical for you do be doing any producing, but that you should be managing full time, that your project management life actually starts to get a bit easier. At that point in time where you have managers reporting to you, your project management worries get lighter still (though you probably have new responsibilities keeping you up nights).

All this to say, over that last 13 years of managing software teams, I haven't seen convincing evidence that project management difficulty increases linearly with team size. There's a breaking point at which the project management (only) difficulty actually decreases when the team sizes breaks a certain point. Project management worries then get replaced by other worries (like what the heck should we be betting the farm on... 'cause if I'm wrong, we go out of business - easy stuff like that).

Am I right?


  • I am experiencing exactly what you have written. I totally agree with you. I am managing a team of size less than 10 and a problem of even one team member disturbs the whole calculation. I will like to know more about your concept of Domain specific management. I feel that, domain experience eases the job of project manager in initial design and planning phase. My name is Dhananjay and you can reply me on dsk3011@gmail.com.

    By Anonymous Dhananjay, at July 02, 2006 4:59 AM  

Post a Comment

Links to this post:

Create a Link

<< Home