Thursday, February 21, 2013

Attack, Defend and the Dark Arts

First of all, clear your mind of the notion of there is any such thing as the “one strategy”. Instead a strategy consists of multiple parts in a game of chess between companies. You manipulate the entire map to create an advantage and you may act in entirely opposite ways on different parts of the map e.g. you may use an open technology approach on one part of the map whilst simultaneously using a closed approach on another.

Many of the techniques we’ve already covered in this series, for example: -

Shared components
The exercise of mapping should provide you with a list of shared components. These should be treated as such. Obviously you need to consider single points of weakness and systemic failure along with whether you can buy in external services but equally you can look at providing these common components as services yourself (an opportunity). What you want to avoid is duplication of effort and waste.

Efficiency reforms & rationalization
The exercise of mapping should hopefully have highlighted some deltas in how groups treat activities. These are opportunities for efficiency gains i.e. questioning why we need to customize oue operating system? Detailed investigation may also provide areas of wasted effort i.e. things which aren’t used. It’s always surprising how much of the legacy estate does nothing but continues to be maintained. Lastly once you have maps you should be seriously asking why any late product stage or commodity components aren’t provided either through open source or utility provision.

Driving a system to a more evolved state though an open approach
There are numerous reasons for using an open technology approach but the basic principle of driving an activity to a more evolved state, enabling greater efficiency and feature completeness should always be considered.

“Platforms for Innovation” and exploiting ecosystems through ILC
Any activity or data you consume or generate (whether currently considered core or not) has the potential to become a platform for innovation and an ecosystem grown around it. Building ecosystems around components is a great tool for increasing efficiency, innovation (as in genesis of novel and new) and improving customer focus.

Reducing barriers to entry
Equally open approaches can be used to reduce barriers to entry into opponents’ value chains. When you’re competing with someone, never hesitate to give your opponents an additional headache.

Land Grab
Sometimes you can see an activity is evolving and you haven’t quite worked out how to exploit it yet. Land grabbing the future buys you a lot of time. Take Ubuntu vs RedHat, on the server market that was an uphill struggle but Ubuntu walked in and took over the cloud space with relative ease. Even today, Ubuntu is still the dominant operating system used on Amazon and other equivalent clouds as well as being entrenched in platform projects like CloudFoundry and open source efforts such as OpenStack.

Creating a centre of gravity
Open approaches (whether source or APIs) are excellent means of creating ecosystems through which a centre of gravity around a topic can be built and maintained. If you’re at the heart of this, these are excellent sources of recruitment. As a small London based company, I successfully used the Perl Community to recruit some of the best and brightest. Never miss this opportunity, as talent is rare.

Exploiting constraints
If you’re up against another company, look for constraints e.g. the example of Hardware Vendors vs Amazon. If you can find a constraint then exploit it without mercy, as these are often time-limited opportunities.

Creating constraints
When an opponent doesn’t have a constraint, you can always create one for them by buying up key parts of their value chain (i.e. the suppliers). Fairly risky, capital intensive and obviously suffers from stimulating demand in the component you’ve just attacked (which means new entrants).

Building value not wasting it.
Look at your components and ask can I turn this into value if it isn’t already? A good place to examine is those more commodity components (which can be turned into utility services) or your data assets and in particular if the data is unique (like purchasing behaviours) whether this is true for aggregated data can an open data approach be useful?

Changing the characteristics of a component
A tricky game to play as you’re looking for a way to change the value chain associated with a specific component. This sort of technique can be used against an entrenched large player, you’re aiming to develop in an alternative market, get big before they react and then hopefully move into their market. This game depends upon exploiting your opponent’s inertia to change.

Slowing down evolution
A dark art that involves either the use of intellectual property to prevent competition or lobbying of Governments to create protective barriers for your value chain. 

Misdirection
One of my favourites and one I’ve used a variant successfully in the past. Suppose you’re under attack from a new entrant and are not prepared then you can buy yourself some time by encouraging them to focus on the wrong thing. With start-ups, the best way is to fund them to do something that absorbs engineering talent and is completely useless. They often jump at the chance of a paycheck from a well-known company name and lose sight of the prize.

Hence, if you’re a management product vendor and a start-up builds a utility management service then fund them to build a version that integrates with your product. Even better, if their utility service is planned to be open source, make sure the integration version isn’t. Whilst they are focusing on building the integrated system and sending confusing messages over licensing to the market then use this time to build and then launch your own utility services.

Your actual strategy may include many if not all the techniques described (and this is not an exhaustive list). However, there are some specific techniques I’d like to look at in more detail using a play vs counter format.

Play: Differentiation
A typical play is differentiation; as in create a functional difference between your offering and those of competitors. This is not about being more operationally efficient but provision of something that most of your competitors don’t have. When looking at the top-level components that serve the needs of the consumer, you’re looking for something novel and new which can be bundled into the offering (either tightly or more advantageously loosely coupled). The mapping exercise may have already given you several of these unmet needs. This sort of play depends upon your ability to experiment, to gamble and to guess right. It’s highly risky due to the chaotic nature of the novel and new.

Counter: Ecosystem
A good way to counter a differentiation play is not to face it head on as this pits your company’s ability directly against the competitors. If they’ve got more talented people or they’re just plain luckier than you then it’s a battle you can lose. A better approach is to build an ecosystem of company’s and individuals (an alliance) to compete against the company with sharing and collaboration between them. This necessitates the use of an open technology approach, for example open source or alternatively provision of an API (all APIs being open) for a common component and the use of a model such as ILC.

Counter: Tower and Moat
Rather than attempting to compete directly on differentiation, you can aim to eliminate any value in differentiation. For example let’s imagine you’re the CEO at Salesforce, a company that provides a more commodity form of CRM. When a competitor (in the product space) attempts to differentiate you can simply acquire an equivalent function and provide it freely as part of your core offering. The purpose of this is that you aim to make revenue through your core offering (e.g. CRM) and then eliminate any differential value competitors might gain through additional activities (social CRM, chatter, analytics etc).

The core revenue is your Tower with the void of differential value around it is your Moat. This approach is particularly useful if you occupy the future battleground i.e. you’re the commodity player vs the incumbent product players. By growing your business and eliminating any differential value in the space, when your competitors eventually realize they have to switch it becomes almost impossible for them to compete with you.

Play: Standardize
A typical play is to attempt to standardize an activity around your offering. The principle reasons tend to be that your competitors will incur a cost of transition to the standard and / or you’re aiming to create a competitive market and exploit opportunities such as exchanges, assurance or brokerages. Open technology plays can be a powerful tool in making this happen.

Counter
The route by which you may counter depends upon relative positions of each player, consumer vs supplier power and which ecosystem governs the evolution of this activity. 

For example, if the dominant public defacto plays a standard game then you need to either rapidly adopt it or build a larger alliance against it or attempt to use standard bodies / legislative barriers to prevent it. Equally, if the activity is mainly governed in the Enterprise ecosystem you can look to pushing this towards the more public consumer ecosystem (and exploit consumerization effects).

If the player initiating the path is smaller and less established, you can immediately counter with your own standards effort and directly engage in a battle over standards. This will require overcoming some internal inertia due to past success. If you’re the dominant and have the supplier power then you can often ignore such standard efforts.

Play: Creating a level playing field
Let us suppose your value chain consumes an activity that is provided by a captured market (i.e. it’s is constrained to a few suppliers). You maybe locked-in to a particular approach and wish to disentangle yourself in order to find more efficient ways of consuming the activity particularly if the activity is really a commodity but you’re consuming a high cost product. 

The ability to play this game depends very much on your consumer power in relation to suppliers and normally requires multiple lines of attack. If your consumer power is weak then you’ll need to form alliances.

Let us assume you’re a large consumer with strong power i.e. you’re a Government agency such as the Department of Veteran’s Affairs purchasing electronic healthcare record systems. Your primary goals are to create pressure on the suppliers and open up the market, hence you can: -
  • Change purchasing policies. When renewing, a cost of exit is calculated and added to the system being offered. Hence if you have some form of proprietary database and the renewal is $100M and the cost of transition to another systems is $150M, the then the renewal quote is considered as $250M. If an alternative more open system would cost $120M but the cost of exit from it (due to use of open standards) is $40M then its quote is considered as $160M. The purpose of this approach is to drive pressure onto the suppliers to enable switching. This is counter to the normal way of operating when the cost of exiting a system is added to the system that you’re moving to and hence encourages incumbents to increasingly raise exit costs.
  • Adopt open standards. Making a clear preferential for more open standards (i.e. Royalty Free) is a blunt tool but especially effective when combined with changing purchasing policies.
  • Make the system open source. This can have two roles, one in part as leverage against the suppliers, the second is to encourage new entrants into the market especially future providers of utility services that are unlikely to come from incumbent providers due to inertia they suffer.
  • Componentization and strong coupling. Often elements of a system will be commodity whilst some activities are genuine differentials e.g. even Electronic Health Care record systems will contain novel components. You should aim to break the system into components with defined interfaces being careful to avoid strong coupling. Example of strong coupling can be found in most desktop rollouts where components such as the device to operating system are all commodity but a line of business application has strong links to a specific operating system forcing you to treat it as a product. You should aim to break these links i.e. applications are delivered through neutral browser interfaces where possible.
Counter: Creating a level playing field
The best long-term approach is to adapt to the environment and look towards operationally efficient provision of more open systems. In particular, by adopting this model you can aggressively look to provide utility services (where applicable) and re-use these for other markets. However, this does require overcoming significant internal inertia which will often been couched in terms such as “cannibalization of existing business”

If you decide not to adapt then against a determined opponent this is difficult to counter because you’re trying to persuade them that living in a gilded cage is better than no cage. Much of this has to be achieved through lobbying and weakening the effort through fear, uncertainty and doubt. Again a multiple line attack is required :-
  • Attack the purchasing policy changes. It’s critical to emphasize that change in policy will incur additional cost as decisions to move towards more open and interoperable environments will incur the cost of exit.
  • Reduce pricing. Often allies can be found within the company that is executing this play particularly those people who benefit from having an association with your company. Provide them the means to counter the effort by reducing pricing and showing more efficient provision.
  • Bundling. The breaking of a system into components is particularly dangerous as it allows new entrants that may erode your market. Provide favourable terms for bundling.
  • Confusion. One of my favourite dark arts is to exploit the confusion of choice. In this case, you would emphasize the management overhead of dealing with different components and suppliers, ask who would test the components, offer your own system interfaces as being the “open standards” and play on the company’s own inertia (concerns over skill set changes, disruption of existing practices etc).
The overall goal is to create enough uncertainty and doubt that a gilded cage looks like the better option especially when combined with price reductions.

Play: Sweat and Dump
This play is used when you have something of value that you know will diminish and hence need to get rid of the costs associated with it.  

For example, lets suppose you’re the CEO of EMC and you’ve seen how VMware (a subsidiary) has grown however you suspect that as infrastructure gets commoditized further towards utility services then proprietary software plays are going to have a tough time. You can’t open source the technology because of the write offs involved. One way to play the game is to continue with it as is, milk it as much as possible whilst building a new line of business further up the value chain (e.g. platform, management line). 

If you can exploit the market (e.g. the current enterprise demands for private clouds) then you can spin out the future business (e.g. Pivotal initiative) with a view of getting the past existing business (hypervisor) either acquired by another or floated on the market. Such a move is always tricky because timing and messaging needs to be perfect as you have to convince the market that you’re letting go of the business because of some conflict or other reason and not because you think it’s a future dead duck. Leo Apotheker had a good strategy for HP but the messaging was awful.

The icing on the cake, is when you can re-invest the capital into what was disrupting you in the first place e.g. EMC making a huge utility computing play.

Sweat and dump is also a way of dealing with legacy estates. If you suspect that financial ERP will become a utility (many large companies are looking to provide such services) then what do you do with your legacy? Well, first keep investment minimal and look to minimize future commitments whilst you plan to move. Enterprise clouds for example provide a way of doing this. Rather than re-architect for utility services based upon commodity components, find someone willing to provide you with utility services for non-commodity, high-end server infrastructure. Get someone else to load up the capital-intensive infrastructure costs (and ideally utility based application licensing) whilst you plot your move to a modern SaaS environment. 

Counter
Don't get caught out by it.

Your Strategy
Once you’ve looked at the opportunities, the “where” to attacks, you can then start making trade-offs and choices. Your strategy is the result of this. 

You might decide to drive some components of the map to a more evolved state in order to increase efficiency whilst using an open approach to undermine a competitor’s barrier to entry and simultaneously building an ecosystem around a new utility service from a commodity component in order to generate future revenue streams whilst misdirecting a start-up. You might combine this with sweating and dumping a legacy estate through an enterprise cloud and creating a level playing field around another. The point is your strategy will have many different parts but each part you should be able to articulate precisely why you’re doing it.

After this it’s all how (open source XYZ, use marketing to help establish a community), what (hire a team of software engineers, hire a community manager, launch a community event, create a public repository) and when.

Oh, and if you're assuming that no-one thinks like this, well, I’m afraid they do. This is what strategy is all about. It’s not about bland statements of becoming more innovative or more efficient or being nimble (thank you Dilbert). It’s about playing the game.

---

Post 23 on the Management and Strategy series.

Next post in series ... On Structure

Previous post in series ... The Strategy Game

Beginning of the Management and Strategy series ... There must be some way out of here