The Reorg

Multiple monotonal voices: We are TheReorg. Resistance is futile. You will be disenfranchised. Your cultural and biological distinctiveness will be cancelled out by forced association with opposing characters.

Companies seem to oscillate between two organizational poles: Project centered and Functional centered.

Project centered is great for start ups with a single project to deliver, but results in the usual fragmentation, duplication of effort and NotInventedHere competitiveness between teams as soon as multiple projects are required. Since coordinating across projects requires time/resources, that usually gets dropped in order to stay at least close to on schedule (in the short term).

Functional centered certainly facilitates consistency across projects. It is also very popular with middle managers in large corporations as it encourages stable fiefdoms over long periods of time. However, the down side is that short term pressures inevitably win out over long term strategic projects. And of course, the short term solutions provided under pressure will result in more short term problems in the next version or the next product.

I've noticed every company I've worked for that soon after new senior management comes on board or someone gets promoted, that the first thing they do is assess where the current problems are and then proceed to switch organizational structure to the other pole. Both the Project & Functional centered approaches have inherent weakness' that are obvious to many. And each mode's strengths solve the other's weakness' - that looks great for a few weeks or maybe months. Then the new problems show up and eventually there is another reorg. It's a way to change focus between long term strategic projects and short term immediate issues, but it doesn't actually solve any of the inherent problems associated with either of these default organizational styles.

You can say that people will just have to "do the right thing", but that will never happen because the pressures natural to those two systems oppose that. In any case, your energies are wasted, or at least very inefficient, when trying to balance opposing pushes/pulls.

I propose that we think about an alternate approach:

Have two types of Project directors/managers:

SpecificProject? Director
Integration/CrossProject? Director (instead of Functional management)

The focus here is that we want to deliver products, and we want these products to have compatibility and consistent quality. When the Integration/CrossProject? Directors are specifically tasked with cross-project issues instead of owning functional areas, the pressure is to solve cross-project issues instead of constantly pulling all resources to tackle a short term functional fire with a short term fix. Now, the Integration directors/managers would each still focus on a narrow functional slice.

The difference is that they are responsible for the success of compatibility across products instead of being responsible for the functional slice being delivered next to a customer for whatever project is first in line.

Engineers would be part of both SpecificProject? teams and Integration/CrossProject? teams to avoid the NotInventedHere problems. This does change the responsibilities of middle management somewhat. Instead of managing people that they have exclusive control/rights over, they now are responsible for facilitating successful product releases that they do not own exclusively.

This requires managers that have significant technical as well as people skills. They also must command "earned" respect as opposed to "entitled" respect based on their titles, since they will not exclusively control either the project or the people resources. Managers accustomed to functioning in command/control mode would resist this type of structure and wouldn't be suited to succeeding at it in any case. For developers the situation would be similar: instead of "controlling" a piece of the hardware/software pie, the focus is on everyone facilitating the successful release of multiple products.

I believe the structure I've proposed would inherently support/push people to "do the right thing" instead of the old paradigm that resists it at every turn. This is not to say that managers and developers alike who function in "control" mode wouldn't resist this new paradigm, but the paradigm itself will tend to reward "doing the right thing" and provide resistance to "controlling personal turf". The old paradigm (no matter which pole the pendulum is currently swinging at) does exactly the opposite.

This sounds like rather like matrix management, which has also been tried a lot. It has its own problems, but can be a good solution. See http://www.mit.edu/~mariats/WebSiteReadings/Reading_for_April_24.htm

In the proposed organization, who is responsible for scheduling the work efforts of the individuals, and actually determining what individual would work on what project? Based on what you start I extract the fact that you would have whole people working on a project and the Integration/CrossProject? Director is only responsible for bridging the gap between these people - Mpetrucci@kldlabs.com

OrphanPage