Next phase of research ...

Many years ago, I produced the ubiquity vs certainty curve to describe the process of how business activities evolve. It took 4,084 data points to create the curve and more details about this topic can be found here.

Currently, I'm researching into how organisations evolve. After conducting a number of general and then specific interviews (creating a thousand data points), I've been able to create models of evolution which hopefully I'll be using in future presentations.

However, I need to collect more data to test the models and either verify or falsify them and hence I've put a general survey online : [Link to Survey]

The presentations that I give at various conferences are based upon this process of hypothesis and testing, so if you have ever found my work useful (such as my various talks at OSCON on cloud computing, see below) then I would be very grateful if you could take 10-20 mins to complete it.

Depending upon the results and validity of the models, I'm aiming to give a number of talks next year on how organisations evolve combined with techniques to exploit this. Naturally, I'll be blogging about the findings as well and the survey does allow you to provide an email in case you'd like a copy of the overall results.

[Link to Survey]

Thanks

Simon Wardley

OSCON 2010: "Situation Normal, Everything Must Change"

Preparing for war

Following on from my post on ecosystem wars, I thought I'd discuss some techniques and tactics to use. However, before I do, I need to first describe the organisation that I hope you work for. If this doesn't describe you and your organisation then the techniques and tactics probably won't make sense and I can save you the trouble of reading the next post.

Once again, my apologies to regular followers or attendees of my presentations, this post is just scene setting and so it runs the danger of teaching grandma to suck eggs.

I'm going to assume you're battle hardened, you realise that business is all about warfare and you've got a keen eye for competition. You've probably done a stint in the typical organisation, scratched your head over some of the practices and ultimately found yourself in a new sort of company (possibly created by you).

You understand what an organisation is. Rather than making the mistakes of the past and simply grouping people, activities and methodologies into generic structures such as IT, Finance, Marketing - you've taken the time to look. You may well have profiled your organisation (see figure 1) and identified those activities you consume, those activities you sell and those activities which act as barriers to entry into your industry.

Figure 1 - Profile (click on image for higher resolution)

You know the importance of ecosystem and how this can both accelerate innovation and reduce your risks. You might be using a model akin to ILC (innovate, leverage and commoditise) to grow and keep a vibrant ecosystem around your products and services (see figure 2).

Figure 2 - ILC model (click on image for higher resolution)

You know full well that methodologies have to change with lifecycle because characteristics do and how activities are interconnected (see figure 3 & 4). One size never fits all isn't effective hence you don't engage in the typical debates of this vs that, agile vs six sigma, push vs pull - you know you need both.

Figure 3 - How Characteristics Change (click on image for higher resolution)

Figure 4 - How Methodologies Change (click on image for higher resolution)

You also recognise that not everyone is the same, you have different types of people :-

• Your pioneers are feverishly imaginative, often chaotic in nature, constantly exploring and they create the crazy stuff. They work on a cadence of weeks, maybe months and they fail often and miserably but they're never afraid to experiment. They want to push things out there, they're infectious, they can even be hazardous. They're not a "safe" pair of hands but you don't want them to be. Every now and then they create your future source of competitive advantage, though you don't know it until it starts to be adopted by the wider ecosystem. They are your Da Vinci's.


• Your town planners build the core of your company and the components which your pioneers develop upon. They build the solid, useful and beautiful and they're obsessed with getting things better, faster, more efficient and more reliable. They're meticulous, methodological and geniuses who hide worlds of complexity behind standard interfaces. They're ultra reliable, your "safe" hands and they work on a cadence of months, even years. They provide the operational efficiency which you can use to bury your competitors. They are your rock, they are your Vitruvius'


• In between, you've got your settlers. They watch the landscape, your competitors and spot the patterns which are going to either disrupt an existing revenue stream or reduce some barrier to entry. They constantly take innovations away from the pioneers and force them to move onto the next thing. They'll drive that innovation into the wider ecosystem, spin it out or fail it fast where necessary. They adapt to the changing environment and adopt what's growing. They've always got their eye on pushing a growing trend towards the town planners. They listen to the ecosystem and whilst they don't create the future or build the cities, they play the games of tactical warfare which are so essential to survival. They are ruthless to your competitors, nurturing to your own ecosystem and you're just glad they work with you. They are your Machiavelli's.

You probably identify yourself with one group and you could probably have read down the list of your employees naming which group they belong to. You didn't have to, they told you.

You've long given up on trying to create departments with a mix of Da Vinci's, Machiavelli's and Vitruvius' and listening to the constant arguments within those departments about how to best run IT or whatever they're assigned to do. You understand they won't agree, they never will.

You understand that outsourcing a department may get rid of the arguments but you'll end up removing sources of competitive advantage. It's better to let the town planners outsource those activities that can be removed.

You've given up making speeches about the need for innovation or efficiency, you know you need both. You've also realised that you need to nurture both pioneers and town planners to do this and you have to let them use the tools they need to get the job done. You understand those tools are different. One size fits all seems a long distant and best forgotten memory.

Hence you've probably decided to structure yourself around change and have groups like pioneers, settlers and town planners - though you'll call them something else. You've probably discovered the alignment issues between your old groups was an artificial construct of how you organised yourself. You've probably also realised the importance of the settlers in managing change and wondered why you didn't do this before.

You've almost certainly realised you want the best Da Vinci's, Machiavelli's and Vitruvius' to compete and hence focus almost religiously on high levels of talent and acquiring the best, no matter where they are in the world. You remove any and all unnecessary vestiges of the old world - expenses, timesheets, standard company laptops and so forth and instead have instilled a culture of respect.

You're going into a war. You want your people fighting and you want them to have the tools they need. if you can't trust your people to fight on your side then you don't want them. Your management reflects this, your organisation reflects this, your people reflect this. It feels vastly different from the old ways you remember.

If this is you, then the next post on tactics will make sense and we can go on to explore some of the actions being taking by the big players in our ecosystems.

Ecosystem wars

Back in 2005, I started to talk publicly about lifecycle concepts and the importance of ecosystems. In the next two posts, I'd like to draw a line in the sand and cover those basics of ecosystem one last final time.

I'll take the liberty of assuming notions such as lifecycle, organisational profile, componentisation and consumerization are universally understood and start with an explication of what a business is.

What is a Business?

A business is a living thing, comprising a network of people, a mass of different activities, and reserves of capital including financial, physical, human and social. It consumes, it produces, it grows and it dies. Like all organisms, any business exists within a number of ecosystems in which it competes and co-operates with others; it’s shaped by and shapes its environment, and hence needs to adapt constantly merely to survive.

People come and go, activities change, and hence all firms are in a constant state of flux. In any industrial ecosystem, new activities (innovations) are a consequence of competition and those that are useful will diffuse throughout the ecosystem becoming more of a commodity. This constant change creates a paradox, identified by Salaman and Storey:

”Survival requires efficient exploration of current competencies and ‘coherence, coordination and stability’; whereas innovation requires discovery and development of new competencies and this requires the loosening and replacement of these erstwhile virtues.”

These two extremes of survival (today and tomorrow) have diametrically opposite concerns, and the techniques, tactics and methods needed to manage each are entirely different. Those who manage organizations are therefore caught on the twin horns of a dilemma: how is it possible to be standardized and efficient as well as innovative and new, without prejudicing your survival - either today or tomorrow?

The effects of this on business can be seen in the constant restructuring to cope with new paradigms, and in the yo-yoing of popular management theories between opposites in a scramble to maintain order. A more effective balance can be found through embracing both goals simultaneously.

How do we balance both goals?

This requires a rethinking of how we organize, and a realization that what really matters is not innovation or efficiency per se, but how we continuously manage the path between the two. To explain why this is the case, let us examine a typical profile of an organisation (see figure 1) and consider how we build systems for the future.

Figure 1 - Using profile to build systems (click on image for higher resolution)

First, let us take those cost of doing business activities which act as underlying components of other business activities such as payroll, computer infrastructure, authentication etc. All of these activities are linear, well defined, ubiquitous and suitable for provision as standard re-usable components through utility services. Such an approach will increase our agility, rate of innovation (componentisation effects) and reduce the cost of gambling for any innovative activities built upon these utility services.

However, it is important to understand that all innovations (i.e. those activities which are uncertain and rare) are a gamble and whilst we can reduce costs we can never eliminate it. The future value of something is inversely proportional to the certainty we have over it, we cannot avoid this information barrier any more than we can reliably predict the future. However, there is a means to maximise our advantage.

By making these utility services accessible through APIs, we not only benefit ourselves but we can open up these components to a wider ecosystem. If we can encourage innovation in that wider ecosystem then we do not incur the cost of gambling & failure for those new activities. Unfortunately, we do not enjoy the rewards of their success either

.

Fortunately, the ecosystem provides an early warning mechanism of success i.e. adoption. Hence by creating a large enough ecosystem, we can not only encourage a rapid rate of innovation but also leverage that ecosystem to identify success and then either copy (a weak ecosystem approach) or acquire (a strong ecosystem approach) that activity. This is how we maximise our advantage.

To capitalise on this, we simply drive our newly acquired activity towards utility service provision and create the next wave of innovation through further componentisation effects. In this manner we create a virtuous circle of encouraging innovation in the ecosystem, leveraging the ecosystem to identify the next pattern and commoditising the pattern to utility services in order to encourage the next wave.

In effect, by being at the heart of this ecosystem we manage to create the simultaneous appearance of being highly innovative (as others in the ecosystem do this for us), highly customer focused (by leveraging the ecosystem to identify rapid diffusion) and highly efficient (as we focus on commodity provision). Tom Peter's old adage of choose one is a busted flush in this brave new world.

I've summarised these concepts in figure 2

Figure 2 - ILC model (click on image for higher resolution)

What is critically important to note, is that in essence both innovation of new activities and efficiency of commodity provision can be outsourced. The innovation of activities can be outsourced to a surrounding ecosystem building upon our services, whilst those commodity activities we consume can be outsourced to a marketplace of utility providers. There are benefits to retaining some element of control in those areas but the critical area to focus on is the transitional phase and how you leverage the ecosystem. Our ability to exploit the link between innovation and commodity depends upon the size, composition, engagement, speed of information and overall level of activity within that ecosystem.

Whilst each company comes with its own personal ecosystem (its staff, its partners) growing an extended ecosystem and using that to manage change is a powerful tool and a competitive weapon. It's not businesses but ecosystems that collide in the commercial world and woe betide that organisation which has the weaker. We've seen this story repeated many times before at many different levels through all the usual examples of BetaMax vs VHS or TCP/IP vs IPX/SPX.

It's imperative to understand that a well formed and large ecosystem leads to lower costs of innovation, creates higher rates of innovation, improves the rates of successful adoption, encourages greater efficiencies and can be mined to detect future successes. However, there are cost to this especially in the form of data collection which is why utility based ecosystems (where information is derived from consumption of APIs) have an advantage over product based ecosystems (where information is derived from market research). 

If it is just you and your employees then you'll find it difficult to survive a direct onslaught from any of the modern day monsters with well developed and extended API driven ecosystems (such as Google, Amazon etc). Not impossible, just damn difficult.

For more details, my OSCON '10 talk provides a useful overview of these concepts. However this is enough of a base to begin with.

In the next few posts, I'll cover some of the consequences of this and the strategies which are commonly deployed. Again, I realise this is nothing new and apologies to all readers who've had to endure me harping on about this over the last five years but I'm just scene setting for much later posts.

Should I listen to my users?

Following on from my previous post on lifecycle, I thought I'd discuss the question of when to listen to users. I'm going to use my lifecycle and profile graphs to illustrate the points I'll be raising, so if this is not familiar to you then please read my most recent post on lifecycle.

Figure 1 - Lifecycle (click on image for higher resolution)

Figure 2 - Profile (click on image for higher resolution)

Before I start, a word of apology. All of this stuff is blindingly obvious and has been for many many years - hence please don't take offense.

Any new activity starts in the chaotic phase and then as it evolves through its lifecycle it enters a more linear phase. As it moves, its characteristics change from uncertain, deviating and a source of worth to known, standard and a cost of doing business.

Less confusion creeps in, let's just reiterate that a new activity is an innovation. Whilst we tend to abuse the term innovation, a feature differentiation is a feature differentiation, a process improvement is a process improvement and an operational efficiency is an operational efficiency e.g. you can call every process improvement, operational efficiency and feature differentiation an innovation if you want but good luck in trying to make sense of things if you do.

As explained in earlier posts, as an activity's characteristics change then the methods by which you can effectively manage it change as well i.e. we shift from agile to six sigma for example. This is why there is no one size fits all.

Equally, in the chaotic stage the approaches taken are about gambling, experimentation, potential future worth and novel practice (i.e. it's highly uncertain), however when that same activity has entered the linear stage it's all about conformity to standards, defined processes, price vs quality of service and best practices (i.e it's predictable). In between these two extremes is where ROI (return on investment) matters because unlike the chaotic stage a market exists to provide some basis for trending and unlike the linear stage, you have a choice over whether to implement it since it is not a cost of doing business.

When it comes to users then :-

• In the chaotic stage the only reason why you would listen to potential users is the same reason why you might collaborate with others - serendipity i.e. the chance encounter of a better idea. Of course, whether the idea is better or not won't actually be known until you "experiment" i.e. you put it out into the market. You have as much chance as identifying the future successful innovation as any user and there are no methods of guaranteeing any innovation will be successful. Like it or not, you have to gamble. The rule of thumb is listen to yourself.


• In the transition phase listening to users is essential because a market has established, users are becoming familiar with the activity, customer feedback and trending is possible and competitors can be analyzed. The rule of thumb is listen to your ecosystem.


• In the linear stage, the activity is a commodity and its all about price vs QoS. Now, assuming you're not going to embark on a disinformation campaign and attempt to persuade users that a commodity is actually some form of innovation (a common tactic) then the only thing you need to really focus on is your position against competitors i.e. faster, more reliable, cheaper etc. Hence the rule of thumb is pricing & quality comparison.

So, should you listen to users? The answer is "yes and no", which one depends upon the stage of lifecycle of the activity in question.

[Added Note 26/02/11] I've just come across this Fred Wilson quote : "Early in a startup, product decisions should be hunch driven. Later on, product decisions should be data driven". It's pretty much spot on.

Deconstructing Gartner's Hype Cycle

This is a piece of work that I did many years ago but given my recent post on Lifecycle (nee evolution). I thought I'd revisit it. I will assume the reader is entirely familiar with the concepts of commoditisation.

In figure 1, I've taken part of the evolution curve and modeled onto it a differential benefit curve (differential value - cost of implementation). This latter curve shows how the benefit of an activity changes as it evolves from its early innovation (where it is a strain on company resources) to a late product stage where the activity is ubiquitous and of insignificant differential value between competitors.

Figure 1 - Lifecycle & Differential Benefit (click on image for higher resolution)

When a new activity appears, you often get whitepapers written about it. These are generally done at a time when the activity is showing a highly positive differential benefit. Obviously there is a delay between the collection of data, the publication of the whitepaper, a user reading the whitepaper, the decision to do something and then implementation of the activity.

By the time an activity is implemented, the actual differential benefit may be vastly different. This creates a delta for expectation i.e. a difference from what we thought we would get and what we got. Figure 2 provides a graphical notation of this.

Figure 2 - Delta in Expectation (click on image for higher resolution)

Modelling this delta, with an awful lot of assumptions, provides the expectation curve shown in figure 3. There are a complex set of assumptions and conditions around this, however for the purpose of this post then I'm happy to say this curve is somewhat valid ... caveat, caveat ... except where it's not :-)

For the sake of this post, let's just pretend it is. What the curve shows is the early stages start with low expectations (but possibly high hopes), expectations are then quickly exceeded and continuously rise to reach a plateau after which expectations rapidly become unfulfilled leading to a trough of disillusionment before eventually levelling.

Figure 3 - Expectation Curve (click on image for higher resolution)

This all sounds strangely familiar and so it should. The expectation curve quite neatly maps to Gartner's hype cycle - see figure 4. So, we have a potential basis for explaining the underlying forces behind the hype cycle except of course, we have all the assumptions and I'm talking about expectation and not visibility. I'm not even sure what visibility actually means but given it's a hype cycle, I'll assume high hopes (expectations) means high visibility. Clocking up another assumption here.

Figure 4 - Hype Cycle & Expectation Curve (click on image for higher resolution)

Does our new underlying "basis" of the hype cycle shed any new light on the subject? Well, yes. However before I show this, I'd like to examine the final stages of lifecycle.

The evolution of an activity from products to utility services invokes its own expectation curve not through differential value (the creation of a new activity) but operational efficiency (a more efficient means of providing an existing activity).

In figure 5, I've provided the later stages of lifecycle including the transition from products to utility services and modeled an operational benefit curve (operational efficiencies over competitors - cost) of a transition to utility services. Again, lots of assumptions.

Figure 5 - Lifecycle and Operational Benefit (click on image for higher resolution)

NB. this benefit curve is the same shape as the earlier differential curve being derived from the benefit created over competitors, number of competitors exploiting the change and a changing cost of implementation due to maturity. Hence the transition to utility services starts with a period of investment, a rapid benefit over competitors gained by those creating or exploiting such services and then a decline in benefit over competitors as more companies switch to a utility model.

The reason why I mention this, is that whilst Cloud Computing is all about volume operations for ubiquitous and well defined activities (i.e. use of computer resources in business) and is hence all about commodities, this transition will create a similar expectation curve around operational efficiency in much the same way that a genuine innovation creates an expectation curve around differential value. This is shown in figure 6, and the result is the same delta in expectation curve shown beforehand.

Figure 6 - Delta in Expectation (click on image for higher resolution)

Our first "insight" is Gartner's hype cycle tends to show both innovative activities and transitional effects on the same graph. We should be careful to distinguish between operational efficiency (doing the same thing better) and differential value (doing a new thing) lest we start to confuse Cloud Computing with Innovation.

Hence, in the following hype cycle I've highlighted several activities, including :-

• cloud computing: more efficient provision of the existing activity of "using computer resources in business"
• social network analysis: a relatively new activity and a potential differential

Figure 7 - Expectation and Hype Cycle (click on image for higher resolution)

Since we started with differential value or operational efficiency, we can now map "value" zones onto the hype cycle. I've done this below.

Figure 8 - Hype Cycle & Value Zones (click on image for higher resolution)

What this suggests is the early stages of the hype cycle has an increasing benefit. In the trough of disillusionment, there is still benefit to be gained but it's diminishing. However, in the slope of enlightenment and the plateau of productivity there is little or no differential or operational benefit over competitors since everyone else is doing it. That's our second "insight".

The lesson of this story has been known in military circles for a long time. An imperfect plan executed today is better than a perfect plan executed tomorrow i.e. if you wait until the activity can be easily and effectively implemented (the plateau of productivity), it'll provide little competitive benefit to you.

Fortune favours the brave.

[A final few comments]

To generate the expectation curve I had to create a model over time. This required lots of assumptions because the evolution (lifecycle) curve does not have a time axis (i.e. you can't predict when something will evolve). There are hence a couple of points I'd like to make clear.

1. You can't simply overlay the expectation curves of different activities on top of each other - i.e. the axis of time is different (some are stretched, some are shortened). Gartner's curve doesn't define its time axis and we can therefore assume they're referring to a general shape which appears over an undetermined length of time.
   
2. The Gartner curve specifically refers to the technology trigger. We can assume this is when the technology starts to spread and ignores any early stage effects (invention etc).
   
3. If the Gartner curve was based upon the measurement of some physical property, it would be possible to reverse the process i.e. from Gartner curve to expectation curve to evolution lifecyle and accurately state where an activity was along the uncertainty axis. By very definition this is impossible. I can currently only state where something was in the past once it has become a commodity. Hence I have to conclude that Gartner's curve is not based upon some external measurement of physical property but instead it is more likely by a process of expert review (i.e. averaging where forecasters think something is on the curve) or even more simply, analysts placing dots on the curve.
   
4. The Hype Cycle in its current form can have both novel activities and the evolution of the same activity to more commodity forms represented on the same position of the curve at different times i.e. a single activity may well go through the the peak of inflated expectations multiple times. In the first case, this will refer to the differential value of the novel activity but later on, the same activity will appear in the same position due to operational efficiency of a more commodity form. This occurs because the same activity can be given multiple different memes i.e. x86 architecture, client/server, hosting or cloud and whilst those memes are different, the underlying activity (i.e. provision of computing infrastructure) is the same. You cannot therefore use the Hype Cycle to determine evolution, notwithstanding the issue that it is time based and evolution cannot be measured over time (we have no crystal ball).
   
5. The expectation curve matches the Gartner curve in certain circumstances. I cannot conclude much about the Gartner curve other than to say that its shape appears to have some validity in specific circumstance and I can approximate the value zones where the curve does match. This doesn't say anything about where the dots are placed on the curve just that the rise of increasing then diminishing then plateau of negligible benefits seems broadly right. That up, down, almost flat shape seems to have merit.

-- Update 10th Feb 2015

This uses an old form of the evolution graph. I've subsequently refined the terms innovation, custom built, product and commodity to genesis, custom built, product (+rental), commodity (+utility). The problem was that whilst I used "innovation" to mean the first ever attempt to put an activity in practice, the common use of the word "innovation" (used liberally to mean genesis of something, feature differentiation of a product, introducing a utility model for an existing activity) made that meaningless. Hence, I changed to use "Genesis" to re-assert the point.

-- Update 7th Sept 2015

Gartner Hype cycles no longer use Visibility vs Time but instead Expectations vs Time. The "time" axis seems to be only a generic sense of travel as the items on the hype cycle are given times to reach the plateau e.g.

I have no idea why they've made this change. Obviously, I was using an expectation curve and so again I broadly agree with the shape. I'm somewhat concerned that the axis changed but the curve didn't but given that the dots are just aggregated opinion, I suspect the curve is just an opinion as well. This doesn't mean it's not useful, as long you keep in mind it's just opinion all the way down.

Pioneers, Town Planners and those missing Settlers.

All business activities evolve, they share a fairly common lifecycle described in the following diagram. From innovation, to custom built examples, to productisation (including the appearance of rental services) and finally to commodity (including utility services).

Figure 1 - Lifecycle (click on image for higher resolution)

As those activities evolve, their properties change from a chaotic to a linear extreme. In the chaotic stage, the activity :-

• deviates from what has existed before and is a novel practice.
• is dynamic and constantly changing.
• is rare and poorly understood.
• has high levels of uncertainty and it is not possible to predict future outcomes.
• has no market data, competitor analysis or well understood trends.
• has characteristics which emerge as we learn about it.
• is strongly affected by serendipity, chance encounters and discovery.
• is a potential source of future worth, differential and hence competitive advantage.
• is a gamble

By the linear stage, that same activity has evolved and:-

• is mature and rarely changes.
• is standardised with a wealth of best practice.
• is commonplace and well understood.
• has a high degree of certainty and known impacts.
• has an abundance of market data, competitor analysis and trends are well known.
• has well defined characteristics.
• has well defined procedures and plans for implementation.
• is a cost of doing business with little or no differential advantage except through operational efficiencies.
• is a known quantity.

Now all businesses consist of a mass of activities, each of which may be at different stages of their lifecycle (stage of evolution). You can map a single business by examining the components involved in a line of business and their stage of lifecycle. You can also examine broader effects by plotting the frequency of activities at different stages of lifecycle thereby creating a profile for an organisation or an industry. This is shown in the figure below, to which the chaotic, linear and in-between stage of transition has been added.

Figure 2 - Profile (click on image for higher resolution)

The techniques which you use to manage each of the phases of profile (chaotic, transition, linear) are entirely different because the fundamental characteristics are different. Which is why no one size fits all approach to management exists. For example, agile development approaches are ideal for the innovation (chaotic) and early transition phases but are superseded by more structured approaches such as six sigma in the late transition and commodity (linear) stages. You can't apply one size fits all without either hampering innovation or impacting efficiency. You need multiple techniques, multiple types of people and even multiple cultures. Alas we ignore it.

In many areas of management, this creates a constant yo-yo between one extreme approach and another such as : agile vs six sigma, networked vs hierarchical, push vs pull. The answer is invariably you need a balance of both. The trick is to learn when to use each.

Given all this, here are my questions :-

1. Since lifecycle is constant and the properties of activities change as they evolve through their lifecycle, why do we organise ourselves around type of activities (e.g. IT, Finance, Operations) especially as a "typed" approach leads to outsourcing of inappropriate activities, misapplied techniques & alignment issues between groups?

2. Why don't we organise ourselves instead by lifecycle with specialist groups managing each stage of lifecyle regardless of the type i.e. an organisation based upon Pioneers, Settlers and Town Planners?

3. Most companies have Research & Development groups (equivalent to Pioneers) and common or shared service groups (equivalent to Town Planners) but Settlers seem to be invisible. Why is this? Who manages the transition from innovation to commodity in your organisation?


-- Update 8th March 2015

A bit of digging in the old memory banks, brings me to Robert X. Cringely's book, Accidental Empires reissued in 1996, page 235 - 238. Copying some quotes from that book (which I recommend people go buy and read), the ideas of pioneers, settlers and town planners are all there. I knew it had come from somewhere.

Think of the growth of a company as a military operation, which isn't a stretch, given that both enterprises involve strategy, tactics, supply line, communication, alliances and manpower.

Whether invading countries or markets, the first wave of troops to see battle are the commandos. Commando's parachute behind enemy lines or quietly crawl ashore at night. Speed is what commandos live for. They work hard, fast, and cheap, though often with a low level of professionalism, which is okay, too, because professionalism is expensive. Their job is to do lots of damage with surprise and teamwork, establishing a beachhead before the enemy is even aware they exist. They make creativity a destructive art.

[Referring to software business] But what they build, while it may look like a product and work like a product, usually isn't a product because it still has bugs and major failings that are beneath the notice of commando types. Or maybe it works fine but can't be produced profitably without extensive redesign. Commandos are useless for this type of work. They get bored.

It's easy to dismiss the commandos. After all, most of business and warfare is conventional. But without commandos you'd never get on the beach at all. Grouping offshore as the commandos do their work is the second wave of soldiers, the infantry. These are the people who hit the beach en masse an slog out the early victory, building the start given by the commandos. The second wave troops take the prototype, test it, refine it, make it manufacturable, write the manuals, market it, and ideally produce a profit.  Because there are so many more of these soldiers and their duties are so varied, they require and infrastructure of rules and procedures for getting things done - all the stuff that commandos hate. For just this reason, soldiers of the second wave, while they can work with the first wave, generally don't trust them, though the commands don't even notice this fact, since by this time they are bored and already looking for the door. While the commandos make success possible, it's the infantry that makes success happen.

What happens then is that the commandos and the infantry advance into new territories, performing their same jobs again. There is still a need for a military presence in the territory. These third wave troops hate change. They aren't troops at all but police. They want to fuel growth not by planning more invasions and landing on more beaches but by adding people and building economies and empires of scale.

Robert X. Cringely, Accidental Empires, 1996 (the reissued, I don't own the original).

What Robert called Commandos, Infantry and Police is what I later called Pioneers, Settlers and Town Planners. The two are identical except Robert was there much, much earlier. In fact 1993, a good ten years before I implemented the tri-modal structure,

I owe Robert Cringely a debt of thanks and hence the update.

-- Update 4th May 2016

These days I use terms such as uncharted to describe the more chaotic and industrialised to describe the more linear.