In Search of Excellence ... revisited

On the Nov 1st, 1982, Tom Peters and Robert Waterman published "In Search of Excellence". This book has become a cornerstone of management reading.

However, it's based upon case studies of 62 companies and identifying those that are excellent according to a particular framework. It doesn't in my view explain the underlying processes of change and hence I'd argue that it's flawed, fundamentally.

The problem with the work, which is common to many management literature, is that it's based fundamentally on case studies with no underlying model of explanation, no cause, no correlation and no predictive tests. The worst examples of this are those books which run on an assumption that big companies know what they're doing and hence case studies on big companies are some guide to how you should operate. That's fairly delusional given any cursory examination of corporate history.

Despite this, the book has some good themes and I thought it would be interesting to view where these companies have got to in the last 30 yrs, a sort of where are they now?

I'll publish the list on the 1st Nov but I thought I'd start with a draft list, needs lots of checking, confirmation etc. I'll update this post over the months, at the moment it's rough notes.

If someone would like to do an actual study of the "In Search of Excellence 62", set-up a wiki etc - then I'd love to hear about this.

It would probably make a good book and fascinating reading. I'd suggest you publish it on the 1st Nov (hint, hint) and I'd certainly buy it at a reasonable price.

Company	1982	2012	Original
Allen-Bradley	Private	Still in operation as a brand-name for a line of Factory Automation Equipment. Acquired by Rockwell Automation in 1985.	Defunct
Amdahl	Public	Defunct 1997. Bought by Fujitsu	Defunct
Digital Equipment	Public	Defunct 1998. Bought by Compaq who was bought by HP.	Defunct
Emerson Electric	Rank 118	Ranked 120 in the Fortune 500. No change.	Operating
Gould	Private	Acquired in 1988 by Nippon Mining, still in operation.	Operating
Hewlett Packard	Rank 110	Rank 11 in the Fortune 500. Significant Increase.	Operating
IBM	Rank 8	Rank 18 in the Fortune 500. Fall.	Operating
NCR	Public	Acquired by AT&T in 1991. A restructured spin-off in 1996 was given the same name.	Defunct
Rockwell	Rank 48	Divisions sold off in the 1990s and in 2001 Rockwell International was split into two companies, Rockwell Automation and Rockwell Collins ending the run of what had once been a massive and diverse conglomerate. Rockwell Automation ranks at 466, Rockwell Collins at 478. Significant fall.	Operating
Schlumberger	$39.38	Still in operation. NYSE $59.67.	Operating
Texas Instruments	Rank 91	Rank 175 in Fortune 500. Significant Fall.	Operating
United Technologies	Rank 20	Rank 44 in Fortune 500. Fall.	Operating
Western Electric	Public	Split up into several divisions within AT&T with parts being spun off. Defunct in 1995.	Defunct
Westinghouse	Rank 34	Split up into several divisions and sold off with the core of the company renamed to CBS Corporation (Rank 174). Brand name of Westinghouse still continues today. Significant Fall	Operating
Xerox	Rank 42	Rank 121 in the Fortune 500.Significant Fall	Operating
Blue Bell	Public	Acquired by VF Corporation in 1986.	Defunct
Eastman Kodak	Rank 28	Filed for Chapter 11 Bankruptcy in 2012. Significant Fall	Operating
Atari	Rank 483 in 1988	Acquired by Hasbro in 1998. Infogame acquired Hasbro Interactive in 2000. Final assets of Atari acquired in 2008 for $11 million total. Atari suffers from significant financial issues. Significant Fall	Operating

On Competing with APIs

APIs are just a vehicle for creating ecosystems and it's through exploitation of ecosystems (under models such as innovate-leverage-commoditise) that a company can aim to become linear for innovation, customer focus and efficiency with the growth of the ecosystem.

So when competing in an active market on APIs providing similar activities (such as Infrastructure), you really only need to ask yourself - what are the relative sizes of the active developer ecosystems consuming those APIs?

1. If yours is bigger and growing faster relative to competitors … you're winning. If done correctly, you're likely to become even more innovative, customer focused and efficient than your competitors. Whoot!

2. If yours is smaller but growing faster relative to competitors … you should eventually win. It might take you many years and you run the risk of the larger competitor finding that killer API but if things keep on as is, then that's fine.

3. If yours is smaller and growing slower relative to competitors … then copy their APIs. This is especially true if what we're talking about is a commodity (i.e. we're discussing utility services rather than rental services for a product) because attempts to differentiate on a commodity are likely to be futile - you'll probably end up in a niche area.

In the latter case, it's far better to tag along by co-opting the dominant ecosystem with a view of extending it once you have found a way of making your ecosystem dominant. For example, if you're OpenStack then one advantage you can create over Amazon is by creating a competitive market of OpenStack providers. Hence by adopting the dominant EC2/S3/EBS APIs, your focus should be to co-opt the existing ecosystem and offer it an advantage through a marketplace of providers.

Alas, achieving this would mean giving up on ideas about differentiating around a commodity or providing an on-ramp private cloud targeted towards your own public service. It would also require those involved overcoming their own iterative prisoner's dilema where an individual company attempts to differentiate to their own advantage weakening the system as a whole.

Whether OpenStack or Eucalyptus or CloudStack will achieve this and become dominant, well it all depends upon how well they play the game. At this moment in time, it certainly appears as if Amazon is just running away with it.

I said to myself I would never again write another post about bloody APIs. This subject has bored the industry and myself rigid for the last five years. I retired from Cloud over two years ago to get away from this nonsense on differentiating a commodity and ... well nothing surprises me about cloud. The industry will probably still be arguing over this in five years from now. Fortunately at least Eucalyptus and CloudStack understand things clearly, along with Canonical / Ubuntu and Mark Shuttleworth

Also, before anyone says it ... APIs are of course not all that's necessary for semantic interoperability, it's a starting point. Cloning APIs only get you so far but at least it's further than not cloning APIs.

Also, before anyone says it ... won't copying APIs just force providers into a price war and a spiral down to lowest margin. Absolutely and if you're a hardware provider (e.g. Dell, HP, IBM) then that's exactly what you want.

Why? Well if the market continues as is then you're going to find yourself in a strategically weak position with a single large buyer - Amazon. What any hardware vendor should be looking for is a fragmented market. By causing a price war, you'll increase demand and that's good.

Why? Because Amazon appears to run at high margin (if you compare to the best examples of commodity private cloud). Now Amazon is a shrewd player and so you can assume that the reason why they've been dropping prices but not to the extent possible is because they're controlling demand which seems to be growing at somewhere near a whopping 200%. You can therefore assume that Amazon has a bottleneck - I'd hazard a guess at buying land for data centres. So, if you force a rapid growth in demand by causing a price war then you will naturally fragment the market. This is good for the strategic position of hardware suppliers.

Also, before anyone says it ... yes, that will only work if computing infrastructure is highly elastic which the last thirty years of data says it is.

In general when it comes to APIs, I'm secretly hoping that Amazon will open source the technology behind EC2 / S3 / EBS in order to shut up the rest of the industry. I don't expect them to actually do so (for numerous reasons) but it would great for my own benefit if Amazon just ended these tiresome discussions.

STRATAfication of society

First, I'm going to start this post by saying I'm a great fan of the O'Reilly Strata conferences and the surge of interest in data science. Now, I'm going to argue that people really haven't thought through the consequences of this.

Before I begin some background information. 

One of the consequences of the development of utility services in computing is the growth of ecosystem models such as innovate, leverage and commoditise or ILC (see Graph 5). These models appear to allow a company to become linear (possibly super linear) for both customer responsiveness and the innovation of new activities, with respect to ecosystem size. Combined with economies of scale, the effect of this is that those companies which exploit such models will become harder to compete with as their ecosystems grow. Contrary to Porter's three strategies, these companies can become simultaneously more efficient, more innovative and more customer focused with growth.

The trick to this is data, the timeliness of the data and the ability to respond. Use of APIs inherently provides more timely and more voluminous data than market research on product usage  but it's the combination of API provision to an ecosystem (provides access to raw information on consumption), metrics on usage and diffusion (algorithms), utility infrastructure (raw compute power) and distributed big data systems (processing) which makes exploitation of this more possible. 

Ecosystem models such as ILC where innovation is encouraged elsewhere through reducing cost of failure, the ecosystem is then leveraged to spot  diffusion of innovation and then those diffusing activities are commoditised to component services in order to grow the ecosystem - a process of eating the ecosystem in order to grow it - have only become possible in the last decade. 

The practice should itself diffuse to dominate all industries touched by technology and those thinking that a bigger company (in terms of size) can beat a smaller company with a larger ecosystem (in terms of size) should prepare themselves for a shock. It's not companies but ecosystems that fight in this future world.

This won't be the last time we see billion dollar market cap companies employing thirteen people, quite the opposite. We should expect this, because whilst we're on the tail end of one industrial age which has covered the internet, social media and cloud computing, we're also at the start of a new age which will be built on many of the components that the last produced.

These component will include utility infrastructure (i.e. compute power and storage), big data processing and increasingly a widespread sensor network from smart phones to the software components that we interact with such as SIRI and EVI. 

These components will lead to agent software, an environment where my abilities are augmented by the network around me. From dynamically determining my schedule, to working out what to buy my sister for her birthday to giving me a heads up on my bosses latest meeting. For some background on this see "Any Given Tuesday"

However, the ability of my agent network will depend upon access to information, algorithms, raw compute power and processing capabilities. Even if access to information and processing capabilities were open (as in open data and open source respectively), my ability to exploit this will depend upon the algorithms and volume of computer power I can afford.

In other words could my ability to exploit agents to my personal advantage relative to over others will depend upon how much I can afford?

So not only is education a resource to be bought, so too will the ability to create advantage through agents and to hence more effectively exploit the precious time we all have. Counter to the levelling that open source has brought, this change could lead to an increasingly stratified world between the have more and the have less.

As Tim O'Reilly has pointed out, we are part of this machine and we're not yet sure what we are building. In the excitement of all the possibilities of big data, there exists a dystopian nightmare of reduced social mobility. 

Could my failure to afford the right sort of education and the right sort of agent condemn my son's future to answering endless Turk requests on "which would make a better birthday present?" in order to serve the software agents of others who spend their time on higher matters because their parents can afford to buy them into this strata? Does it matter? Will ability matter? 

Certainly the movement of social mobility in the US / UK gives me pause for thought but who is looking into the social impacts of big data?

Terms I'm using ...

Thought I'd write a note on the general terms that I use.

• Activities are what we do.
• Activities evolve through discrete states - genesis, custom built, product & rental services, commodity & utility services.
• Practices are how we do it.
• Practice evolve through discrete states - novel, emerging, good and best.
• The evolution of an activity can cause the co-evolution of a practice i.e. the shift of computing infrastructure from from product to utility services has caused the development and evolution of a new set of architectural practices.
• Both activity and practice states can be characterised into common phases which have common properties - chaotic, transitional and linear.
• For activities these phases are
• Genesis is chaotic
• Custom, Product & Rental Services are transitional
• Commodity & utility services are linear.
• For practices these phases are
• Novel is chaotic
• Emerging and Good are transitional
• Best is linear.
• The largest inertia barriers to change are found in the evolution of activities from the transitional to the linear phase i.e. the shift from product & rental services to commodity & utility services.
• Inertia barriers are instrumental in controlling the shift between different economic eras - known as the peace, war and build era.
• The eras make up a repeating cycle of change which maybe specific to an industry or have wider economic effect.
• The largest of these cycles of change are known as Ages.

Pioneers, Settlers and Town Planners

I recently heard of a third organisation which has a pioneer, settler and town planner (PST) like structure rather than the usual organisation by type - IT, Finance, Marketing - or the various derivations of (Geography & Type, Business Unit & Type).

I was going to do a long rambling post on evolution, how activities and practices move from chaotic (poorly understood, uncertain, constantly changing, rare, future source of worth)  to more linear (well defined, predictable, stable, common, cost of doing business) and how organisations contain a mass of these activities and practices. Understanding this and using the right methods and tactics is important to creating a balance between the unstable but potentially high margin activities (chaotic) and the stable and low margin (linear).

This process of evolution from chaotic to linear is why "one size fits all" mentalities are so dangerous because you either impact survival today (through poor efficiency) or survival tomorrow (through future wealth creation). This creates the badly termed "innovation paradox" of Salaman and Storey.

There is however a route by which you can create a profitable but stable organisation which deals with the constant cycle of change, except unfortunately traditional organisational structures (by type) get in the way. They do so by obscuring the natural evolution (or flow) of activities from chaotic to linear which is driven by user and supply competition. Invariably the traditional structures built on type result in alignment issues and a host of other problems.

More cell based structures (e.g. Two Pizza) appear better than traditional structures at dealing with these issues but as I accidentally found out in 2004 (but couldn't explain why back then) this can be enhanced by a pioneer, settler and town planner (PST) structure which appears to solve the problem of flow enabling high rates of innovation of new activities and efficiency continuously.  These days, I can explain why this should work but with so few examples then it could just be coincidence or some other bias.

Under PST, there is no IT, Finance or Marketing departments or any grouping by type. There is only a structure defined by evolution and flow - hence pioneers, settlers and town planners.

Now, I could go through the details in a long rambling post but I've done this countless times before in presentations around the world over many, many years. So, instead I'll just add a few diagrams (pinched from various presentations) on PST which is useful for those with a basic understanding of evolution, value chains and the flow of chaotic to linear (for some background see Ten Graphs on Organizational Warfare)

Figure 1 - How things evolve.

Figure 2 - Mapping an organisation, value chain vs evolution

Figure 3 - Structure around it.

Figure 4 - An organisation based on theft.

Overall, I'm happy to hear of another example and I've also been told of a possible fourth. Alas, I'll need several hundred more operating under many years of economic competition before I can actually demonstrate the difference has significance.

The models say this is a more "right" structure than by type and if successful even in these few cases, the practice should diffuse. Time will tell and I'll be watching those companies with a great deal of interest.

20th March 2013

Updated images with higher resolution screenshots with less Neapolitan Ice Cream effect.

The interesting thing about cutting costs

I've been reading about RIM's strategy and the announcements by Chief executive Thorsten Heins that they plan to build new smart phone software in an industry being increasingly commoditised through Android. They also plan layoffs to make RIM more profitable. 

I'm not impressed. First some background, just in case you need it.

All business activities (what we do) evolve through a common pathway but this also leads to co-evolution of practice (how we do it). For example computer infrastructure has evolved from its modern day genesis with the Z3 to custom built systems, products with rental services and finally to more commodity with utility services. As the activity has evolved, so has architectural practices for scaling, system resilience and overall fault tolerance. In the product world, best architectural practice was scale-up with bigger machines, N+1 and disaster recovery tests. In the utility world, this is increasingly being replaced with the emerging practices of distributed system, design for failure and chaos engines. These emerging practices will ultimately become best practice for the utility world.

The evolution of activity and practice both follow a path from a chaotic phase (rare, constantly changing, unmeasurable, poorly understood) to a more linear phase (common, stable, measurable and well defined). In activities this is shown as genesis to custom to product to commodity. With practices you have novel to emerging to good to best practice.

One of the consequence of this process of change is that higher order systems built with best practice in one evolutionary phase (such as applications built on infrastructure with architectural practices of scale up and N+1) incur a transitional cost to the new phase (i.e. you cannot simply port applications based upon scaleable and highly resilient hardware to a utility world offering volume provision of good enough and more standardised machines).

This is one of many inertia barriers to change but despite their existence you have to transition for reasons of competition. I've covered this many many times before, so I'll simply say it's not a question of if but when.

Inertia is important in the cycle of change (the process of commoditisation actually enables genesis of new higher order systems which then commoditise themselves) because it acts as a gatekeeper between different economic states or eras of the cycle - peace, war and build.

The peace era is one of relative competition, where sustaining change exceeds disruptive change, where listening to customers, product improvement and a focus on profit / margin are critical.

The war era is one that is often initiated by a new entrant not encumbered by past business models and the inertia to change this creates. It's a time where disruptive change exceeds sustaining, where competition is a fight for survival, where customers have their own inertia and say they want things (e.g. better SLAs, better hardware) before abandoning this to adopt volumes of good enough. It is a time of commoditisation and the disruption of past industries, past skills and past roles.

Overlapping this is the build era, a time of wonder where capital quickly flows from past industries to new. In this time of creative destruction, new organisations appear exploiting the new co-evolved practice and we see explosions in the rate of creation of higher order systems. It's a time of increased experimentation and uncertainty where there are no customers to listen to and massive increases in unmodeled data with endless arguments over classification. Eventually we see the formation of bubbles and corrections and the new super giants which will settle down to dominate the new industries as they enter a peace era and wait for the next wave.

Now different parts of the economy and its value chains can be in different evolutionary phases at the same time, so whilst one industry is in a era of peace, another is in a era of war. Whilst this cycle can be local it can bubble up through combinations of activities that are evolving in close tine order to create macro economic waves which we call Kondratiev waves or Ages.

The underlying drivers of this (user and supply competition), the process of evolution, co-evolution of practices,  the cycle it creates, the new forms of organisation, the increases in data and the link to macro economic waves can be traced back over 200 years. In business, I've been actively using these models and making public presentations on them over the last 6 years. The entire system not only has cause and correlation (thousands of data points) but is most importantly predictive - something which I finally was able to test at the LEF last year.

So, to the title - the problem with cutting costs.

If your industry (i.e. the parts of value chain which you sell) are in a peace era then cutting costs through efficiency to increase profitability due to declining revenue can be a good play, assuming you don't reduce barriers to entry into the space. There are many reasons why you would do this and often you can clear out a lot of waste in the organisation.

However, if your industry has moved into the war then then cutting costs through staff to restore profitability due to declining revenue is often a terrible move. The problem is your revenue is eroding due to a change in the value chain and the commoditisation of the activity. You need to respond by adapting and possibly moving up the value chain. However, by layoffs you're likely to get rid of those people who were seen to be less successful in the previous era.  That doesn't sound too bad but the result is you end up with a higher density of people successful in the past models (which are now in decline due to evolution) and hence you'll tend to increase your cultural inertia to change. Revenue will continue to drop and you'll start a death spiral. 

What you of course should be doing is adapting and realising that the tactics you play in one era are not the same as another (peace vs war etc). Now any large organisations has multiple different values chains in different evolutionary phases and you have to see this and know how to switch context between them in order to choose the right tactics. Naturally, most people don't manage to achieve this which is why big companies often die but at least that keeps things interesting.

So back to RIM. Trying to produce a new software product in an increasingly commoditised industry seems to smack of inertia to change. Cutting staff through layoffs will almost certainly reinforce this. RIMs future in my view has become pretty bleak. So expect the usual patent spats of a wounded creature which is in a self inflicted death spiral. Also, expect the usual nonsense about how it wasn't the strategy but the culture, market and competitors that finished RIM. Alas, this is a classic case of a succession of CEOs out of their depth and driving a good company to the wall.