Organizational Structures in Software & High Tech Companies

So you've put together a hardware or software startup company. Chances are you didn't give a lot of thought to what the next step should be in organization 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 bound your initial business plan--there are quite a few anal-retentive planning 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 options.

IMPORTANT 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 great examples is HP. Bill Hewlett and Dave Packard instituted a decentralized structure almost from the very beginning of Hewlett-Packard. They were careful to keep the units small, by breaking them up as they grew. In my opinion, this was one of the great drivers of HP's success, and worked well because it suited their personalities, as well as the folks that they hired. They believed in "Management by Walking Around", but also believed in motivating high performance by allowing their employees to use all of their talents, without unnecessary constraints. It seems simple, butit is often hard for managers (especially hands-on, entrepreneurial types) to give their employees enough rope and space to excel. I believe that this hands-off, decentralized approach only worked well because this style fit with Bill and Dave's personalities.

What are the key personality traits of your employees and target hires? Similar to the question about the principal's above, the organizational style needs to fit with the "personality" of your company, the culture. If you have a lot of type "A", self-motivated people with strong leadership skills, a decentralized org chart may fit better than a hierarchical, centralized approach.

Are there disparate technologies within the company? This is a big driver in deciding how to organize. If you have several different technologies, how do they fit together technically--if at all? Do they fit together from a market perspective? If there is a lot of synergy or need to coordinate between technologies/products, a centralized, hierarchical approach may work best. The less "fit" that there is between your core technologies or products, the more inclination I would have to organize using a decentralized, business unit approach. This assumes that the resources are available for a decentralized organization. But if resources are so scarce that you can't decentralize properly, does it make sense to try to be successful with multiple disparate products/technologies anyway?

Now let's take a look at some common ways to organize.

ORGANIZATIONAL OPTIONS

Hierarchical/Functional/Centralized - the classic organizational style of traditional businesses. The strength of this type of organization is that it is easier to optimize each function, as there are more resources available within each function in a centralized approach. This can enable a more sophisticated approach to best practices. On the downside, my first job 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 huge degree; trying to get even the simplest, small thing done had to go many levels up. It was like trying to turn a battleship on a dime, and really painful. I'm not a big fan of this style for larger organizations, but for smaller, single-market or single product companies, it generally is optimal.

Decentralized/Business Units - This is the polar opposite of the traditional hierarchical organization. It's my preference for growing companies who are starting to "spreading their wings" beyond their initial market or technology focus, as well as for larger companies. It's strength lies in the ability to keep lines of communications short, keeping personnel close to the marketplace, and motivate self-starters by providing more positions of broad responsibility. For medium-sized companies, the danger lies in decentralizing before there is really critical mass to run separate business units, which comes with some added costs due to duplication of functions. One good way to mitigate this is to centralize and share as many of the non-product specific functions as possible, 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 organizational structures above. For example, within your marketing department, there could be people assigned as product managers, or as market managers. Sometimes a hybrid approach is used, where there are product managers for unreleased products, and market managers for currently-marketed products.

Matrix - This organization 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 normal way a team is constituted within the main structure in use. For example, in a hierarchical organization, you might set up a matrixed, cross-functional team to put focus on the launch of an important new business initiative. This may give the new initiative more emphasis than it normally would get, given its modest contribution to the overall business at that point. If used properly, matrix management 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. If used too frequently, or without endowing the "head" of the matrix with real power to accomplish the desired goals, matrix organizations can quickly become ineffective and politically driven entities--and 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 organize a software or technology company for success--too many to discuss here. And we just touched on a few of the issues to consider. Hopefully this short article will stimulate some thinking on this topic, to avoid organizational structure which often form haphazardly as companies are started and grown. Post a comment if you have a take of your own.

Phil Morettini

PJM Consulting

www.pjmconsult.com

Strategic Acquisitions for Software and Technology Companies

Acquiring new products or whole companies is a popular activity for many growth and market-share oriented companies. Is it a good idea?

Well, as I often say--it depends. I get involved in company or product acquisitions quite often in my consulting practice. There is nothing inherently good or bad about acquisitions in the technology business. However, there is nothing inherently bad about opening a restaurant, either. Nonetheless, a very high percentage of restaurants (I've seen figures as high as 90%) fail within 5 years. The failure rate for acquisitions may not be quite as high as for restaurant startups, but technology acquisitions are also judged to be failures at shockingly high rates. Caution should rule when approaching either of these very popular activities. As I'm fond of saying about success or failure in any complex business activity--the devil's in the details.

Common Motivations for Acquisition Activity

Let's examine the common reasons that acquisitions are considered in the first place:

1) It's exhilarating and "sexy" to buy another company
2) Growth for growth's sake (often pushed by investors)
3) The belief that buying a competitor is the ultimate "victory"
4) A consolidating market (often commoditizing) where there is only room for a few large players
5) Diversification
6) A great strategic fit where 1+1 truly equals 3

As you might have guessed, reasons 1-3 above aren't great justifications for such a risky activity. Number 4 can be a good justification, but often this is given as the rationale, when the actual market case doesn't truly support it. Number 5 can be a good or bad rationale, depending upon whether the business case really calls for diversification--or if focus would make more sense. Number 6 is by far the best reason to acquire a company, particularly if you aren't an industry giant, pitted in a death match with another titan of your marketplace.

So let's say you've actually thought it through, and have used sound analysis and judgment in deciding to pursue an acquisition. Congratulations for passing the first test--but there are still myriad things that can trip you up, on the way to acquisition success:

Great Ways to Fail

First acquisition done "on your own"--I strongly urge all first time acquirers, whether of the product or company variety, to seek assistance. Acquiring a company and even a product is very complex, with a lot of places to trip up. Retaining an experienced hand that has seen and gone through the mistakes before, can prevent you from the most expensive education of your life.
Bad cultural fit--In the excitement of an acquisition or a merger, people have a tendency to not look past the surface. It's much like dating an attractive potential mate, and proposing based upon infatuation, without establishing whether there is common ground in the way you live your lives. This is the business equivalent of marriage, folks. Compatibility in business philosophies and practices is crucial--and often overlooked, until after the fact, when everything is unraveling.
Poor organizational integration-- Even with an excellent evaluation of potential partners, a great many mergers fail based on the execution of integrating the organizations. That's because it is HARD. You are generally merging two organizations with disparate operating styles, as well as overlapping functions and people. Fear, uncertainty and doubt of the individuals involved can by ITSELF scuttle a potentially great fit. This area is often quoted as the reason most acquisitions fail.
Poor product integration--This is the reason a lot of acquisitions in software and high tech should be called off early in the process. It is often very difficult to rationalize how you are going to support two different code bases or technologies, aimed at the same market. The plan usually call for integrating them over time, but that often proves to be very difficult from a technical perspective. This is a real red flag when buying a direct competitor. Yet the price of the merger in high tech often assumes that the products can be integrated acceptably, without losing customers from either of the existing products. Unfortunately this is usually a very tall order
Paying too much--Price plays a big role in software and technology acquisitions. Due to high growth rates and the perceived need to move quickly in fast-growing, competitive technology markets, acquisitions are often priced in multiples of revenue. This is in contrast to the more conservative multiples of EBITDA in other less dynamic industries. Often the target isn't even profitable yet, but still commands a high price-to-revenue multiple, due to the "hot" nature of the market space, and perceived value of the acquired technology. This high price puts a severe strain on downstream execution of the merger to be "perfect", as discussed above.

So with all of the landmines out there in the acquisition arena, along with the high failure rate, is it simply nuts to consider acquisitions? Doesn't it make sense to just stay away from them? NOT NECESSARILY.

Sound Approaches to Pursuing Mergers

Buying innovation--This often happens when companies reach a certain size; they simply lose their ability to innovate. Rather than innovate internally, they do so by acquiring small companies with market-changing technologies, which may not have the resources to fully exploit in the marketplace on their own. Even though multiples here tend to be high, risk is somewhat mitigated relative to internal Research and Development that might not "pan out", and the size of the acquisition is often very modest, relative to the resources of the acquirer. This is an example of a true 1+1=3 strategic fit. This strategy has been used with great success by Cisco, Microsoft, and many other large companies with successful acquisition programs.
Buying companies or products that truly fill a hole in your offering--While some companies tend to overuse this as justification, acquisition of a reasonably priced company or product at just the right time, can mean the difference between continued growth or inevitable stagnation.
Buying undervalued assets--This is harder to do in high tech than in other industries; high tech companies have a habit of overvaluing their businesses and technologies. But an executive team with a key eye for a bargain can often pick up a diamond in the rough, for example a division that has suffered because it isn't a good fit with the parent company's core business
Truly appropriate diversification--Sometime you run out of steam in your current market, and the amount of cash flow generated by your current business dictates that an investment in another growth area may be prudent. The key here is to pick a market segment adjacent to the existing business, or at least a business that the management team can easily adjust too. However, management teams often are over-confident and deceive themselves, and end up investing in an area where they really don't belong.


I could go on and talk more about acquisitions for a very long time. But instead of putting you all to sleep, let's begin a dialogue on this topic. Inform us of your own Merger and Acquisition stories, best practices, and cautionary tales.

Phil Morettini
PJM Consulting
http://www.pjmconsult.com/

Open Source Software Business Models

Open Source has been gaining ground for quite some time. Some would say, using the example of Linux, that Open Source has Microsoft and the rest of the traditional software giants on the run. No doubt that open source software has had a major impact on the economics of the software business, across many different market segments.

But is it a good model to use in your software business--if you are actually interested in making money?

Not Generally My Cup of Tea--But Let's Take Another Look

I will admit that my feelings toward open source business models have always been lukewarm, at best. Maybe there's a bit of dinosaur in me. But the idea of putting into the public domain the code that you've sweated to produce, at great emotional and financial expense rubs me the wrong way. It trikes me as fundamentally opposed to the basic nature of capitalism and the entrepreneur.

Like just about everything else in business, however--the devil's in the details. Using Open Source methods has been shown a number of times that it can be a competitive weapon in the software business--when used thoughtfully and strategically.

Poor Use of Open Source

Let's first examine a typical example of what I consider a misuse of the Open Source model. It often goes like this: Technical founder with a crack programming team, and little marketing money or expertise, decides that they are going to use Open Source to inexpensively roll out their new product in the market. Being programmers, they love the idea of Open Source from a user perspective, and so have a strong belief that the market they are aiming at will love it as well. Unfortunately, they aren't trained as marketers, and don't think the situation completely through.

Here are some of the negative things that can happen:

1) Since the company is releasing the initial product as Open Source, they are not quite as diligent as possible with QA of the code, as well as other "commercial product" polishing activities. Basically the product is rushed to market. The product isn't well-received, costing them the one opportunity that you have, to make a good first impression

2) Open Source tactics are used prior to developing a proven business model: "We'll release a free, Open Source product, and have so many users, we can figure out how to make money later". This is reminiscent of the old "eyeballs" business plans prevalent just before the Internet bubble burst in 2001. It's very important to have a solid idea of what the Open Source release is going to gain you, and what the steps are that will to allow you to capitalize on the wide attention. Ultimately, you need to monetize SOMETHING. There are ways to make money with an Open Source model: customization, training, training, premium versions--but in many instances, these won't really support a serious, mainstream core software development effort--if you are also interested in profits.

3) The company has done some thinking about the business model issue, and has decided that there will be a free, Open Source version released initially to seed the market. The follow on product will be commercial/paid with added features, with the hope that the large user base from the free version will upgrade to the more attractive premium version. But without expert marketing analysis, balancing how much to "give away" in the free version, and how much to "hold back" for the premium version, can be quite tricky. If you don't get the balance right, the potential revenue stream can be greatly reduced.

4) The company is in a market segment that highly values order and traditional business practices--in this circumstance, using an Open Source model could seriously devalue your product, in the eyes of your target prospects.


Good Use of Open Source

The other side of this story is that when implemented thoughtfully, Open Source can be a major strategic weapon in certain markets. Let's look at some scenarios of how an Open Source strategy might be implemented more shrewdly:

A) When entering a new market against a huge, strongly entrenched (but slow and stodgy) competitor, where it will be difficult to get traction with traditional marketing methods. This is Open Source used as a Guerilla tactic.

B) In markets where the availability of Source Code REALLY IS IMPORTANT. This may be for reasons of integration, or for reasons of business continuity (for example, a bank application) where they would require source escrow anyway.

C) Having a free Open Source version for one type of small volume customer (internal developments), but to redistribute the code for commercial purposes, there is a royalty/fee. This is using the Open Source model only partially. MySQL has used this model very successfully for quite a while.

D) Formulating a well thought out, hybrid business model ahead of time. For example, a free Open Source version is made available to seed the market. Backed by extensive research and marketing planning, a paid premium version is made available, with just the right features at just the right price, creating huge upgrade numbers with minimal marketing expense.

E) An Open Source product is created for a particular market segment, with data backed by research that this segment will require and pay for substantial levels of integration, customization and/or support.

Summary

That's my view of the good and bad in Open Source as part of a commercial business model. Used well, it can be a major weapon--when the situation calls for it. But if used blindly by companies just following a trend toward the newest thing--it can be the "Business Model of No Return".

Drop me a note or post a comment with what you think.

Phil Morettini
PJM Consulting
http://www.pjmconsult.com/
info@pjmconsult.com