Your company reorganization: Keep it simple, stupid

Highlight the work, not the looks of the org chart, when determining your company's structure

Dear Bob ...

We are a medium-sized IT shop (approximately 100 people). One of my managers is retiring next year. My problem is there is no immediate heir apparent. I have a very talented, hard-working group that is a veritable mix of all possible personalities that brings with it personality conflicts.

[ Want to cash in on your IT experiences? InfoWorld is looking for stories of an amazing or amusing IT adventure, lesson learned, or war tale from the trenches. Send your story to If we publish it, we'll keep you anonymous and send you a $50 American Express gift cheque. ]

And we're organized around technologies -- .Net for new development and support for legacy Java -- which I know has a lot of potential for creating conflict as well.

Off the Record submissions

Our proudest achievement has been getting this group to work together as a functioning team (most of the time). I'm concerned that this will all unravel following the retirement.

The soon-to-retire manager and I have discussed some alternatives. One involves blending the management of the Java and .Net groups such that one manager handles the "people stuff" and the other manager handles the "project stuff." The remaining manager handles both very well, and the thought is to give her the "people stuff" and find someone else for the project-related work with the assumption that those skills are more easily found in the IT world. Thoughts?

- Not shy, am retiring

Dear Retiring ...

The answer to your question is obvious: You need to bring in an IT organizational specialist to perform a lengthy and expensive study of the whole environment. Interestingly enough, I know just whom you should call. Failing that ...

It's rare when the right question is what the organizational chart should look like. A better question is what the most important work is. You then design the org chart to minimize the number and layers of organizational boundaries that will interfere with that work.

I'm not in love with separating "people" and "project" responsibilities, largely because they're inseparable. Project success depends on human performance; conversely, whoever is responsible for the human side of things will need to understand how each employee performed on projects.

Here's a guess: There's a strong sense of organizational rivalry, bordering on hostility, between the Java and .Net teams. If that weren't the case, I'm pretty sure you'd simply promote the head of the Java team to become the head of the combined departments, especially if she has the ability you describe. The most likely reason you aren't thinking along these lines is that it would create the impression of a hostile takeover of one team by the other.

You can go one of two routes:

  • Promote the manager anyway; establish team leads for the .Net and Java teams to report to her, and don't worry about the rest. She'll figure out how to make the interpersonals work.
  • Figuring the current organizational structure is working well for you, don't change it. You have a year or so to recruit or develop a replacement. Take advantage of having the time, and do so.

The disadvantage to the former approach is that it adds a management layer, increasing the organizational distance between you and staff-level employees. The disadvantage to the latter: If the manager who is staying is ready for and deserves a promotion, this is an opportunity to provide it.

Either of these two alternatives can work just fine, or they can fail. The outcome depends mostly on who sits in each of the critical chairs.

- Bob

This story, "Your company reorganization: Keep it simple, stupid," was originally published at Read more of Bob Lewis's Advice Line blog on