Reorganizing for Growth

I recently came across an article titled Reorganize for Growth and I thought that was interesting because typically reorganization has a negative connotation. People think organizations reorganize because something is not working, and they are right. But what comes after the organizational structure is fixed is growth. This particular story is about Kraft Foods. If you wish to you can read the full story here. I had one major takeaway from the Kraft story that I will share at the end of this post.

When I read the Kraft story though I thought, Kraft has tangible products, they have assets and inventories, and they have business and consumer customers so they have physical entities that they can reorganize around. For instance decentralizing certain product line decisions back to the business units that own them rather than going to corporate to make a decision about a product corporate knew nothing about was a change that made a big difference to Kraft.

But what of services organizations that don’t really have widgets to organize around. Let’s take an example I am very familiar with and that is an Information Technology (IT) organization. One might start an IT organization by dividing people into New work (new applications or new functionality) and Support work. This organization is purely financial but may not necessarily benefit the end customer. The new work is classified financially into revenue and capital expenses and can be amortized by the company whereas the support work is considered operational expense and categorized as a cost of doing business and therefore a direct hit to an organization’s bottom line. Guess what, the customer for the new work and support work is the same. But when he/she approaches the IT organization they don’t get seamless service. They have to deal with X person for new functionality, and Y person for bug fixes and God help them if it's not clear whether the new functionality is in fact new or a build on an existing functionality that was just recently built. They will go around in circles for days before anyone figures it out.

The second organizational layer comes in roles. Both new work and support work requires a project manager, a business analyst and developers. They both work for the same customer on the same product but they are completely separate teams reporting to different managers. Do you see a problem here?

The third layer is a built on the second because it too has to do with roles. Certain skills within roles can be distilled. A project manager and business analyst have the skills to work on any project, new or existing. Should they be organized in such a way that there is a pool of business analysts that project managers can chose from regardless of whether they are needed for new work or support? If that happens then business analysts are effectively leveraged no doubt, but they will spend a lot of time capturing hours spent on each project since one could be a capital expense and another operational.

Because of these complexities and shared responsibilities was born the matrixed reporting structure. Have you ever been part of a matrix reporting structure? It is a mess most of the time. Trying to keep one boss happy is bad enough, now you have two or even three that you have “dotted line” accountability too.

Every IT organization I have known has tried reorganizing (sometimes annually) around these three scenarios or a combination of them. And each time the only thing the reorganization does is create “activity.” And then things get messed up again. This brings me back to the one thing I picked up from the Kraft article that I said I would share with you at the end of this article and that is; while reorganizing structural, cultural, and operational changes must be made together because they influence one another.

Have you reorganized your IT group lately? If so, please share why and along what lines did you chose to align the group to?