Fog Creek Software
Discussion Board

Project Managers vs. PRoject Leaders

I have worked for a couple of different companies throughout my career. It seems like they all structure their IT groups differently.

The best structure that worked for me was a team that had both a project manager (not so technical but process oriented - requirements, interacts with business group, oversees meetings etc) & a Project Leader (technical, does coding, estimates, writes specs, leads other programmers).

Other companies I have been with and am with now take these 2 positions and merge them into one with turns out to be a disaster.

My question to everyone is how does your company structure their dev groups and what do you think is the best way to structure it?


Wednesday, February 26, 2003

Ours is typically structured around three management roles: technical lead, project manager, and program manager.

The technical lead is responsible for all of the technology decisions and he manages the technical team.  His word is final.

The project manager is responsible for overseeing the operational aspects of the project, especially coordinating the teams that are producing the technology, the content, the documentation, graphics, and all the rest of the bits that go into a production release.

The program manager is responsible for launching a series of projects that address a certain market, so he's kind of like a product line manager.  The main reason for this is market analysis, so there are usually several similar products targetting different segments of a market.  This is the guy that usually sets up schedule, scope, and budget targets for the individual projects to work against.

Sometimes other parts of the products grow a little bit and get their own lead.  So, for example, there is sometimes a documentation lead when the documentation requirements merit more than a couple heads, or there is a media lead when the product has extensive or specialized media needs.

I've done the technical lead role and am currently working in the project manager role, and I think this separation of concerns works very well for our needs.  The main thing that makes this work, I think, is that everyone is reasonable and professional.  If we got someone into this mix that was a "yes man" or someone that lived in a separate reality, I can see where this kind of a system would go down in flames.  Whoever developed this strategy also put into place a set of checks and balances so there is very little management by fiat that I have seen.

A Project Manager
Wednesday, February 26, 2003

That's exactly the setup I want here. I spend the most time with the code, know the most about the architecture, and have the best knowledge of the code.

So why am I not a technical lead? Who knows. It means the director makes stupid decisions because he doesn't know what he's talking about. (See my thread on HTML to TIFF below, promised to a customer before I'd been consulted as to its feasibility...)

Better than being unemployed...
Wednesday, February 26, 2003

We had something like this in several projects at my previous company. Team leader (business-oriented, not
programmer at all sometimes) and project manager (techie at all times). Worked well for me (team leader).
Economic education and management skills plus CS and programming skills = good results.
Sometimes we also had chief architect (architectural decisions) and process manager (process management).

Note: Some companies call the business guy -project manager and the techie guy -team leader.

Wednesday, February 26, 2003

KenB wrote, "I have worked for a couple of different companies throughout my career. It seems like they all structure their IT groups differently."

Imo, this is probably the biggest reason why technical software development positions are so hard to fill (the employer's viewpoint) and are so difficult to do for a long period of time (the programmer's viewpoint).

KenB wrote, "what do you think is the best way to structure it?"

That is very difficult question to answer in a paragraph or two. 

Certain development methodologies sound wonderful on paper (i.e. Microsoft Solutions Framework).  Unfortunately, most employers are un-willing or un-able to setup project teams in such a well-defined manner. This is one of the reasons why I find the Agile methodologies so interesting.  They "Agile way" may not be the "best way" to do software development, however, these methodologies (and the type of team structure they advocate)  might be the most practical way.  That is, you have your developers involved in all aspects of the development process and hire project managers and/or analysts only if you can afford to do so.

When I first got into this field, I worked for a very small but very structured/organized company (they had their sh*t together when it came to software development). Project teams consisted of:

1) A project manager - all of them could code and had coded at one time.
2) Systems Analyst(s) - did most of the customer hand holding, spec work, etc.
3) DBA
4) Programmers - had various titles and responsiblities. Most (such as myself) did nothing but sling code all day long.

The pay sucked, but I was able to go home at 5 PM and rarely worked more than forty hours a week. Of course, those were much simplier times -- 286/386 PCs were considered to be top-of-the-line.

Nowadays, when people ask me what it is like to work as software developer in the IT industry, I tell them that in many work sitiuations it like being a German soldier/commander in late 1944/early 1945.  You fight the enemy with whatever forces you are able to cobble together at the last minute.

Kampfgruppe is German for "Battlegroup". These were temporary formations created to counter emergency situations, cobbled together from whatever units happened to  be in the area.

One Programmer's Opinion
Wednesday, February 26, 2003

*  Recent Topics

*  Fog Creek Home