War Stories & AnecdotesGrowth & Expansion Strategies
Leading from Behind
|
|
Sometimes when we work with a client, success in one case leads to a new engagement on the same issue. For example, once we looked at a 10-year labor relations plan with GM. After the landscape over this 10-year horizon was well understood, a second case looked at the 3-year window. When that view was clear, we addressed in a third case the current UAW National Agreement contract negotiations. In another situation, the client brought us back 9 times to look at various facets of the same issue. And very commonly, success with a case in one market will lead to us looking at the same issue for the client in a different market.
But perhaps one of the most interesting sequence of cases we have done was working with IBM on their Linux strategy. Starting in 2001 and closing out in 2004, we performed a sequence of five cases tracking the fast-changing Linux marketplace and guided IBM on choosing its best actions at each point in time. It is quite unusual for us to be able to talk publicly about our work with companies like IBM. Usually the work we do is secret and never sees the light of day. But in 2007 IBM was kind enough to go public about our involvement, in an article in the Toronto Globe and Mail newspaper's monthly Report on Business magazine.
Our main business contact at IBM was Joel Cawley, vice president of corporate strategy, who was interviewed for the article. Joel revealed a lot about our projects with IBM that we would never have otherwise been able to talk about. He also said a lot of nice things about Open Options. I would not have been able to write this chapter if Joel had not been so forthcoming.
"There were a lot of different interests at stake," said Joel [in the Report on Business article, about the Linux issue] "To figure out where and how it's likely to evolve, you need to look at the interaction of a whole bunch of different players and their respective interests—and if those interests diverge or converge, it really does get unwieldy, so you can't trust simple intuition."
"What you don't realize [in many decisions] is how much time gets spent on debate that at the end of the day doesn't end up mattering that much," Cawley said. "If you can narrow the debate down to the handful of things that really matter, you can dramatically speed up decision time. With the Open Options guys, we've gotten to the point where we can assemble a team and, in the course of three or four days, gather the data for the workshops, feed it in, and within a couple of weeks have good outputs and good answers and good insights."
So with that as an introduction, let’s look at what happened in the set of cases we did for IBM on their Linux strategy.
Open Options started working with IBM in October, 2001, shortly after 9/11. Their global head office is in New York State, set in the woods just north of the Westchester County airport, a commuter train ride from Manhattan Island. The fall of the Twin Towers was still very much on everybody's mind - around the world, but especially anywhere near New York City. But life and business must go on, so the sadness of 9/11 permeated our thoughts but did not impinge our work.
We were there to look at how IBM should deal with the growth of the Linux operating system. Linux had been around for a while, but had in recent years shown the potential to grow from an arcane tool for geeks to an operating system that could conceivably rival Microsoft Windows. To understand why this was important to IBM, we need to go back a few years, to IBM's heyday.
The rise of the personal computer was a big challenge to IBM. It could, and did, displace the IBM mainframe, but that was not so clear an outcome at first. IBM was smart enough not to ignore the threat, and challenged it directly by developing the IBM PC. It was a dominating technology, and has set the pattern for today's PC's. So on that score their strategy was very successful. But at the same time it was a failure. IBM used an open architecture, meaning that anybody could supply any part for the computer. This motivated suppliers of hardware and software to move to the IBM standard, generating wide acceptance. But it also allowed other manufacturers to produce the same product more cheaply. The IBM brand was not strong enough to prevent commoditization of the PC, and the market was effectively lost to them.
There were two elements of the IBM PC standard that IBM discarded to its eternal regret. One was the processor chip, which Intel provided. Intel of course went on to become one of the largest companies in the IT industry. The second key element that IBM lost control of was the operating system, DOS, which was owned by a small company (at the time) called Microsoft. The loss of the processor to Intel seems to have been accepted with grace by IBM, but Microsoft's domination of the operating system seems to have been an enduring thorn in IBM's side ever since.
When we started working with IBM in 2001, the extreme nature of this antipathy toward Microsoft became very apparent. For one thing, nobody in IBM was using Microsoft Office software. They may have been using Windows, lacking an alternative, but they certainly did not use Word, Excel or PowerPoint, all of course the standards in business. It was a terrible inconvenience, since the only way we could share files with them was to translate from the standard Microsoft files into the Lotus applications that they were using and vice-versa. It was a burden that they would have to share with any outsider, not just with us. Luckily we were using IBM laptops rather than a competitor's, and Targus mice rather than Microsoft mice.
But an even more difficult situation came up as we were building our first model on the Linux situation. One of the players that was identified, as you might expect, was Microsoft. Certainly, as Linux would develop, Microsoft would have a strong interest since Linux could potentially replace Windows. When Microsoft first came up as a player, there was clearly major discomfort in the room. Eventually it came out that they would prefer it if the model did not include Microsoft at all. It was explained that Microsoft was a taboo topic at IBM, and it would go against corporate culture for it to be explicitly considered.
Of course after reflection the decision team realized that they could not deal with the real marketplace effectively if they pretended Microsoft didn't exist, and so it remained in the model. I like to think that we had some influence in correcting their behavior more broadly, too. Although administering our first case with them was fraught with problems because of their insistence on not using Microsoft software, by our second or third case the problem disappeared as they shifted over to Microsoft. After only a year or two the whole Microsoft elephant seemed to have left the room, or at least was mingling freely with the guests.
The first case we did was typical in many ways - 21 options and 9 players. Aside from the fuss over Microsoft, rest of the model was quite sensible, and like other clients the IBM team found a lot of value sorting out who was important and what key actions could each of the players take. It turned out to be easy for the group to coalesce around a common view of the players' interests, but at the same time there was uncommon anxiety about whether the team had judged things properly. This anxiety probably had a lot to do with the fact that this was a fast-changing market involving players new to IBM's strategic considerations.
The main focus of the results of the model analysis had to do with the need for standardization. At the time there were many competing versions of Linux, depending on what functions were being promoted by whom. As an open source product, anybody could change anything at any time, and several different versions had strong commercial promoters. The importance of Microsoft was also realized for its ability to either inhibit Linux or even potentially embrace it.
Our second Linux case with IBM happened only about six weeks later. The general idea was to take the insights from the first case and do a "deeper dive", gleaning new gems from a more focused view of the issue. The decision team had built up their background knowledge of the issue and had a better understanding of what sort of questions they wanted answered.
The model that resulted in this second pass at the Linux issue stands as the largest model we have ever constructed. There were ten players and 36 options in total - almost twice as large as a typical model. This is not a good model, but at the time we did not have enough experience to understand all of the liabilities of proceeding with such a model. We had only recently been computationally able to analyze such a large model, so we were actually interested to see what would happen if we pushed the envelope.
One of the liabilities associated with a large model like that is the fact that the decision team has to rank order the 36 options for each player to form that player's preference tree. Intuition might suggest that it would take about twice as long to sort 36 options as it does to sort 18, but it doesn't work that way. The relationship is not linear, but exponential, so that it takes about four times as long to sort 36 options as it does to sort 18. On top of that, there were ten players, each of which needed a preference tree.
Consequently, the decision team and the Open Options facilitators worked many long hours developing the preference trees for this model. I forget how long it took, but I do remember the exhaustion and bad tempers that characterized the last few hours of the session. A good learning experience, as they say.
The decision team ended up exhausted and bad tempered because they put so much time and effort into making sure that the information they put into the model was well thought out. Consequently, they were satisfied that the process had good quality input. It was then left to the Open Options team to analyze the model to see what insights could be found. The analysis did stretch our technology a bit, but in the end it was quite up to the task.
This second Linux case and subsequent ones established the basic principles that guided IBM though its Linux strategy over the following three years. The first of these was that IBM should not lead (hence the "Leading from Behind" title for this chapter). The Linux market was developed by grass-roots programmers with an anti-corporate philosophy. If IBM took an early leadership role, it would be likely to smother the market. IBM should, at that point in time, stand to the side patiently until the market had coalesced onto one or two standards.
The second principle had to do with potential legal action around Linux. As an open-source product, the legal status of the intellectual property encompassed in its code was ambiguous. This ambiguity was a deterrent to the widespread adoption of Linux because large organizations did not want to commit to the use of software that might be unsupportable in the future or require unknown royalty or license fees. At the time, Microsoft was thought to be the most likely source of legal action. The principle that was revealed was that as long as no legal action had occurred, Linux would remain inhibited. However, once legal action had been taken, whatever the result, Linux would be "freed" from this limbo of uncertainty.
These two principles reappeared in our third, fourth and fifth cases with IBM on the Linux issue, as we observed the market change over the next few years. We saw Red Hat emerge as the leading Linux distributor. At one time we advised IBM to buy into Red Hat, which it chose not to do, but I observed the share price of Red Hat quadruple over the year following our recommendation. We saw the appearance and decline of United Linux, and we examined the effect of Sun embracing Linux.
During the three years we followed this market with IBM, things played out very much as predicted, in the principles if not the details. It was the SCO Group - with Microsoft backing - that sued IBM over code SCO claimed was imbedded in Linux, not Microsoft itself, but the effect was much the same. Linux was invigorated by the lawsuit as the uncertainty was dispelled. That IBM sat on the sidelines in the early years also worked well - IBM was able develop a strong branding in the Linux market without threatening its growth. In the end, Linux did not displace Windows in your desktop computer, but is nonetheless a widely used operating system for servers and other applications where speed and reliability are important. And it may yet replace your desktop yet - a non-profit group called One Laptop Per Child (OLPC) intends to distribute potentially millions of laptops to children around the world, all fitted with Linux operating systems.
-----
"There were a lot of different interests at stake [in this issue]. To figure out where and how it's likely to evolve, you need to look at the interaction of a whole bunch of different players and their respective interests--and if those interests diverge or converge. It really does get unwieldy, so you can't trust simple intuition. What you don't realize [in many decisions] is how much time gets spent on debate that at the end of the day doesn't end up mattering that much. If you can narrow the debate down to the handful of things that really matter, you can dramatically speed up decision time. With the Open Options guys, we've gotten to the point where we can assemble a team and, in the course of three or four days, gather the data for the workshops, feed it in, and within a couple of weeks have good outputs and good answers and good insights."
– Joel Cawley, Vice-President of Corporate Strategy at IBM
