Monday, December 01, 2014

The 10xers

Back in the days of Fotango (circa 2000 to 2007), we used to talk about the difference between an average developer and a rock star as being 10-100x. I used a number of techniques to create centres of gravity, a good working environment, interesting projects and went on a rampage hiring almost every star Perl developer we could get our hands on through the open source community. We certainly acquired a selection of stars.

But, here's the rub. What I didn't realise fully at the time (but I do now) is that we also knew where to attack, what to commoditise and we had a very highly developed awareness of our environment and markets. We certainly didn't exploit this as well as we could but in terms of cloud, we were years ahead of the game.

To give you an idea, here's a few snippets from an early 2007 board pack (remember this stuff was all in production, live in 2006, if not before) ....

Snippet 1 - Where we were and dealing with existing issues

Snippet 2 - An overview of Zimki - a PaaS (in 2006)

Snippet 3 - On the earlier 2006 Strategy

Snippet 4 - On the impacts of the Zimki PaaS

Alas, in an act of vandalism a well known consultancy gave the parent company advice that this stuff wasn't the future. But that's not what is important.

What's important here is that our strategic play came from our understanding of the environment and our use of techniques such as mapping. It's the same technique I used at Canonical when we took Ubuntu into the cloud against RedHat and others. There's also an array of gameplay that can be involved.

So what has this got to do with the 10xers? Well, this concept and the war for talent is all the rage but does it really help if you can build the thing faster, more efficiently and more well designed if you're building the wrong thing? 

The problem that I commonly see is that situational awareness is so poor in business that most strategy is little more than copying others, gut feel, story telling and astrology. I'm no genius but if I'm playing a game of chess against you but only I can see the board then you're going to lose every time no matter how good your people are. Of course, if we all suck at gameplay then 10xers will certainly make a huge difference because the one who has them will get to experiment, trial and gain feedback faster.

The point of this post is simple - don't just assume that 10xers are the solution to your problem. You may just end up getting where you don't want to be, faster. Know where you need to attack i.e. make sure you have good situational awareness and exploit it. Finally, and most importantly, NEVER employ big name strategy consultancy firms (under any circumstances). Learn to play the game for yourself.

Sunday, November 30, 2014

On the impact of CEOs

There is a popular idea of the CEO as the lone mastermind directing the fortunes of a company, playing a game of chess against the CEOs of other companies. In some cases, more often the exception rather than the rule, this appears to be the case. But I want to talk about the rule not the exception.

To begin with, we need to tackle this idea of the lone CEO. I've often faced situations when discussing gameplay where the CEO would respond "I'd love to do this but my management won't let me."

The first time you'll hear this it is often a shock. Surely the CEO has absolute power in an organisation? Alas, no. In many cases the power within an organisation is shared with the board and with lower levels of management. It is difficult to estimate how widespread this phenomena is or how much impact it has. Techniques vary from examining the role of the CEO, the titles of the CEO and whether the CEO was a founder or an insider / outsider. The answers usually vary from around 30% to 50% of companies having a 'strong CEO' i.e. one that can directly exert their will on the organisation and even then, this question is often hotly debated.

What is interesting, is there "no evidence that firms with powerful CEOs have on average worse performances than other firms" (see Powerful CEOs and Their Impact on Corporate Performance - Renee Adams). Instead these firms tend to be a mixture of the best and worst performers in the market. But how much is this difference?

Again, answers on these vary depending upon the examination, the definitions used etc. I've seen distributions of 15% to 25% of strong CEOs being top performers, the same amount being underachievers and everyone else roughly where the market is.

Of course, there are other ways of examining the impact of CEOs. For example, there has been considerable work on the impact of CEO death (compared to other executives) on the performance of a company. Whilst there has been shown to be a correlation between death and subsequent poor performance of the firm, an intellectual leap is often made that this correlates to the CEO having a positive performance. The problem is one of 'infantilism'. If a strong CEO exists, an organisation may well be ill prepared to cope with decision making for a short period of time due to the previous dependency. You cannot therefore simply assume that a negative performance is due to some beneficial impact of the CEO as opposed to a dependency on the role.

Another issue is that of situational awareness and competition. In previous work (looking at the levels of situational awareness vs action in 160 high tech companies) then, it has been noted that situational awareness and strategic play are not uniform and high levels of situational awareness and strategic play are associated with positive market cap growth (see figure 1).

Figure 1 - Awareness vs Action

Unfortunately, in the wider market it is estimated that less than 30% of large companies undertake any form of scenario planning and less than 4% have any means of visualising the landscape they compete in. Without this, strategic play appears to be more about copying others, gut feel, story telling and astrology than it is to chess. However, this is also an issue of competition because poor strategic play and situational awareness only matters when competing against others with better strategic play and situational awareness.

So, what's the impact of the CEO?

Currently that's an impossible question to answer. However, if we assume that between 30% to 50% of CEOs are 'strong CEOs' (i.e. power resides within them rather than elsewhere) and that between 15% to 25% have a positive impact, you can (as a rule of thumb) say that 4.5% to 12.5% have a positive impact. The remaining 87.5% to 95.5% have little or no effect at all, if not negative.

On the question of executive death, we cannot assume these figures demonstrate a positive influence (as opposed to a negative impact due to loss) due to the potential for 'infantilism' within an organisation. The issue regarding low situational awareness would also imply that the number of CEOs having a positive strategic benefit is low, however even in a game between blind chess players there will be winners and losers. Hence, for many markets the lack of situational awareness won't have a significant impact on outcome because all competitors lack situational awareness. Even astrology gets it right, sometimes.

Overall the data (which is far from conclusive) suggests to me that the impact will be at the lower end of the scale based upon the level of strong CEOs, performance differences and poor situational awareness. I'd put the figure at around 5% of CEOs having a significant, repeatable impact. This issue of situational awareness is also not confined to the CEOs but impacts other C-levels and can be exhibited by the tendency of strategy to simply emulate others.

So, whilst in some corners of industry the image of the "lone mastermind directing the fortunes of a company, playing a game of chess against others" seems reasonable and can appear to have a significant impact, this is not the rule. In most cases it would appear that replacing the CEO might have a short term detrimental impact (though this may well be due to infantilism of the organisation and the need for the role not the person) but the overall longer term impact appears negligible. You could just replace them with a random person from the street on the understanding that the power structures in the organisation would cope admirably. 

Now, I'm not suggesting you do this on an individual basis - particularly because you might unfortunately remove a person who is the exception and does create a significant impact. However, the argument that we cannot enforce a greater gender balance at the board level (as has happened in Norway) due to the importance and experience of these people is highly questionable in my opinion. I've not seen data that supports the idea that the commercial world would suffer due to such a change. In fact, it suggests there will be little negative impact on the performance of those companies. If anything the impact (due to diversity) may well be positive.

Until such time as someone can conclusively demonstrate that the existing cadre of CEOs have an overwhelmingly positive impact on performance, I'll hold the view that a short sharp shock (e.g. regulation requiring immediate gender balance in the board, at senior levels and employment of women as CEOs) is not only beneficial from a societal viewpoint but will not adversely effect the performance of industry in the long run. The argument that there aren't enough women with the calibre and experience to be chess playing CEOs is bogus in my opinion. 

Most CEOs don't play chess.

Saturday, November 29, 2014

Fool's mate in Business

I'm in the middle of writing up some work and I thought I'd spend a bit of time explaining how utterly ridiculous strategy is in many organisations. I know people like to talk about chess in the boardroom but most of the time it's more like equal parts of copying others, alchemy, astrology, story telling and gut feel.

To illustrate this, I'm going to explain one super simple move which should never work but does - almost all the time. This move, I'll call Fool's mate. 

Now since this move is in play in various industries, I'm going to use a hypothetical example to demonstrate it. I'll start with a map of a particular media industry (see figure 1).

Figure 1 - Map of the Media industry

From the map above, I've highlighted certain parts. First, the company sells its content (i.e. shows) through both aggregation sites and its own branded efforts. The shows themselves come from a pipeline with constantly evolving content - it's starts as a novel show and then becomes a sold or acquired format. The distribution mechanisms are shown but what I'll focus on is the artistic direction side which defines the type of novel shows produced.

In this case, the shows are produced by creative studios, of which there are a limited number. This creates a constraint and as a result the cost of producing shows is quite high. Ideally, if you were the company commissioning and distributing shows then you'd like to see a more fluid and competitive market. However, those same creative studios will resist any drive to commoditising their field. I've marked this all up in figure 2 including a red arrow for how you'd like to change it and a black bar for the inertia the studios would have against this.

Figure 2 - Commissioning vs Studios

The creative studios themselves have a constraint which is talent and access to production systems. This relationship is shown in figure 3. By commoditising the production systems, you should therefore be able to increase the talent pool and drive the creative studios towards more of a commodity creating a more fluid market. 

Figure 3 - Exploitation of Underlying constraints

Now, those companies involved in providing production systems (i.e. the physical studios themselves, the equipment etc) aren't going to be happy about a commissioning company entering this field and trying to make it more of a commodity. They will have their own inertia (shown in figure 3 above) and resist.

The creative studios should of course resist this change as well because the effects on their industry (e.g. reduced barriers to entry) are so obvious. However, if they were absolutely clueless then they might support it because it reduces their cost of production i.e. they're thinking in the immediate short term and not the strategic outcome. 

Such a deliberate move by a commissioning company - the chess equivalent of Fool's mate - should never work but it does, in industry after industry. Yes, I am saying that companies often support the commoditisation of an underlying component or constraint without realising this will reduce barriers of entry into their field and ultimately commoditise them. Companies seem to act thinking of the short term with no understanding of the impacts to themselves. 

Most of the problem appears to be that companies cannot see the environment (i.e. they have no map) and aren't used to any actual form of strategic play. To be honest, this is like stealing candy from a baby except the candy is worth millions or billions. What is really frightening, is it takes a couple of hours to map out and work out such a play. There is no way on earth you should be able to get away with this and I'm afraid it gets worse.

This particular move is one of a set of very basic approaches (see figure 4). I'm always surprised by how many companies don't even use these basics in a co-ordinated fashion. This is kindergarden stuff in the world of strategy and we're going to see a lot of big name casualties over the next decade caused by truly poor gameplay.

Figure 4 - The most basic attacking & defensive moves.

However, the death of companies is not the point of this post. What I'd like people to realise is that many companies have little or no strategy and they're not actually used to playing the game. They instead rely on communication tools like SWOT or Business Model Canvas (which are both great communication tools) that lack any context. 

These companies aren't playing chess against each other, they have very little idea what the board looks like. Which, if you're a start-up is great news. Don't fear the giants, they're easier to take out than you'd expect.

-- Addition

The importance of where over why

One thing I'd like to also reiterate is the importance of where to attack. Why is a relative statement i.e. why here over there and so any strategy should start with the where. In figure 5, I've marked on the two "wheres" that you could attack.

Figure 5 - Where can we attack

One "where" is to attempt to commoditise the creative studio space. The problem of course is the constraints will still exist, the creative studios will resist and you'll be in direct competition with the studios which you use as suppliers etc. In all likelihood, you'll probably create a war on talent and end up increasing your cost of program production.

The other "where" is to attempt to commoditise the production systems. You'll have resistance from the vendors in that space but assuming the creatives studios don't understand the game, they'll probably support you (for reasons of short term reduction in their costs). You could deploy an open approach here (e.g. open source, open hardware, open APIs) and the effect of commoditising this space is likely to reduce both the constraints caused by expensive production systems but also the talent constraint by making it easier for people to get into the field. The net effect will be to commoditise the creative studio business - which is what you're after.

So, you have two "wheres". The "why" you should attack one over the other should be self obvious by now. 

As a word of warning, if you ever employ a strategy firm then if they start talking about the importance of why, simply ask them to explain the "where" to you first. If they bluster, you know you've got a dud. Get rid of them quick - they're costing you oodles and you'll get nothing of real use.

PS. Don't ask me for strategy advice / consultancy - I don't do this, I'm not a gun for hire. I research on behalf of the LEF members. My ONLY advice to you is learn how to map and play the game.

Friday, November 28, 2014

There are many chasms to cross ...

Consider the evolution of an activity such as computing infrastructure. Let us start with the genesis of the act of modern digital infrastructure (arguably the Z3 in 1943) and progress through the waves of improvement and disruption that have followed until eventually we end up with a commodity provided through utility services.

The evolution of an act isn't a smooth process but has many released improvements each of which will diffuse in society. If you examine the diffusion curves for each improving version, they generally have different time length and market sizes (i.e. they're not uniform, each goes to 100% adoption of a different applicable market) - see figure 1.

Figure 1 - Diffusion of multiple improving states of an act - from A1 to A5

However, by examining ubiquity of an act and certainty (i.e. how complete, well understood and well defined an act is) then you can measure this progress of evolution. I've provided an illustration of this in figure 2.

Figure 2 - Evolution of an act - from A1 to A5
So, if we think of computing infrastructure then :-
  • We started with the genesis with the Z3
  • We have multiple custom built examples e.g. LEO as companies and individuals explored the potential.
  • The act of computing infrastructure evolved (i.e. became well defined and widespread enough) that the first products (e.g. IBM 650) appeared.
  • We had multiple waves of ever improving products. Some of these waves disrupted previous products - mainframe, minicomputer, server.
  • Overlapping this time, we had the introduction of rental services.
  • Computing infrastructure became so widespread and well defined that commodity servers were introduced (volume operations based, highly standardised etc).
  • Being widespread, well defined and with a suitable delivery mechanism (the internet) then computing infrastructure became provided as utility services (e.g. Amazon EC2).
Now, it's important to understand that the evolution curve is made from hundreds of diffusing and ever improving versions, some of which disrupted past examples and some which were incremental improvements.

So, where is the chasm in this? There are many chasms not one. If you think back we've had chasms for utility computing, client / server, mini-computing, mainframe and even the original adoption of computing. During this time, computing infrastructure (as in the act) hasn't changed - it's still all about provision of compute processing & storage. Just the mode of operation and delivery mechanism has evolved.

So when you look at the evolution of technology (e.g. figure 2) then there isn't a single chasm. Evolution has many hundreds of diffusing changes involved each with potentially their own chasm. Hence when you think of computing infrastructure then :-
  • There was a chasm in the early stages (the original computers).
  • There was a chasm when computing went from custom built to products.
  • The have been multiple chasms involved with each major product change (mainframe, minicomputer, client/server etc) as the act evolved.
  • There was a chasm involved in the introduction of commodity servers.
  • There was a chasm involved in the introduction of utility servers.
If you're looking for the chasm involved in the evolution of computing infrastructure, I'm afraid you won't find one - you'll find many, almost as many as there are separate diffusion curves (for each evolving instance) and examples of incremental and disruptive changes.

Fortunately, from a perspective of mapping - there exists only one evolution curve. Which is why we can map a business. Without a single evolution curve then mapping would be impossible (this is why we can't map over diffusion, hypecycle, system of record / engagement etc).

Sunday, November 16, 2014

How we used to organise stuff ..

In the early days, we used to apply one size fits all methodology because we didn't know better (see figure 1, which is a system provided in a map form). We used to yo-yo between methods but in 2002, most of us in the open source world had gone "all agile" whilst the enterprise was mainly "all waterfall and all outsourcing". Under such a model, the IT organisation is one large hierarchical department and one attitude. Be warned, single methods fail to deal with evolution and tend to run into excessive change control cost overruns.

Figure 1 - circa 2002 - One size rules all, OK!

By 2004, in the open source world, we had learned that one size fits all didn't work. We had started to work towards the use of multiple methods. We knew agile was suitable in the early stages of evolution of an act but we also knew six sigma was better for more evolved activities. The foolhardy amongst us had started to organise by this "bimodal" fashion with groups such as common services or systems and development (see figure 2). Under such a model, the IT organisation is two groups in a hierarchy and two polar opposite (usually competing) attitudes - a bit more "bipolar" than anything else. Be warned, these structures tend to fail to hand over activities and lead to lack of industrialisation of common components, spaghetti junction and platform rewrites. 

Figure 2 - circa 2004 - Bimodal rules all, OK!

By 2005 to early 2006, many of us had learned that the jump between the novel and the industrialised was too large. We needed a third group and a different set of methods, techniques, culture and attitudes to cope with this. Structures that took this into consideration started to appear, in some cases we formalised the "missing" group in our "bimodal" structures e.g. we went from development and common services to development, framework and common services. This three party system was also applicable across the entire business as a pioneer, settler and town planner structure (see figure 3). Under such a model, the IT organisation is three groups and three overlapping attitudes which can be made to work in concert through the use of theft (i.e. enforced evolution). Be warned, such three party structures contain strong hierarchies and still tend to create large groups creating communication and other issues.

Figure 3 - circa 2005 / 2006 - Trimodal rules all, OK!

By 2007 to 2009, we had started to learn that we needed to deliberately divide our organisations into self organising cell based structures e.g. a starfish model, two pizza models etc (see figure 4). It wasn't the case that we weren't doing this, it was more it had been a coincidence rather than a deliberate informed decision. Under such a model, the organisation is broken into many small groups but it has no specific attitude and no means of dealing with evolution. Be warned, whilst many of the communication and growth issues are better handled, the lack of means of managing evolution can create problems itself. The structure itself still has a hierarchy for management of the cells (often through fitness functions i.e. defined criteria for performance) but the cells themselves are autonomous.

Figure 4 - circa '07 to '09 - Cell based structure rules all, OK!

Sometime around 2012, a few of us had started to look at deliberately combining both cell based structures and using three party concepts to cope with attitude, heavily using techniques developed in the military to create more adaptive structures (see figure 5). Again, it wasn't the case we hadn't done this before, it was more a case that we didn't realise that we had been doing this and now needed to formalise it. Under such a model, the organisation is many small groups and three overlapping attitudes which can be made to work in concert through the use of theft (i.e. enforced evolution). The structure blends both attitude and aptitude with autonomous cells operating in a management hierarchy. 

Figure 5 - circa 2012 - Adaptive structure rules all, OK!

By 2014 ... be warned, this process is ongoing. The above leads naturally to administrative structures (covering training, culture and attitude) along with what can be loosely described as "battle groups" formed to implement a line of business. The closest there is to something that remotely resembles this sort of structure can be found in military organisations which have had many hundreds of years to learn how to combine attitude, aptitude, hierarchy and autonomy into a useful structure. The majority of organisations are still at the very beginning of one department and one attitude. Once again, this idea of "pools" of resource is not new, it's more a case of formalising what had been achieved through experimentation  but we had yet to realise the importance of it or why it worked at the time.

It might sound a bit odd but the formalisation of a method comes a long time after experimentation. That we had blindly fallen into a pioneer, settler and town planner structure using small teams back in 2005 is one of happy accident and fiddling. It took many years to realise what we had stumbled onto. Any illusions of great thought followed by implementation should be banished from the mind. This was always a case of fumbling in the dark and later on realising you had managed to accidentally pick up and put in your pocket a priceless treasure.

Three things to note ...

1) Don't think for one second anyone knows the best way of organising stuff in business - we don't. All we know are better ways than the past. Anyone who tells you they have the perfect way is talking horse.

2) Mapping an environment really helps with organisation or at least the exploration of the possible ways we might organise.

3) The use of mapping and high levels of situational awareness is a necessity for coping with evolution unless you have exceptionally talented people who understand that things evolve (i.e. they have their own mental models, can cope with inertia etc). Without extremely good situational awareness then I'd suggest you go for a cell based structure and hire rock star developers who work well with others.

Friday, November 14, 2014

How to get to Strategy ... in ten steps!

I was asked by someone whether I could help with a particular strategy. My response, was rather simple ... you do steps 0-9, I'll help you with ten ... all in graphical form. There really isn't much point to start with step 10 until you've done all the previous steps.

Thursday, November 13, 2014

Bimodal IT - the new old hotness

I've recently come across a concept known as Bimodal IT. I couldn't stop howling with laughter. It's basically 2004 dressed up as 2014 and it is guaranteed to get you into a mess. So we better go through it.

I'm going to start with a map. Now, as we know the map of a business contains many components organised into a chain of needs (the value chain) with the components at differing states of evolution. As components evolve, their properties change (from uncharted to industrialised) and different methods of management become appropriate (see Salaman & Storey, the Innovation Paradox, 2002). Hence components in the uncharted space use in-house, agile techniques, quick release cycles, highly iterative etc. Whereas those more industrialised components tend to be six sigma, ITIL, long release cycles, heavily standardised etc (see The Sum of All Fears, Butler Group Review, Dec 2007).

When it comes to organising then each component not only needs different aptitudes (e.g. engineering + design) but also different attitudes (i.e. engineering in genesis is not the same as engineering in industrialised). To solve this, you end up implementing a "trimodal" (three party) structure such as pioneers, settlers and town planners which is governed by a process of theft. Ok, this is all old hat, circa 2005 and I've summarised it in figure 1. 

Figure 1 - Map of components in a business

So lets speed on and discuss what's wrong with bimodal.

The problem with bimodal (e.g. pioneers and town planners) is it lacks the middle component (the settlers) which performs an essential function in ensuring that work is taken from the pioneers and turned into mature products before the town planners can turn this into industrialised commodities or utility services. Without this middle component then yes you cover the two extremes (e.g. agile vs six sigma) but new things built never progress or evolve. You have nothing managing the 'flow' from one extreme to another.

For example, you start off with a new platform designed for the future on top of which your pioneers build new things. But unfortunately pioneers aren't usually so good at making rock solid and mature products, they're more pioneering. Of course, your town planners won't want to industrialise something which isn't a rock sold and mature product, it's too uncertain for volume operations. You end up with this stalemate that the new thing never gets turned into an industrialised service. Instead what happens, is something even newer gets built on top of your non industrialised component. And this continues with new things built on layers of components that are not fully industrialised. It becomes kludge on top of kludge on top of kludge.

Eventually, after five years or so then this creates spaghetti junction. It is an environment which becomes unmanageable - performance sucks, reliability disappears and costs spiral. You get everyone to together and the new idea is always to build the new "platform for the future". You then spend vast sums of money, create the new platform and repeat this exercise all over again.

This has occurred in almost every company that I've seen in the last decade using bimodal approaches for any period of time. I've seen many billions blown on the same mistake of pursuing solutions which fail to cope with evolution (e.g. one size fits all, outsource everything, bimodal etc) - we will have R&D over here and shared services over here and it will all work! Think again. Its why people use alternatives such as a cell based structures or a trimodal system (e.g. pioneers, settler and town planners) or a combination of both. 

The whole purpose of the settlers is to productise i.e. to take the early stage work of the pioneers, and iteratively mature it until the town planners can finally industrialise it. They are absolutely essential to the functioning of such structures. Remove it at your peril.

Of course, bimodal is still "better than the madness of one size fits all" (e.g. agile everywhere or six sigma everywhere). Maybe in the short term but you're still going to end up with SNAFU. So, think trimodal. Be a bit more 2005 than 2004, even though it's 2014. Create a virtuous cycle of theft (see figure 2).

Figure 2 - Pioneers, Settlers and Town Planners

On that note, I can't believe people are flogging Bimodal IT as something new in 2014, that's taking the piss. Next week Gartner researchers will be telling us they've just invented the "internet" or the "wheel". Be under no illusion, bimodal plus time can go horribly wrong - seen it, done it, bought the T-Shirt.  Let me just reiterate that point. I'm telling you from the experience of having used both bimodal and trimodal forms over the last decade that bimodal is not what you want to do.

Apparently though Gartner's bimodal model has both pioneers and settlers in 'mode 2' group and Town Planners in 'mode 1' group. Whilst the language Gartner use - industrialisation, uncertain, non linear - is all familiar, the justification of combining these groups to form a bimodal is highly suspect in my view.

When I wrote my Butler Group Review Article in May 2008 on the need for use of multiple methods within an organisation (e.g. Agile and more "Waterfall"), we already knew back then that you couldn't organise by this bimodal fashion because of the problems it had caused. You need that missing middle (the settlers) that dealt with the transition.

Now, I haven't read Gartner's recent research on this subject (I'm not a subscriber) and it seems weird to be reading "research" about stuff you've done in practice a decade ago. Maybe they've found some magic juice? Experience however dictates that it'll be snake oil and you really need to separate out the three groups. I feel like the old car mechanic listening to the kid saying that his magic pill turns water into gas. I'm sure it doesn't ... maybe this time it will ... duh, suckered again.

--- Update 14th Nov 2014
One thing I haven't made clear in this post and need to is where did the idea of implementing a three party, trimodal way of working such as pioneer, settler and town planner come from?

From my perspective then the origin of deliberately implementing this structure was James Duncan, now a CTO within UK Gov.  It started all those year ago, back in the days of Fotango when I was CEO. I was frustrated by several things - how the organisation worked, the lack of any competitive map to describe our environment , the compete blah of what was called strategy etc.  I'd shown James my work on mapping and evolution. We worked together on this to refine the whole Fotango plan. It was a time of exploration for me and James was my cohort in this (which is why I use the term Wardley-Duncan Map occasionally.  Well, credit is due).

However, it was James (who was the CIO) that proposed to me a three party structure within IT. It sounded right, I couldn't say why but I was happy to go with it and I was delighted by the outcomes that resulted. I then started to fold the rest of the company into this model. Now, I'm not saying others didn't have a similar model just from my perspective it was James Duncan who started this particular aspect of my journey. Sometime around 2004.

It's also true that back then I couldn't fully explain why the trimodal approach worked so well - in fact many of our successful experiments were hard to explain. All we had was the practice and the result. It took a bit longer for all the aspects of mapping and evolution to become clearer before the reasons why it was a good move stood out. I mention this because mapping, the use of multiple methods, the work on ecosystems, open source and organisations - all started with practice & observed outcomes first. Understanding why came a bit later.

--- Update 14th Nov 2014
One final thing to mention, my disapproval of bimodal IT assumes that CIOs are trying to use it to fix a problem by using a flawed approach. I've now come across an example where it is more being used to "bolt on innovation" in much the same way that some companies are not adapting to digital but instead "bolting on a CDO". This is akin to adding lipstick to the pig.

I'd argue that this indicates an additional organisational need which is removal of its technology leadership. In such cases, a CDO is not only needed but should replace the CIO. But how do you now?

Well, next time you have the chance to chat with the CIO, just ask what they think of the Bimodal IT approach. If they're positive, that's fair enough it's not too deadly a sign. But use the vernacular and ask "When our Sprinters have created something new, then overtime it'll become like the stuff the Marathon runners provide. How are we going to manage that?"

If the response is "they'll just hand it over" or you get hand waiving warble or you get any sign of confusion then you know you probably own a well lipsticked pig.

-- 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 and 21 years before Gartner came up with this rather lame bimodal concept.

I owe Robert Cringely a debt of thanks.

Monday, November 10, 2014

The Enterprise is slower than you think

In the late 1990s, I had taken an interest in 3D printing. It was one of the main reasons I joined Fotango (a small but failing online photo startup) because of my interest in the distribution of images.

In 2001, I was the CIO of Fotango and we were acquired by Canon. 

By 2002, we became an open source and agile (XP) development shop. We extensively used and provided web services. We lived online. We started to get involved more directly in open source projects particularly Perl. We built a centre of gravity to attract talent to the barren technological wasteland that was Old Street.

By 2003, I was the CEO. We operated an environment which had started to use mixed methods (i.e. we learned that Agile wasn't appropriate everywhere). We had introduced paper prototyping for design and worth based development techniques (known as outcome based techniques today).  We focused on the user need. We had BYOD, a wireless office, remote working. We had replaced the company intranet with a wiki and had started to explore alternative mechanisms of communication (core parts of what is now called Enterprise 2.0). We built multiple systems for others and we were profitable. 

By 2004, we had started developing our own private IaaS (though it wasn't called that back then). The system, which included creation of virtual machines through APIs and configuration management tools (based upon CFEngine) was known as Borg. We had developed continuous deployment mechanisms, extensive monitoring and started mapping our own environment to determine new game plays and opportunities. We had started running mini conferences. We had introduced conference funding, started to promote our open source work and started working on the idea of providing public API services.

By 2005,  we had simplified internal procedures such as HR (removed timesheets, holiday forms etc) and looked towards using commodity services where possible. We had launched the first iteration of a public Platform as a Service (this become known as Zimki the following year). We focused on industrialisation of key aspects of building a platform. We understood how to play an open source game, create a competitive market and exploit an ecosystem and their network effects. We had converted most projects to outcome based metrics, we had started to introduce a new organisational structure based on evolution, we had common web services running through dozens of large public facing systems.

So why do I mention this? 3D printing, continuous deployment, agile, mixed development methods, open source, building centres of gravity, cloud, building and stitching together small discrete web services (microservices), ecosystems, IaaS, PaaS, BYOD, Enterprise 2.0, Hack days (we introduced in 2006), focus on user needs, outcome based approaches ... these are all 'hot' words in the Enterprise today. 

But these "words" weren't born out of ideas but practice from a decade ago. Oh, if you think we were first - you must be kidding. We thought we were slow compared to our compatriots and competitors.

That is I'm afraid the point. I hear these words often spoken as something new within the Enterprise. Well, it maybe new to an Enterprise and it maybe new to some of your competitors but don't kid yourself that you're doing anything other than trying to catch up with where the edge of the market was a long time ago. The cutting edge of the Enterprise market is about a decade behind the edge of the market. An early adopter in the Enterprise world is still a laggard.

But why? Competition. 

You don't need to be near the edge unless your competitors are there as well. Which is probably why some traditional enterprise companies do so badly when companies like Amazon or Google move into their space. They're not prepared for the level of competition needed.

But that's why we need to adopt "3D printing, continuous deployment, agile, mixed development methods, open source, building centres of gravity, cloud, building and stitching together small discrete web services (microservices), ecosystems, IaaS, PaaS, BYOD, Enterprise 2.0, Hack days, focus on user needs, outcome based approaches" I hear some cry or more importantly their anointed consultants cry. 

It won't help you. Instead you need to think of the above list as stuff you've been doing for a decade (where the puck was) and work out what new things you'd have built on top of this during that time (where the puck is). Then you need to look forward five years (where the puck will be). That's where you need to be heading.

Thursday, October 16, 2014

Of Peace, War and Wonder vs Company Age.

One of the more interesting discussions in recent times has been Prof Jill Lepore’s arguments against Clayton Christensen’s concept of disruptive innovation. In her now famous New Yorker article, Lepore argued that disruptive innovation doesn’t really explain change, but is instead mostly an artefact of history, a way of looking at the past and is unpredictable. This really is a non-argument because both Christensen and Lepore are correct. The problem stems from the issue that there are two forms of disruption - one of which is predictable and one which isn't.

The two main forms of potential disruption are product to product substitution and product to utility business model substitution. 

With product to product substitution then the predictability of when (depends upon individual actors’ action) and what (genesis of some new feature or capability) is low (see figure 1). This means a new entrant can at any time create a disruptive product but a company will have no way of ascertaining when that will occur or what it will be.  So whilst disruption will occur (as Christensen points out), it is unpredictable (as Lepore points out).  Apple’s iPhone disrupting the Blackberry is a good example of this type of disruption.

Figure 1 - Predictability.

With product to utility substitution the “what” and “when” can be anticipated. Hence a new entrant can more effectively target a change to disrupt others. However, it also means an existing player can effectively mount a defence having prior knowledge of the change and time to prepare. Fortunately for the new entrants, the inertia faced by incumbents in terms of existing business models, developed practices, technological debt, behavioural norms, financial incentives to Wall Street expectations and self interest are often insurmountable, so the start-ups often win.  Hence, whilst the change is entirely defendable against (with often many decades of prior warning) companies fail to do so. This form of disruption is entirely predictable and it is here where Christensen's theory excels.

Now product to utility substitution is a key part of the commonly repeating cycle of peace, war and wonder that we've discussed extensively about. The 'war' element can be anticipated and the cycle occurs both at a macro and micro-economic level.

You can even model out the potential impact of this cycle on company age. Creating a simulation with 1,000 actors, assuming all actors are in competition, that the largest companies start with an age of 45 years, there exists some unpredictable disruption from product to product substitution and no peace/war/wonder cycle then you can graph out the emergent change of company age with the top 400 due to new entrants and previously successful companies failing. I've provided the output of such a simulation in figure 2.

Figure 2 - No Peace / War / Wonder cycle

In the above the average age remains fairly constant over time (shown as sequence steps of the model on the x-axis with each step of the model being analogous to a year). This is because whilst companies age, there is some substitution by new entrants counteracting the growing age. 

This requires a set of specific conditions including a moderate level of disruption from product to product substitution (3% p.a.) but I'll use this simulation as our base line. By adding in the peace / war and wonder cycle, starting with a condition of 30 steps (e.g. years) for an act to evolve from genesis to commodity and 10 steps (e.g. years) for a commodity to disrupt an existing industry then the following pattern (figure 3) emerges.

Figure 3 - Company Age with Peace / War and Wonder Cycle

What's happening now is a constant undulation in average company age as the environment moves through these cycles. It constantly attempts to return to a higher average age but the constant 'war's and disruption by new entrants (on top of the normal product to product substitution) keeps this in check.

Of course, one of the interesting aspect of the peace, war and wonder cycle is that this not only affects all activities, practices and data but these components can be communication mechanisms. Such communication mechanisms (e.g. telephone, postage stamp, Internet etc) will increase the rate of diffusion of information which impacts the speed at which evolution occurs. This in turn accelerates the speed of the peace, war and wonder cycle.

Rather than a case of we are becoming more 'innovative' as a species, it appears that the speed at which things industrialise (i.e. evolve to more commodity and utility forms) and hence the rate at which we are forced to adapt and move onto the next wave has accelerated. If you now add this communication impact into the simulation (i.e. assume some of those peace, war and wonder cycles impact communication causing a subsequent higher speed of future cycles) then the following pattern emerges (see figure 4).

Figure 4 - Company Age with Peace / War and Wonder Cycle plus Communication impacts.

What's happening is the system is constantly trying to maintain an age but the peace / war and wonder cycle is causing oscillations arounds this (due to new entrants and failure of past giants). However, the acceleration of the cycle (due to commoditisation of means of communication) is causing a shift downwards to a lower age (and a new stable plateau around which age will oscillate).

However this pattern is highly influenced by the ability of the agents to adapt (i.e. if we assume high levels of situational awareness and the ability of companies to evolve then this pattern doesn't happen and a completely different pattern of dominance emerges).

I mention this because the same pattern in a simulation - which is derived from supply and demand competition causing evolution and the interplay with inertia causing the peace, war and wonder cycle  - can also be seen in the graph of S&P500 company age over time by Foster (see figure 5)

Figure 5 - Variation in average company age with S&P500

You have the same undulation that is caused by peace, war and wonder cycles plus a decline in average age which would be expected from commoditisation of the means of communication and acceleration of the cycle (e.g. Telecommunication, the Internet etc).

So, why mention this? Well, I'd argue that what we're experiencing is all perfectly normal. The system is rebalancing to a new company age around which it will oscillate. There are many ways of countering this effect by exploiting predictable change (which is unknown to many) and through the use of ecosystems but that's another post for another day.

The good news is that most companies have appalling situational awareness and so it's very easy to exploit. I've only been involved in three startups (all sold to large companies) and I've used these techniques in working for Canonical (we stole the cloud from RedHat) and Governments. It's amazing how much power a little situational awareness and understanding of common economic patterns gives you.

--- Update 17th October

After talking with Florian Otel, a smart cookie and always a good chat, I decided to run the simulation above several times to see if we could get it to mimic real life.

After a bit of trial an error, I set the starting company age at 50 years, with each step of the model representing 270 days, a low product to product substitution rate, a higher rate of disruption from the 'war' phase of the cycle (i.e. extremely low levels of situational awareness and ability to adapt in the agent), a base time to industrialise of 30 years, a time to disrupt once industrialisation starts of 15 years, a set of peace/wonder and wonder waves each impacting communication, a 7 year rolling average of the top 400 companies, 1,000 competing companies (actors) and an initiation time of April 1937.

I ran the simulation 10 times, because each step in the simulation is probability based and each actor therefore has a chance to age or be disrupted or disrupt others in each step. Hence after each simulation is completed, different actors have died or taken over etc. No two simulation runs are identical.

Figure 6 provides the overlapping result of 7 year rolling average of company age for all ten simulations on a single graph. A very strong emergent pattern can be seen which doesn't do a bad job of mimicking real life.

Figure 6 - Approximation of Real Life through Simulation

It's not a bad approximation to Foster's graph but it's by no means perfect. There's some variation in the simulation when re-run (as can be seen by the different lines in the graph). The times are not perfect (often being out from real life by many years) nor is the shape identical however it should be remembered that in the simulation the agents actions are random but in real life we have the ability to anticipate change - I'll come back to that point.

I've overlapped both Foster and in the Simulation on the same company age / time axis scale in Figure 7.

Figure 7 - Comparison of Foster to Actor (Agent) based Simulation

Now, not a lot can be inferred by this. It's an agent (actor) based simulation which creates an emergent pattern which approximates real life. It reinforces the internet (1991), cloud computing (2008) and information technology revolution (1967) as key moments of industrialisation of communication. It's not bad though and gives food for thought.

However, one key thing was very noticeable and that's the point about anticipation. The model only ever comes close to mimicking real life when the agents themselves act as though they have little to no situational awareness and ability to anticipate change hence creating high rates of disruption in the war part of the cycle. If I'm going to infer anything from the model, it would be the implication that most companies are running blind.

Sunday, October 12, 2014

On maps, component class, pipelines, markets, inertia and economic states.

When drawing maps, I often use different symbols to represent different aspects of competition. For example, since activities, practices, data and even knowledge evolve then I'll often mark these aspects on the map (see figure 1).

Figure 1 - Activities, practices, data and knowledge.

With most maps, I tend not to mark up the different component classes unless it is useful. When it is useful then in practice though I might add a legend to show the different class of components (activities to knowledge), I tend to not fully write out the process of evolution for each class on the evolution axis - it becomes unwieldy.  I simply use the evolution of activities to represent the different publishing type I to type IV of evolution. 

It's worth remembering that maps (even geographical maps) are simply a representation of the space. 

In some cases, within a map there will be a pipeline of constant change e.g. content for publishing. I'll normally mark this on (as with the case of the TV industry in figure 2).

Figure 2 - A content pipeline

When scenario planning, I'll tend to add on different markets to show comparison to the market in focus. I'll also add on further contextual information such as price elasticity, known forces (buyer vs supplier), known constraints and known difference between the company and the market (usually a dotted red line identifying a delta or a solid red line indicating a difference). An example of this is shown in figure 3.

Figure 3 - Comparison to market.

I'll also add on potential force multipliers (e.g. ecosystems), potential sources of inertia, likely points of change (a grey dotted line) and general comments or areas of interest.

Figure 4 - Ecosystems, inertia, points of change and areas of interest.

Lastly, I'll add different competitive states (peace, war and wonder), current and future states, competitive forces and potential for impacts. See figure 5.

Figure 5 - Competitive states and competitive forces.

The final maps I produce tend to contain elements of all the above. They are complex but then, so is competition.

When scenario planning then all of these components from activities, practices and data, to inertia, competitive forces, constraints, economic state, points of change, ecosystems, comparison to other markets, buyer vs supplier relationships, pipelines, elasticity and other compound effects (co-evolution, Jevons' paradox etc) need to be considered. Trying to do this in your head without a map i.e. a way of visualising and discussing a landscape - is almost impossible for any complex business.

Saturday, October 04, 2014

Something that will change the world of competition ...

One of the most powerful force multipliers in competition is the use of an ecosystem model known as ILC built around a utility service. This model has been in operation for about a decade and can be shown to create network effects in terms of innovation, efficiency, customer service and stability of revenue. There's nothing quite like it but since it's old hat, I won't go through it again.

However, the ILC model doesn't work quite so well in the product space (because the capture of consumption data requires expensive market research) nor in the physical commodity space (again there is no way of capturing consumption data).

This is all about to change. 

Sensors are getting to the point of being industrialised to commodity components that will capture and centrally store data through a "Sensor as a Service". Future products, even physical commodities will contain multiple "Sensor as a Service" components. This provides the capability for ecosystem games like ILC to be played out in the physical world. 

Supplier companies will start providing low cost commodity sensors with an attached Sensor as a Service capability as a highly industrialised platform. Other companies will deploy these components into their products, new inventions and hence an ecosystem will build around these Sensor as a Service. The benefit for the deploying companies is the sensors will be low cost and the Sensor as a Service will provide either data aggregation, market comparisons (performance compared to other sensors) or a range of other useful capabilities. Whilst useful for lowering cost of experimentation and product implementation for the deployer, the real beneficiary is the supplier. 

The supplier can play the same trick that happens in the digital world of not interrogating what the sensor is doing (that'll be private to the company deploying it) but simply monitoring consumption through the Sensor as a Service to identify the spread of new successful innovations (whether genesis of a new act or a product differential). It's no different to the ILC model but now played out in the physical world and it will have the same impacts. 

From figure 1 below - you industrialise a component activity representing a sensor (A2) to a more commodity form (A3) which is provided with a Sensor as a Service capability (e.g. data and / or code with some form of connection to a remote API). Other companies then build new inventions / feature differentiation (B1, C1, D1) on top of the Sensor (A3) because it is provided at very low cost and hence reduces their risk of experimentation. You then simply monitor consumption of the API to identify what changes have been successful and when identified you aim to commoditise any component (D2) to a future Sensor service and repeat the game - you get everyone else to Innovate, you Leverage the ecosystem to spot success, you Commoditise - ILC.

Figure 1 - ILC Model

For example, let us suppose we were Amazon (they are very good at ecosystem games) and with big data becoming a rapidly industrialised component (already services like BigTable and EMR exist) and CCD being a fairly commodity component then let us hypothesise that we introduced a CCD Sensor as a Service. For makers of devices which include CCD, they would get low cost CCDs and a service telling them about the performance of their CCDs in the wild, maybe some other data aggregation capability (even to the point of customisation to location / time given environmental conditions). Of course, as the supplier, we would get to know what products (in which our sensors are deployed) are rapidly growing and being used regardless of who is making or selling them or the data being transferred. This is achieved by simply looking at consumption of the service, the actual sensor data being private to the deploying company. This is incredibly useful for the supplier and why ecosystems are powerful future sensing engines.

The net effect will be the same as the digital world. The supplier will start to simultaneously exhibit :-
  • rapidly growing rates of innovation - it's in fact the ecosystem that is doing the innovation for it. 
  • rapidly growing rates of customer satisfaction - by using consumption data to pick successful changes in the ecosystem and then providing this as new components to everyone else
  • high rates of efficiency - simply economies of scale
  • high stability of revenue - through provision of industrialised components and reduced risk of experimentation (everyone else is taking the risk)
  • eventual grumbling - as other companies start to complain "they've eaten our business model again"
There's a whole new world approaching where ecosystem games (from gaming theory to open source as weapon) can be re-applied in the physical world. Competition from physical engineering to healthcare is going to get seriously interesting. We've seen early starts in this space over the last couple of years but it is building. Key to success of course will be to position yourself as the supplier of commodity sensors with the Sensor as a Service attached i.e. you need to identify those sensors suitable for such a game, industrialise to components and start building the ecosystem of other companies building on top of it (see figure 2 for a rough simplification of the game).

Figure 2 - high level map of the game

That's the really interesting thing about the Internet of Things. The real battle will be over the underlying components and ecosystems that are built around this. Sensors are sexy - well, if you're a competition nut like myself. You don't want to be the device manufacturer, you want to be the component sensor as a service in every other manufacturers device.

Oh, and the best news is ... most of the competitors in this space probably won't see this coming (poor situational awareness), they'll focus on the device and communication between devices whilst you can start to build up in underserved markets. When it finally hits then combined with inertia, this will be one of those predictable forms of disruption that any start-up can have a field day in. There's a few billion to hundred billion dollar companies to be made in this space.

How do I know this? Well, I don't - well not for definite. With another 7,200 days of data collection I could be more conclusive (or not) but alas that's another story. At the moment, I'd advise taking the above with a pinch of salt as with any other prognostication on the future unless you're a start-up in which case I'd say 'you become what you disrupt'.  It'll take 10-15 years before this space really kicks off, so it's time to start building now.

There's a lot of future value in sensors and sensor ecosystems.