The challenges it had to face: Microsoft

In one of his books, Harvard Business School professor Clayton Christensen argues that a company strengths and weaknesses of a company mainly come from by the challenges its had to face. It will build skills and processes to cope with these challenges, but at the same time those same skills and processes might prevent it from dealing effectively with other types of challenges.

Given this, let's analyze a few companies, starting today with Microsoft.

Microsoft has always striven to sell software which is central to computers: Microsoft Basic, MS-DOS, Windows, etc. It's interesting to notice that the development has taken various forms. From building in-house, buying a product and renaming it (MS-DOS was purchased from a small Seattle software company), or a mix of both (Microsoft lured out of Digital a whole operating system development team led by Dave Cutler, the man who designed the VMS mainframe operating system).

But the challenge has been more from an organizational and product management standpoint. Indeed, since its very first program (Microsoft Basic), the company had to deal with numerous vendors as its software needs to work on a wide variety of hardware systems. Today, for any new release of Windows, Microsoft needs to interact with thousands of partners from all over the world. PC manufacturers need to have Windows preinstalled on their systems. Hardware and peripheral vendors want to release their device drivers on time, ideally shipped with that new version of Windows. Software editors want their applications to work smoothly on the new operating system. And millions of developers might be interested in taking advantage of the new features.

In order to cope with this challenge, Microsoft had to come up with several partnership programs. An OEM program allowing PC manufacturers to preinstall Windows on the computers they sell. The Microsoft Developer Network (MSDN), the Microsoft Certified System Engineer program (MCSE), various business partnership programs with other software companies, etc.

On the technical side, Microsoft had also to come up with several public programming interface to make sure 3rd party products know how to interact with Windows. The Windows API (Application Programming Interface) allows software companies and developers to know how to code applications on Windows. On the other end, the Windows HAL layer (Hardware Abstraction Layer) isolates the bulk of the Windows code from hardware, making it easier for Windows to support a wide variety of devices and peripherals.

As we see, Microsoft heavily relies on partners. But it knows all too well that today's partner can become tomorrow's enemy. After all, Microsoft was once IBM's partner for its Personal Computer and used that position to steal the control of the PC market. As Redmond doesn't want it to happen again, one of its problems has been to find a way to control its partners and make sure it gets the lion's share of the profits in the whole value chain.

This last goal is actually conflicting with the goal of working with partners. Indeed, providing an interface to work with its products is a necessity for Microsoft. But at the same time, a public interface can evolve into a standards that can escape from the control of its creator, just like IBM lost control over the interfaces defining its PC. The solution has been to provide a constantly evolving complex and rich set of interfaces. Windows programming has never been simple and will never be. For instance, even though Microsoft programming platform .NET is built on top of ActiveX technology, the knowledge required to develop ActiveX applications from 10 years ago is merely useless to develop a .NET application today. By contrast, a lot of the HTML or Java knowledge from 10 years ago is still valid today. In order to be up-to-date, developers need to keep learning constant changes. An application which is using the Windows API cannot be easily ported to another operating system. And even patents set aside, Linux or MacOS X can hardly replicate Windows' huge API set and thus make sure they will smoothly run Windows applications through emulation.

The other problem Microsoft is facing is the constant risk to see its two main cash cows (Windows and Office) become commodities. The best way to avoid that is to keep releasing new versions and adding new features to convince people to upgrade. This is why Microsoft products tend to consume more and more resources after each release, as Redmond keeps cramming new features in a hope to keep them sexy.


An outcome is that Microsoft has learnt to successfully manage large projects involving large teams and a lot of partners. Some might argue that all Windows releases have experienced significant deadlines and are full of technical glitches, but the company has done good enough a job to conquer multiple markets. And as far as partnership goes, Redmond has been extremely successful at gathering a lot of partners while keeping them under a tight leash.

Now, these skills can also be liabilities for Microsoft. In theory, its current business relationships would seem like a liability when trying to conquer a new market. Who wants to deal with Microsoft when you don't have to? But apparently Redmond has been very good at courting partners even in new markets.

The biggest liability is regarding its products. For instance, complexity is the name of the game at Microsoft. The company just cannot provide a simple product. It could have never come up with Google's simple front page. There needs to be a next version that will have more bells and whistles. Microsoft is thus prone to overshoot its customers, leaving the door open for new entrants who sell disruptive products. Also, a "big project" approach is less suited to the Internet where users are more used to the "release early, release often" model.