So you’ve put together a hardware or software startup company. Chances are you didn’t give a lot of thought to the next step should be in your IT or software company organizational structure development. You just wanted to bring in some revenue and find a way to keep the doors open. Or, maybe you gave it a great deal of thought! Even before you finalized your initial business plan! There are quite a few anal-retentive, extreme–planner types out there. You know who you are!
I don’t mean to make light of this issue; it’s actually quite a serious one. Let’s look at a few of the questions to consider when deciding how to organize your company, as well as a few typical options:
IMPORTANT ORGANIZATIONAL STRUCTURE QUESTIONS TO PONDER
What are the strengths, weaknesses, and operating styles of the principals?
I believe that this is a critical question to ponder if one wants to organize the company successfully. One of my all-time great examples is HP. Bill Hewlett and Dave Packard instituted a decentralized org structure almost from the very beginning of Hewlett-Packard. They kept the operating units small by breaking them up as they grew. In my opinion, this was one of the great drivers of HP’s success. It worked well because it suited their own personalities, as well as the folks that they hired. They believed in “Management by Walking Around”.
But they also believed in motivating high performance by allowing their employees to use all of their talents, without unnecessary constraints. It seems simple. But it is often hard for managers (especially hands-on, entrepreneurial types) to let go and give their employees enough rope and space to excel. Again, I believe that this hands-off, decentralized approach worked well because this style fit with Bill and Dave’s personalities.
What are the key personality traits of your employees and target hires?
This is similar to the question about the principal’s styles above. The organizational style needs to fit with the “personality” of your company and its culture. And the company is ultimately characterized by its people. As a quick example, a certain company may have a lot of “type A”, self-motivated people with strong leadership skills. In this instance, a decentralized org chart may fit better than a hierarchical, centralized approach.
Are there disparate technologies within the company?
This should be a big driver in deciding how to design an IT or software company’s organizational structure. If you have several different technologies, how do they fit together technically, if at all? Do they fit together from a market perspective? Is there a lot of synergy or a need to coordinate between technologies/products? If so, a centralized, hierarchical approach may work best.
The less overall “fit” that there is between your core technologies/products/markets, the more inclination I would have to organize the corporation using a decentralized, autonomous business unit approach. This assumes that the resources are available for a decentralized organization. Because one disadvantage of this approach is there is always going to be some duplication of roles across independent business units. However, let’s assume that the resources are so scarce that you can’t decentralize properly. Does it really make sense to try to be successful with multiple, highly disparate products/technologies anyway?
Now let’s take a look at some common ways to design hardware and software company organizational structures.
HARDWARE & SOFTWARE COMPANY ORGANIZATIONAL STRUCTURE OPTIONS
This is the classic organizational style of traditional businesses. The strength of this type of organization is that it is easier to optimize each function. That’s because there are usually more resources available within each function, in a centralized approach. These resources can enable a more sophisticated approach to best practices.
On the downside, I remember well the frustrations of my first job. It was with a Big 3 Automotive manufacturer, which was VERY hierarchical and centralized. The company was SO hierarchical that it paralyzed the organization to a great degree. Trying to get even the simplest, small thing done often had to go many levels up for approval. It was like trying to turn a battleship on a dime and was really, really painful. I’m not a big fan of this org structure style for larger and more complex companies. But for smaller, single-market, or single-product companies, it generally is the optimal approach.
Decentralized/Autonomous Business Units
This is the polar opposite of the traditional hierarchical organization discussed above. It’s my preference for a growing software company organizational structure which is starting to “spread its wings” beyond its initial market or technology focus. I also prefer it in general for larger companies as well. Its strength lies in the ability to keep lines of communication short and keep personnel close to the marketplace. It also motivates self-starters by making available more positions of broad responsibility.
For medium-sized companies, the danger lies in decentralizing too early. You don’t want to do it before there is really critical mass to run separate business units. That’s because this org design comes with some added costs, due to duplication of functions, as mentioned above. One good way to mitigate this at least initially is to centralize and share as many of the non-product-specific functions as possible. This would include functions such as finance, HR, quality control, etc. The key functions that absolutely need to reside in the business units are usually marketing, product development, possibly manufacturing (for hardware companies), and occasionally sales.
Product-Centric or Market-Centric
This is a variation that can be combined with either of the two major types of IT or software company organizational structures discussed above. For example, within your marketing department, there could be people assigned to product lines as product managers. Or maybe to market segments as market managers. Sometimes a hybrid approach is used, where there are product managers for unreleased products, and market managers for currently-marketed products.
This organizational style is “overlaid” on top of a more typical organizational structure, such as the types discussed above. The main idea is to set up “dotted line” teams, responsibilities, and reporting structures that are desirable, but fall outside of the usual way a team is organized within the main structure in use. For example, in a hierarchical organization, you might set up a matrixed, cross-functional team. The team’s purpose might be to put focus on the launch of an important new business initiative or product line. This may give the new initiative more emphasis than it normally would get, given its modest importance to the overall business at that point.
If used properly, matrix management organizational techniques can be a great way to dampen the negatives that are inevitable in any rigid organizational structure. It must be used with caution, however. It can be used too frequently, or without endowing the “head” of the matrix with real power to accomplish the desired goals. Under these circumstances, matrix organizations can quickly become ineffective and politically driven entities. Not to mention the butt of jokes around the water cooler.
This is just a quick take on a very complex topic. There are many different ways to design a hardware or software company organizational structure to foster success. Too many to discuss here. I just touched on a few of the issues to consider, as well as typical organizational styles. Hopefully, this short article will stimulate some thinking on this important topic. I hope that it may help you avoid the haphazard formation of an organizational structure. Please post a comment below if you have a take of your own to share.
Follow Phil Morettini and Morettini on Management via Twitter, Facebook, LinkedIn, RSS, or Subscribe to the Morettini on Management Newsletter hosted by LinkedIn. Contact Phil directly at email@example.com