Every company struggles with this, particularly as it grows. The way of organizing a corporate structure can be divisive at times, and clear release of pressure at others. I have found that as I witness the process of corporate reorganization due to the departure of a CIO coupled with the high growth of a company, there are many aspects to take into account before a proper decision is made.
1. Team Culture - The culture of the team is not necessarily intuitive. As in a good marriage, opposites sometimes complement each other. If you have a "rules lawyer" type of organization, sometimes it's a necessary breath of fresh air to bring in a manager that will play a little more loose and easy. If you already have a loose corporate culture, sometimes it's instructive to bring in a bull-by-the-horns administrator. I'm not saying that bringing in a polar opposite is always the proper play, but it should bear consideration. There are two "interfaces" for the management team... that of the managers to the team members, but don't forget the interaction of the managers to the executives. The culture of both of those relationships should be examined with care.
2. Personality Types - I'll dig deeper into this one, but I've had good success by identifying the personality types of each tier of the management structure. If you have an organization where the team must make collective or aggregate consensus decisions, then the personality types of the team members need to be purposely examined. Take a Driver mentality leader and blend that with an Analytic "goaltender". This seems to work well as their highly complementary aspects will combine to form a good collective management team. You can also blend Expressives and Amiables to keep the consistency of a "dreamer" combined with the "doer". Be careful in situations like this to not try to force two identical Driver or Expressive personality types in the same confined space. It only results in overstated competition and doesn't serve the organization well. Give the driven personality managers room to breathe and they will perform for you.
3. Process Patterns - In any given team there are theories or patterns to how the work is conceived, designed, implemented, tested and deployed. This holds true for software development or marketing initiatives. As you decide on which implementation pattern you are going to adopt, it makes sense to conform the organizational structure to fit. In the IT space you could examine the Agile or Waterfall software development lifecycles, but to put it in truly general terms, you have models where everything is planned out in advance and then all implementations follow the "template" according to the plan. You can alternatively have a model where the "unplanned-ness" is predicted ahead of time, so your initial draft is known to have gaps, and your implementation plan takes periodic "pauses" where you can alter the plan as you see fit.
4. Skill Set - There are many times where the strengths and weaknesses of each management team member can help you predict what positions they should be positioned for. You can also leverage their personality types. If your struggle is with quality assurance and you have a good Analytic leader in your organization, then it's a pretty safe bet that diagnostics and debugging is a likely strength for them.
5. Training - You can cram a square peg into a round hole, but it's going to be far easier if that square peg really prefers to be round anyway. If you are taking a manager that is Amiable and you keep sending them to high energy, confrontational management classes, then you're probably going to be disappointed. By examining how people innately behave, you can really steer them in a direction that they are already comfortable with.
6. Experience - The past histories of the team members can inform you quickly into what roles they are already comfortable with. This isn't always a panacea but it can be instructive. A person that has always been a leader in the past may tend to be comfortable with more leadership roles. A person that hasn't had that level of experience, but desires it, should be evaluated carefully. Many times we are thrust into management roles simply because that's the only institutional way of earning more money. This simply forces the issue and drives people into roles where they are no longer happy.
Here is a sample organizational structure that highlights mapping the organzational structure to the implementation pattern. In this example we take the AGILE implementation plan and compare it to the organizational structure that might best fit this type of implementation pattern. Note how the phases of Project Management, Scope and Business Requirements loosely map to the Project Management Team of the organization. In similar fashion, the Software Requirements, Detailed Design, and Technical Architecture map to the Architecture and Development Teams respectively. These are loose associations but by modeling the organization after the implementation pattern, there is an integrated team concept while still preserving the roles and responsibilities of each group.
It is my hope that you will examine your own organization and take the time to first define how you plan to implement things, and then try to dovetail your organization to fit the model that best works for you.
Here are some additional resources to help guide you:
Here is a great resource that discusses the differences between Mechanistic and Organistic Corporate Organizations... something to sagely consider, particularly if you employ high tech workers: