* The Business of Software

A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.

We're closed, folks!


» Business of Software FAQ
» The Business of Software Conference (held every fall, usually in Boston)
» Forum guidelines (Please read before posting!)


Andy Brice
Successful Software

Doug Nebeker ("Doug")

Jonathan Matthews
Creator of DeepTrawl, CloudTrawl, and LeapDoc

Nicholas Hebb
BreezeTree Software

Bob Walsh
host, Startup Success Podcast author of The Web Startup Success Guide and Micro-ISV: From Vision To Reality

Patrick McKenzie
Bingo Card Creator

Optimal organizational structure for largeish software org

What do you think the best way to organize a decent sized software development shop is?

I work as an architect in a largeish software company.  Our development organization has about 450 staff and contractors when you include management.

We currently spend about 70% of development dollars on maintenance and enhancements of existing products, and the remainder goes toward development of new products.

I've been having a running discussion with my boss about what organizational structure makes the most sense for our development organization.  The choices seem to be a product-oriented structure, where managers are assigned products, and have both HR/resource management and project management responsibilities, or a functional structure where projects are led by project managers and the "managers" are more resource managers. 

The product oriented structure seems more susceptible to resource hoarding and missallocation (because the next thing on a department's todo list might not be the most important thing organization-wide).  The functional structure seems like it would have reduced ownership of products by teams.

Any thoughts or pointers to resources elsewhere?
Steve Peterson Send private email
Monday, November 01, 2004
There is no one right structure, though there are some I'd avoid.  Each structure has strengths and weaknesses.  Those have to be managed.  If you don't have some product focus, you loose continuity.  Resource allocation needs to be managed regardless of the structure.
Kate Send private email
Tuesday, November 02, 2004
In my experience, a Functional organization quickly morphs into a Product organization. The only time the development staff is freed to move across product lines is when there are no plans for another release (i.e. the product is sunset).
Tom H
Tuesday, November 02, 2004
My first programming job was as a "maintenance programmer" at Nortel: I maintained software for which the original developers had moved on to another project developing something else. It worked pretty well; their software seemed to be engineered for maintainability: for example it included design documents, and suites of automated tests.
Christopher Wells Send private email
Tuesday, November 02, 2004
The "Product Team" organization is superior.  I've tried "Functional Matrix" organizations, and the shuffling of labor around makes the people feel interchangeable and devalued.

A "Product Team" with a Project Manager and an assigned team of people, with an identified product at the end, allows buy-in and expertise development.

I suppose the people on the "Product Team" can "assist" with other projects -- but it is essential they have a 'home' project.  The 'home' project gives them a place where their talents are well-known, they can be evaluated by someone who knows their work, and they can 'belong'.
Tuesday, November 02, 2004
I've never seen a matrix-styled organization run very efficiently or effectively. That said, I think you can organize functionally or along product lines successfully. You need to ensure that a) everyone is clear on what they are responsible for, b) that only one person is ultimately responsible for any one thing, and c) that all important (subject to interpretation) items are covered by someone.
Jeff Kotula Send private email
Tuesday, November 02, 2004
I second (or is it third or fourth) the product team organization. If the people don't have skin in the game, they are just employee numbers waiting for their next assigned gig and feeling like they have multiple managers.
m Send private email
Tuesday, November 02, 2004
I think that Jeff explained it really well and m has picked up on the theme.  If people are treated simply as an interchangeable resource they will eventually end up behaving that way and change themselves to another company.  Either that or they will completely unplug from the organization and not care about what happens there.

Ownership is key, if you are not willing to give some level of ownership of somthing at all levels (right down to the summer intern) then you are not going to be able to keep a large percentage of your staff motivated to achive the goals of the company.
0xCC Send private email
Tuesday, November 02, 2004
Another vote for Product Teams.  However, you need to provide a way for people to cross-pollinate if they want to.

Some people are perfectly happy producing daily TPS reports for 30 years, while others want to try something new every couple of years.  It's important that you give the latter a way to do that, otherwise you'll lose them to another company.
example Send private email
Tuesday, November 02, 2004
The politics in matrix organizations is terrible. To be avoided.

Tuesday, November 02, 2004
I would prefer the organization structure that is most strongly customer/value aligned. In this case, product team over functional team. (Are there other structural variations we haven't considered, yet, here?)

My experience in the trenches has been that functional organizations always degenerate into "keeping [other] people from doing things they shouldn't be doing." This is an inhibiting, rather than enabling, mindset; and quickly leads to suffocating bureaucracy, among other pathologies.

Preventing stupidity may sound like a laudable goal, but when you're focusing on internal risk avoidance, you're not focusing on customer value. When you stop focusing on customer value, you're dead.

Friday, November 05, 2004
My only experience is with the Product Organization.  Benefits:

1. Small boat phenomenon.  Everybody knows they need to row, bail, steer or the boat is going to sink.
2. Organization responds quickly to changes.


1. Encourages development of technical fiefdoms.  Leaders become good at stealing resources and denying success to other groups.
2. People become emotionally attached to product.  Prevents product from taking optimal course wrt overall organizational needs.

But this is the devil I know.  Would not choose Functional Organization under any circumstances.
Bob Rundle Send private email
Saturday, November 06, 2004
another vote for product. I recommend having some sort of Technical Lead/Architect on the team. Especially for larger teams of like 25.

regarding the potential fiefdom problem, i would recommend some sort of sister-group pairing. And promote rotation into other groups every 2-3 years.
CraigZello Send private email
Tuesday, November 09, 2004
I suppose the one advantage from a management stand point for functional groupings, is that if you have a large number of people with the same functional grouping, you can take advantage of "machine solidarity" for training.  I worked at a factory and I can't ever remember hearing, "Everybody does it this way" so much.  Programmers think while you aren't looking, where as assembly workers will be doing the exact same thing in 30 minutes 7 hours 2 weeks, and 20 years.  But on the flip side, the line managers were mostly concerened with playing favorites, and no one knew where or how the product was to be used.  The common name for this type of organization is a cluster fuck.
ragnar Send private email
Friday, November 19, 2004

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz