Carlos Leyva

Silicon Stories

Chapter 2: Competitive Advantage

Commercial Software vs. In House Development

« PreviousContentsNext »

I will use the example from the auto industry to help illustrate a subtle, but important, distinction between software development in commercial organizations, whose final product is not software (e.g. Ford Motor Company), and software development in the commercial software industry (e.g. Microsoft). Both use similar tools, methodologies, and human capital during the software development process; however, the organizational structures that drive the process are quite different.

IT departments tend to view their market as the internal customer organization (marketing, engineering, HR, etc.). It is a myopic view that tends to severely constrain potential solutions. A broader, more holistic, cross organizational worldview is required for efforts that are intended to create competitive advantage. Corporations have now entered the creativity business in a big way (yet most don’t know it), and they must realize quickly that you can’t get the genie back in the bottle (i.e. this is not your daddy’s Ford Motor Company). There must be a willingness to experiment with some of this fuzzy logic if progress is to be made.

Companies that produce commercial software on a large scale are usually organized in a manner that mandates, and facilitates, communication between senior management, marketing, program management, development, and R&D in order to achieve specific results in the marketplace. This communication, although not always optimal (depending on the set of players), is built into the process.

The communications process for non-commercial software companies (as it relates to software development) tends to be ill defined. It also tends to be slower and less rigorous, negatively impacting both time-to-market and quality. There are a number of historical reasons for this, including the scarcity of institutional memory, as it relates to software development. The chapter entitled Movie Making and Software Development includes a description of an organizational model that attempts to address these deficiencies.

Microsoft Goes to War

What would Microsoft do if they considered exploiting the new car delivery process for competitive advantage? Well, I can’t say for sure, obviously, but I can surmise a damn good guess. First of all, their best and brightest would study the problem to determine if the resulting advantage would be compelling. The probability is quite high that they would crack the code and determine that the problem is a human communications problem as much as a technology problem. They would then weigh this advantage vis-à-vis their current portfolio of competition killer projects to determine relative importance to the organization. If, after this process, this project were at (or near) the top of the list, they would declare war; arm their best soldiers; pull together a top gun, cross-functional team; appoint a field general; and get after it with a vengeance!

A technology plan would be developed that included, at a minimum, what should be contained in the next couple of releases. All of this reduction in DIP activity would happen in an incredibly short period of time. No amount of resources would be spared until the goal was achieved. Top management would be all over the team’s ass to produce. Why? Because they are at war! Most corporations are totally incapable of this type of mobilization.

The discussion of concepts such as the DIP, chaos, and the 2nd Law is not meant to undermine the importance of strategic thinking and raw technology. Both remain incredibly important. However, the message from this chapter is that while these are necessary, they are not sufficient. Corporations will only be able to sustain a competitive advantage by applying these amorphous ideas (e.g. reducing the DIP)—in conjunction with strategic thinking and enabling technologies—to a set of activities within the value chain in order to produce the desired results.

Hopefully, the upcoming Process Patterns discussion will help to clarify the fuzziness. Top decision makers can no longer abdicate responsibility for technology decisions solely to the technology people. Technology is so tightly interwoven with the set of activities that you are attempting to impact that it is difficult to separate the two. Learn to pay attention, or risk funding one disaster after another. An often-quoted definition of insanity is to “continue to do the same things over and over and expect different results.” Allow me to translate this into Leyva speak for you:

If you continue to use the same fucked-up processes, you will continue to achieve the same fucked-up results.

One additional point of clarification: corporations need not transform themselves into Microsoft in order to derive competitive advantage from applied information technologies. The capability to produce insanely great software is not required. The creation of damn good software, in conjunction with things that you currently do well, is all that is required. In fact, the resulting work product will be, more often than not, a system (as defined in Chapter 1) that produces great results, as opposed to a product.

That said, the organizational model that is required to produce software-based intellectual capital does not have to possess all of the same characteristics that are found in successful commercial software organizations. However, there is much to be learned from seriously studying the best practices that have emerged from this industry. Keep in mind that you don’t have to be the fastest, or the first; you just have to learn to out run the competition.

The ability to learn faster than your competition may be the only sustainable competitive advantage.

—Arie de Geus

(when head of planning at Royal Dutch Shell)

« PreviousContentsNext »