Saturday, February 06, 2016

From purpose to leadership and back again.

I haven't written in a while, so I thought I'd put down same rough notes on managing an environment. Contrary to popular belief, management isn't some linear game of planning but a highly iterative cycle. It's best described (in my opinion) in the following diagram by combining Sun Tzu with John Boyd.

Figure 1-  Tzu and Boyd.

The first part is to understand your purpose i.e. your scope and your moral imperative (the reason why others follow you). Your organisation consists of value chains but it operates in the value chains of others. So you need to understand what you are and who you interact with. This is the game that you are playing in for the time being. Please note that the process is iterative i.e. your leadership and action may well change the game you are playing in. There is no such thing as core to a company, it's all transient i.e. Nokia's purpose changed from when it was a paper mill to when it became a telecommunications provider. You are, in the words of Deng Xiaoping, "crossing the river by feeling the stones" or in other words, the best you can do is to have a direction and be adaptive.

Now, once you have a scope you need to understand your landscape. This is what we call situational awareness and it requires a map. To create a map you need several things. First you need an anchor (e.g. in chess it's the board, in a physical map it's the compass). Then you need the position of pieces relative to the anchor (i.e. the co-ordinates on a chess board for the queen or this unit is NW of this position in a map). Finally you need movement i.e. where the pieces have been and where they can go.

To do this in business, you can use a Wardley map. The anchor is user needs. Relative position is given in a chain of needs anchored on the user. Movement is provided by evolution. Be careful here, I often see utter howlers with people using diffusion as a replacement for evolution. They are not the same thing. An example map is given in figure 2.

Figure 2 - An example map.

There's a lot of things which call themselves maps but without position and movement, they're not a great deal of use for learning. There's another concept worth noting called flow i.e. flow between components (whether information, risk or money) but that's a little bit advanced for this post. It's also one that people regularly make a hash of by making ineffective flows more efficient

One you have a map, you need to understand the climate. Fortunately from the use of maps or boards, you can infer the rules of the game over time. You can do the same with Wardley maps. There are many rules in the business climate. For reasons of brevity, I'll just mention 13 of the simplest.


1. Everything evolves : due to supply and demand competition.

3. No one size fits all : whether project management (agile vs lean vs six sigma) to purchasing to outsourcing.

4. Efficiency enables innovation : it's faster to build new things with pre-existing components than to start with everything from scratch.

5. Increased stability increases agility : an effect from componentisation.

6. Higher order systems create new sources of wealth : e.g.  standard electricity enables TV.

7. Capital flows to new areas of value : either the more commoditised form or moves up to the higher order systems. This is a key part of creative destruction.

8. No choice over evolution : the Red Queen effect.

9. Change is not always linear : known as a punctuated equilibrium

10. Success breeds inertia : There are in fact at least 16 different forms of inertia each with their own tactical plays to resolve.

11. Co-evolution : e.g. practice with activity, see DevOps.

12. Inertia kills : e.g. Blockbuster, Kodak. Neither of these companies were taken out by lack of innovation (they both out innovated the market). It was there pre-existing business models that hit them.

13. Disruption comes in multiple forms : there are many different forms but the two worth knowing about are predictable and non-predictable.

Once you understand the basic rules of climate (i.e. the rules of the game) including the various forms of cycles (e.g. peace, war and wonder) then you can do a pretty reasonable job of anticipation by using the map. But you need to know how to organise yourself around the map. Here we're into context free doctrine. By this I mean doctrine that applies in almost all situations regardless of the context (i.e. the environment). There are many of these but again for brevity I'll just mention seven.


1. Focus on user needs : start with transaction and then onto customer journeys. It's essential to focus on the user need and you won't be able to map without it.

2. Use appropriate methods : i.e. use agile or six sigma where appropriate

3. Remove bias and duplication : you can use multiple maps to do this fairly easily. 

4. Fast, Inexpensive, Simple and Tiny : go read up on Lt Col Dan Ward and FIST.

5. Use small autonomous teams : e.g. cell based structures, think Two Pizza (AMZN) or Haier. 

6. Think aptitude and attitude : e.g. pioneer, settler and town planner. This is still an area we're learning about

7. Eat your own dog food : i.e. don't sell what you're not prepared to use yourself.

At this point, when you're playing the game then you should have a good understanding of your purpose, your landscape, the climate and doctrine to be used. At which point we can add gameplay. Alas, there's a vast array of different forms of context specific gameplay that I'm now aware of. It's a bit like Chess or Military combat where there is all sorts of standard moves depending upon the context of the board or map. When playing the game you often use multiple at the same time.

There are lots we could go through but I'll just mention one as an example in business - the use of fool's mate - which is to attack an underlying part of the value chain when you wish to shift a higher order part of the same value chain.

The combination of the map and anticipation (from climate) gives you multiple points of attack (i.e. multiple wheres, see figure 3) and the use of context specific gameplay helps you determine why to attack this space over another. That's the key about strategy, the why is relative as in why here over there. You never start strategy with why, you always start with WHERE.

Figure 3 - Multiple Where

Of course, this is the decision point and your action can impact the game, your purpose, the landscape and so on. It's all iterative. A constant cycle of observe, orientate, decide and act. Except in most business it isn't.

Most business have no idea of the landscape they exist in. Hence they can't possibly hope to learn the rules of the game (i.e. the rules of economic climate). They certainly can't distinguish between context free doctrine and context specific gameplay nor do they have any mechanism for learning context specific gameplay. In most business, leadership is an exercise of writing down a purpose and jumping straight to strategy by copying what others are doing or gut feel or the use of verbal reasoning such as SWOT diagrams. It's a mess of memes normally. But then, that's not really surprising because if you can't visualise the environment in some form then how are you going to observe changes to it (you have nothing to compare to) and how can you orient around that? As figure 4 highlights, what could strategy be other than meme copying and gut feel? Is it really any wonder that corporate strategy documents tend to be a tyranny of action statements (how, what and when) with only the most vague notion of 'why' when we can't see where to attack or learn from our play?

Figure 4 - Lack of a map

However, that doesn't mean people are daft or can't change, the problem is they've been playing a game of chess without ever seeing the board or understanding that a board exists. I see this all the time. I run a workshop in which I take groups of LEF members through a scenario (using SWOTs, reports and financial analysis) in which they choose a set of strategic options and then later on they map the same scenario and discover (almost uniformly) how utterly mistaken their first attempts are. It's amazing to see and especially those lightbulb moments when they realise how they've been playing the game in their existing business. As one CIO of an enormous environment (think in the billions) said to me recently - "once you've mapped, it becomes so obvious that you wonder why you weren't doing this before".

Of course, you can learn to map in a day and do remember that all of this is creative commons. When you get good you can normally map an environment, work out the gameplay and determine how to attack a given space within a day or so. The trick is getting good and that, like Chess, takes practice. Many years of it. However, that's down to you. The only people who can map an environment and play the game are the people who work / live in that environment. You can't hand this off to consultants. You have to put in the effort.

Oh, but what about culture! That's another topic wrapped up heavily in doctrine with context specific elements and impacted by purpose and your choice of strategic play. However, given most people can't do the basics, I don't even think it's worth mentioning other than pointing out that you need more than one. But "culture eats strategy for breakfast" I hear some people cry. That's a soundbite which appears as popular as it is flawed. It has the accuracy of "the key to strategy is execution" or "you can't manage what you can't measure". But these are all more complex topics, better left to another day.

Saturday, January 30, 2016

Managing a complex world

Going through some old talks, I dug up this video - I've now put it on Google - covering how to manage a complex world. It's from May 2008 and though I didn't go through mapping (back then I didn't realise that others might find mapping useful because I assumed everyone must do something like that) but it does cover innovation, evolution and how future organisational strain will be caused by rapid change. 

Alas, the best solution to this that I know of (as mentioned in the video) is a three party system e.g. Pioneer, Settler and Town Planners (or what I used to call Pioneer, Coloniser & Town Planner back in 2008). Eight years later and all the rage seem to be bimodal. Oh dear. There are many problems with such dual system approaches. You'll find out why you shouldn't soon enough.

It's amusing to note how many of the same problems still face companies today. These really shouldn't. Business thinking seems to progress very slowly ... except in China. However, that's another story for another day.

Sill, the presentation is not bad.

Friday, December 11, 2015

Efficiency vs Effectiveness - Repeated.

I'm bumping into this sort of madness at an alarming rate. Any illusion that I once held that business is sane is rapidly diminishing. I'm going to use an example, not including names and slightly modified to include other examples of practice just to ram the point home. This covers a company working in the financial sector.

The company has its own data centres and it is rapidly growing which is creating a problem because of the time it takes to order and install new servers. The basic process is fairly straightforward, they order new servers, the servers arrive at goods in, they are then modified and mounted. The company analysed the flow (a rough diagram is provided in figure 1) and found that the bottleneck was caused by modification of the servers due to the number of changes which need to be made before mounting. 

Figure 1 - The flow.

The solution? To automate the process further including investigating the possible use of robotics. It turns out that the process of modification is not only time consuming but can cause errors and the cost of automating this process (given the rise of general purpose robotic systems) can be made given the future expectation of growth. The figures seems encouraging. Getting rid of bottlenecks in a flow sounds like a good thing.  It all sounds reasonable.

But it’s all barking mad. The first thing to do is map out their environment including the flow. The map is provided in figure 2. 

Figure 2 - The map

Now, as we can see from the map then goods-in and ordering are fairly commodity (i.e. well defined, commonplace) and that makes sense. Computing on the other hand is treated as a “product” which seems suspect but far worse is they are making some fairly custom modifications to this “product” before mounting. Also, what is racks doing in the custom built section? Racks are pretty standard things aren’t they?

Well, not in this case. Here the company is using custom built racks which are slightly smaller than the 19 inch standard. Which is why they need to modify the servers. “Eh, What?” I hear you scream. Yes, the company needs to take the cases off the servers, drill new holes and mount rails to make them fit. “Eh, What?” I hear you scream. And so, yes, the proposed automation is about using robots to improve that process of drilling and modifying servers to fit into custom built racks.  Wait, can’t we just use standard racks? 

If we take our map, and mark on how things should be treated (see figure 3) then surely it makes sense to use standard racks and get rid of the modification. “But, that’s how we’ve always done it!” comes the cry. Oh, heaven help us. It may have somehow made sense in the long distance past but that's the long distant past.

Figure 3 - The modified map.

In fact if we look at the map, we should also mark compute as a utility (which is what it is now). I’ve done this in figure 4. Which now begs the question that we’re a finance house, what the hell are we messing around with servers in the first place for, let alone drilling holes in servers to make them fit custom built racks. We shouldn't be "improving" this flow, we should be getting rid of it entirely.

Figure 4 - An alternative flow

I'm writing this whilst looking at another example which has nothing to do with finance or racks but it's as equally daft in all senses except scale. This one is a lot bigger, a lot more expensive and they've even splashed out a good few million on consultants to help define their "reasonable approach". This includes lots of nice charts, flow diagrams and even a value stream map (a mechanism for improving flow). I'm starting to think that large chunks of business can only operate because competitors are doing equally daft things. Making ineffective mechanisms more efficient isn't a good thing. You really need to understand context before embarking on this type of stuff.

I need a large cup of tea, a nice biscuit and a good sit down. I'm trying desperately hard to be polite and hold back the expletives. 

Thursday, December 10, 2015

My top predictions for 2016

Here are my top five predictions for things you absolutely should do but will ignore in 2016.

Focus on user needs. Lets face it, playing with tech is far more fun than actually understanding your user needs and so you'll probably argue that buying a whole load of VR gear is fulfilling this requirement. It's not but that won't stop you and it's not like the business knows what it's up to anyway.

Improving situational awareness. Making decisions, determining strategy and even effective operations requires an understanding of the environment. But hey, why bother starting now since you've been living for so long without it. The whole idea of actually understanding your landscape sounds very complicated especially when I can buy a report from McKinsey to tell me what to do. 

Getting over one size fits all. Whether it's agile, lean, six sigma or outsourcing then by now you should suspect that one size doesn't fit all. In fact, the techniques are specific to different stages of evolution. Eh? What? Oooh, that sounds complex. Especially since I can roll a dice and pick one.

Organising around evolution. New things appear and evolve. They start in the uncharted space (a world of exploration) then we learn more about them (the transitional space) before finally over time they become more commodity like (the industrialised space). You really need to organise around this evolution using cell based structures (e.g. Haier / Amazon Two Pizza) and models such as pioneers - settlers - town planners which require multiple cultures within a single organisation. This does seems like an awful lot of work and anyway Gartner has told us to go bimodal. Following orders has always been so much easier than thinking.

Coping with inertia. Change in an economic system caused by supply and demand competition is often resisted due to past success. There are 16 different forms of inertia to cope with and it's worth remembering that inertia is a killer. However, a bigger killer is rocking the boat prior to retirement, so if you can just hang on in there, keep things steady and learn a few good buzzwords - digital, ecosystem, platform, disruption - then why do you care what happens after you go?

These are my big five things that you absolutely should get to grips with but will ignore in 2016, replacing instead with meaningless buzzwords and tech gadgets. The good news is because most other companies will do exactly the same then you're likely to get away with it.

Duplication and bias - two problems that cost you a fortune and are easy to solve.

Having just had a rant on the ridiculous attitude some take to outsourcing, I'm now going to skewer another pair of bugbears of mine - duplication & bias. Again this uses mapping.

I'm going to start with two maps, both from a Government department. One is an internal system, the other is external. Now, you can argue about the position of pieces on the maps but that's not the issue. What I want to point to are the green dots which are replicated from one map to another. Lets now look at those maps (figure 1 & figure 2)

Figure 1 - An Internal System

Figure 2 - An External System

What the maps tell me is I have multiple components, repeated and often treated in different ways. Sometimes we even use different terms for the same thing. The more maps I add, the more duplication I find. Eventually with enough maps then most components are green i.e. duplication is everywhere. 

I can use these maps to create a profile for an organisation by adding all the green dots from many maps to a single page. I've shown this in figure 3, highlighting the level of duplication, examples of bias and a "cluster" for how things should be treated.

Figure 3 - A Profile for activities within an Organisation

The purpose of this profile is it tells you were you are duplicating, where you have bias and gives you information to go and challenge what is being done. This is the real power of mapping, the act of sharing these maps enable you take out waste and start learning common patterns. But is this just a Government thing? 

People often think that Government is the home to inefficiency. It might come as a shock when I tell you that the private sector excels at this. In one case, I know one large corporate with 380 customised versions of the same ERP system built by different teams but meeting the same types of needs for the same type of users. The private sector in my experience beats Government hands down for duplication, bias, waste and making decisions without any form of situational awareness.

Unfortunately because so few organisation do something as basic as mapping out their environment and collecting those maps, they have no continuous means of identifying duplication and bias. They endlessly create custom built examples of things that are well defined products and they rarely clear out the baggage except in some big "rationalisation" effort. Of course, most of those "rationalisation" efforts are a joke because they try to clean up their act with no maps of the landscape and hence no idea of what to clean up. It's all praying to the God of the water cooler that somehow people will take care of this through serendipitous discussions.

So, how common a problem is this? Well, most companies (i.e. > 99%) have no recognisable form of situational awareness.

What about a figure for the level of waste! It's difficult to put a number on that because it varies between organisations. But experience dictates that if you combine duplication, bias with inappropriate doctrine (e.g. outsourcing too much) then in a large organisation you are looking at around 90% waste.

90%!  You're kidding! Nope, I'm not. People will tell you it's lower (i.e. 20-30%) but when you get into the details then all sorts of things come out of the woodwork. In one case, I have an example where the cost reduction was 99.95%. The reason why people think it's lower is they have no mechanism of situational awareness and so they really have no idea how much duplication, bias and misapplication of doctrine there is. Never, ever underestimate the amount of waste that happens because people make decisions without understanding their environment or sharing that understanding with others.

Of course, don't tell them they're wasting bucket loads of cash, they'll just get defensive. It's better to lead them to that conclusion. Hence take about ten heads of different business units, put them in a room and ask them for maps of their landscapes. They'll look sheepish, often lots of foot gazing with a few claiming "we do mapping". Try to get them to discuss a system and ask who has got this. I can tell you now you'll quickly find that they all have lots of the same type of things but most likely they'll have all customised it. If you've people in the room with more experience of the environment, you'll quickly discover that most business units will have multiples of the "same" thing. Before long, you'll find an example where you'll be counting 30 or 40 different versions.

Now, be careful here because people often raise the idea about common or shared services. There's nothing wrong with this idea as long you're talking about a fairly industrialised act (see the post on outsourcing). The problem with past "common" or "shared" service efforts is organisations didn't have any situational awareness (they still don't) and so they tried to share the wrong things (i.e. stuff that wasn't industrialised). You need to first use the profile to identify duplication and then eliminate bias (i.e. unnecessary customisation) and then with the industrialised stuff (which turns out to be a lot of IT) you can then look at common, shared services or outsourcing to a cloud provider.

Oh, and as for the person who said "we do mapping" ... the reality is it's extremely rare and so you can bet they don't. Organisations do use things such as value stream mapping, business process diagrams which are all fine but don't give you context and can therefore lead to all sorts of really bad decisions. For a map you need position (in this case a chain of needs relative to an anchor which is user need) and movement (in this case evolution) and without these two aspects then you'll just keep repeating the same old problems.

This "wisdom" is brought to you courtesy of 2007. For all our sake's, stop doing this sort of nonsense in Government IT. Don't build things without some form of situational awareness. I know a few Depts think of themselves as little Empires and don't want to share but we can't afford to waste vast sums rebuilding the same things over and over. If you're happy with the status quo then please go and work in the private sector instead because a) you won't harm Government or waste taxpayers' money b) the private sector has so much waste they won't notice you piling on a bunch more.

Wednesday, December 09, 2015

Cloud is outsourcing but it's not outsourcing (as was).

I'm tired of many of these discussions because they're ridiculous. However, once more unto the breach dear friends.

First, lets take a map. I'm using an example based upon HS2 (high speed rail) in figure 1. Now, the map contains many components, all evolving (under supply and demand competition) from the uncharted space through a transitional space to an industrialised world. I mention those three different stages just in case a hoard of bimodalites come raging past.

The methods you need to use depend upon how evolved the components are. For a handy guide, I've put down the normal range in figure 2. In the uncharted space, you're discovering and so you need to reduce the cost of change. Hence Agile (or more accurately, the Agile principles) are best suited. By the transitional stage, you know roughly where you're going and you need to reduce waste and learn more on the environment. Go read Lean for this. By the time the same act becomes industrialised then you're into reducing deviation and here Six Sigma rules.  So let us look at those figures.

Figure 1 - A Map (modified from HS2)

Figure 2 - Methods.

Now, most organisations (and by most I mean > 99%) have no map and therefore no situational awareness instead relying on story telling and SWOT diagrams. Hence the tendency to adopt one size fits all methods and all the other instruments of la la land including woeful strategy, meme copying, no mechanism of learning through context, masses of duplication and bias etc. If you want a good laugh, you should spend time in the boardroom when people discuss strategy ... any illusion of chess playing masters will quickly disappear. People are really shooting in the dark here and struggling because of it.

Since most people have no situational awareness, the best you'll get is a business process map or another box and wire which shows connections between things but no context. You'll get something like figure 3 and asked the question which bit should we outsource? In the past we tended to outsource the whole lot because we didn't have a clue.

Figure 3 - A box and wire

So what happens when you outsource the lot? Well, you'll try to put a well structured contract in place to make sure you know what's being delivered. But lets look at this box and wire in terms of a map. See figure 4.

Now this is a rough map (the only people who can actually map an environment are those actively working in it) but it'll do for this discussion.

Figure 4 - A map of the box and wire.

Now we can argue about the position of the pieces on the map but eventually we will get to something we agree on. Let me assume the above is about right and we've outsourced the lot to a friendly outsourcing supplier under a very structured contract because that's the "sensible" (chortle, chortle) thing to do.

What's going to happen is the stuff on the right (the industrialised bits) will hopefully be delivered effectively and efficiently by the supplier buying highly commodity components or well defined products. You certainly don't want them to be building a LIDAR like you're the first person to ever have one of these. Things like GPS, LIDAR and even geographical maps (though not included on the diagram here) are actually well understood and common and hence suitable for outsourcing, provision as commodity components etc. However, the stuff on the left in the uncharted space will change. We will be exploring this space, working out what do we actually need from a World Perception Server. The result of this change will of course be excessive cost control overrun through a change control process. Naturally the supplier will say that the excess cost is all your fault because you didn't specify well enough what you wanted in the World Perception Server etc but the reality is you could never specify well enough. Neither you nor anyone else could know what is required in the uncharted space. You have to experiment.

The problem with outsourcing in the past wasn't the concept of outsourcing but instead that organisations outsourced entire systems for which they had no situational awareness. This was foolish and of course outsourcing got a bad name except from the suppliers who cottoned onto the scam and made oodles of cash out of it. The simple reality is that there's nothing wrong with outsourcing if you break down complex environments into components and outsource those industrialised ones.

Which is where cloud comes in. Cloud is all about the shift of a bunch of product based IT activities to highly industrialised utility services. When you're using AWS for infrastructure e.g. EC2 then yes you're outsourcing infrastructure to AWS but in this case you're outsourcing a highly industrialised component to a utility service provider. Top marks, a dead sensible thing to do.

What you're not doing is the "old" form of outsourcing which means taking a whole bunch of components for which you do not understand the context and handing them to someone else in the hope they will take of it for you. For those going "people didn't really do this, did they?" ... oh boy did they and for endless reasons of gibberish e.g. from it's too difficult to deal with components and interfaces to it'll reduce risk. The only risk it reduces is the risk that the supplier won't make excessive profits. Trebles all round. 

So, yes ... cloud is all about outsourcing highly industrialised components to utility service providers. No, it's not like the outsourcing of the past which was barking mad in many cases. No, the mechanics of this are very different and before anyone says something really daft like "Isn't cloud like renting a room in hotel" ... I'll stop there.

This "wisdom" was brought to you care of 2006. Shame on you if you're still getting this wrong. I'm fed up with being nice to people on this, please go work in another industry and stop giving IT a bad name. Or go run Donald Trump's IT office and bankrupt him. Tell him you need custom built servers, oh hang on ... custom built chipsets ... oh wait, no tell him you need an entirely new form of power to run the web site (i.e. a dyson sphere) and outsource all the exploration to someone under a "fixed" contract like it's an industrialised component. At least you'd be doing everyone a favour.

For all our sakes, stop doing this in Government IT. Please, just leave. Regardless of what you think, we are in economic competition with other nations. There's better places to spend taxpayers money than flushing it down the toilet by outsourcing without situational awareness. Oh, and before anyone says "mapping is hard" etc ... with a bit of practice you can create a really useful map in a few hours. You can then start sharing maps and getting rid of duplication and bias - but that's a post for another time.

Btw, all the mistakes above such as outsourcing too much, one size fits all methods, creating dual structures are mistakes I've made but learnt from.

Finding easy competitors to take out

When mapping and determining gameplay, it's always worth having an occasional glance at your competitors - the game of strategy is an iterative one of observe, orient, decide and act. It’s really useful to know who are the easy competitors and the ones you should take out whilst avoiding the tougher spaces whilst you grow. There’s a number of signals to use which demonstrate easy targets. Most of these you can pick up from their own website, their public talks, forums etc.

Key to look for are

Duplication and bias. Without mapping or some equivalent then companies have no real mechanism of avoiding duplication and bias. They'll also be suffering with inertia. This is a goldmine as these companies will inevitably be slow and inefficient whilst being riddled with unnecessary complexity and inaction. In the worst case that I’ve found, a single company had 380 customised versions of the same ERP system. It’s often difficult to find out how bad the situation is without talking directly to ex employees etc but occasionally companies let slip by announcing future rationalisation projects. This form of competitors are great fun as they are just too slow to counter you. Think "stealing their pack lunch".

No position or movement. Without a means of visualising the environment then companies are unlikely to have much of a concept of position or movement. These companies are ripe for attack. You can pretty much guarantee they have no means of organisational learning or effective approach to anticipation, they certainly won’t understand repeatable forms of gameplay or context. Any “strategy” (I use that word loosely) is simply backward causality. You can often spot this by looking at their strategy statements (normally a long list of action items), their emphasis on story telling (no means of visualisation) and their fondness for memes. These competitors are easy to wreak havoc on as they just don’t how to react. Think "All you can eat buffet".

Single methods / dual operating system. These companies are very unlikely to even understand evolution which means they certainly can’t map and are unlikely to have developed any situational awareness. However, worse than this, they not only don’t understand the environment but they’re imposing a dogma of some type on it. You’re not going to be facing a cell based killing machine here but instead an organisation racked with difficulties, failing to manage the legacy, over-reliance on outsourcing & analysts and in a stupor to consultants.  Their own people will often be rallying against them as they boil under the tyranny of an imposed one size fits all method or create waring tribes. Morale is likely to be low and good engineers should be prime for poaching. The company might talk a good game (e.g. ecosystem, disruption, open source) but have no fear, they are really lost at sea. Send a note to the CEO with the words “boo” on it and then help yourself to their market and their good people. You can usually spot these companies a mile off because they’re announcing that they’re going “all agile” or “all digital” or "all openstack" etc. These are my favourite companies and you should treat them as an excellent recruiting ground. In this case it's less free lunch and more "Execs will come to your house and cook whatever meal you like" as these people are actively working in your favour.

There are other things you could look for but this is usually enough to spot the vast majority of easy targets.

Sunday, December 06, 2015

Open source as weapon

I often talk about the use of an open play as weapon, a mechanism of changing the environment you exist in. Back in 2011, when I examined the phenotypic changes of companies (due to a particular cycle known as peace, war and wonder - more details here) there was a pronounced change in attitude in the next generation of companies from the use of open means for simply cost reduction to the provision of open means (source, APIs, data) to manipulate the market (see table 1).

Table 1 - Changes of phenotype from traditional to next generation.

In the following year, I examined the level of strategic play (based upon situational awareness) versus the use of open means to change a market and noticed a startling effect. Those who showed high levels of situational awareness and used open approaches to change a market showed positive market cap changes over a seven year period (see figure 1).

Figure 1 - Changes of market cap with Strategic Play vs Open approaches.

I've talked extensively about the use of Wardley mapping and how you can use this to identify where you might attack a market. I've also provided examples such as "Fool's mate" which is one of about 70+ different forms of repeatable gameplay that can be applied to a given context. In Fool's mate, you attack the underlying system with an open approach in order to gain a change in a higher order system. More details are provided here but figure 2 provides an outline.

Figure 2 - Fool's mate in business.

However, even if you do have reasonably high levels of situational awareness, you understand where to attack and how to manipulate a market through open approaches then this is not the end of the story. The use of open approaches is not a fire and forget system. You can't just declare this thing as "open" or create an "open consortium" and walk away.

Unfortunately, far too often in corporations I've seen people believe that "open" is synonymous with "free resources" and that somehow by opening up a system that the community will be so grateful for the gift that they'll just adopt it and success is assured. This is la la fantasy land. The majority of today's great tech corporations owe their success to the open source community, they are built on it and they do themselves no favours to disrespect the community in such a way.

If you decide to attack a market and you decide to use open as the means of changing it (what I like to call "open by thinking") then when you launch you'll going to have to put time, effort, money, resources and skill into making it happen. Hence the importance of "open by thinking" because going open should be seen as an investment decision which can pay handsomely if done right. There are numerous pitfalls to be avoid e.g. antagonising or not building a community, not listening to a community, not acting as a benevolent dictator for that community or failing to put its interests over your own, failing to steer a clear direction, failing to invest and worst of all establishing a collective prisoner dilemma.

You are the custodian, the gardener, the benevolent dictator of the community you hope to create. The act of throwing some code over the wall, creating an open source consortium and running a social media campaign on how "good" you are is a long way off from what you need to be doing. It is more akin to the self aggrandising but absentee landlord who claims the lack of tenants for their unsafe flats is purely because people renting properties are ungrateful.

Yes, you can use open approaches as a weapon to change the market in the battle between companies but it's a weapon that requires skill, dedication, investment and care.

BTW, I do love Chapter 12 - How to tell if a FLOSS [e.g. open source] project is doomed to FAIL. Hat tip to Jan Wildeboer for that one.

Thursday, December 03, 2015

Two speed IT - the more I look, the worse it gets.

I've just been told of a "new" idea of using two speed IT with agile combined with a platform. Heaven help us. First, it's a very old idea and second it was as daft then as it is today.

Let's go through how things should work (see figure below). Your town planners (specialists in empires of scale) create your platform. Lets start with a simple code platform providing a utility like service. Your pioneers (the specialists of speed) build lots of new stuff on it. Your settlers (the specialists of learning, reducing waste) find the common patterns in all the new stuff and turn these into basic components whether products or libraries which they develop further. Let us be clear here, whilst your settlers may take "more" time to build a product or library component than your "hack it anyway it works" specialists, your settlers accelerate the speed of everyone building with those components. Hey, I just install the library rather than write one or there's an API to some rental like service (which is fairly stable).

Over time, your town planners convert these increasingly matured components into component services optimised for volume operations. These component services become extremely stable, change slowly (though new component services can be constantly added) and they accelerate the speed of everyone who builds upon them.  For your pioneers, they don't have to install a library or product but instead they just use an API to a solid service ... super fast! Ditto your settlers who can include these component services in their libraries and products.

And so the cycle goes on and on, constantly driving us upwards and ensuring efficiency, agility, speed and removal of debt by the use of three groups, three speeds of operation, three types of people and three cultures. This was reasonable practice circa 2005.

So lets roll the clock forward to 2015. What we have is a "great" idea of one group builds the platform and then a second "agile" group running at a different speed builds the new things (see figure below). Certainly this might give you a short term bump in efficiency and delivery. The problem is there's no group identifying common patterns and evolving them. The "platform" group that builds industrialised component services aren't going to touch your flaky new "agile" thing (cue endless arguments to exacerbate any tension between the two groups). The agile team of course wants to move on, so they'll start building new things on top of their new things. This is a one way street to spaghetti junction, a bucket load of technical debt, an entire system that creaks and slows downs and a big "meeting" where we all get together to build the new platform of the future because the last one is now fscked. I've seen this so many times over the last decade that it ain't funny.

Two speed IT combining agile + platform ... that's my new shibboleth for the clueless. Almost anything is better than a big expensive platform effort which will grind to a halt requiring a huge future platform re-engineering effort and on and on. This is where you'll be heading and this is kids stuff. It's shockingly bad.

-- 6th January 2016
[added updates above]

Lots of people discussing the importance of speed. Please note, don't confuse the speed of how quickly something is built with the overall impact of the thing on speed i.e. it might take longer to build a library than a quick hack for the same activity but the advantage of the library is in re-use. The more industrialised something becomes then the speed of building / changing might become slower but the speed benefit it has on everything that is built on top becomes huge.

It's way quicker for me to chop down a tree and saw a plank of wood than it is to build a modern computerised sawmill. But if I need planks for a 100,000 homes then it's way better to have highly industrialised and standardised planks created by computerised sawmills than to have me with an axe and a saw.

Saturday, November 21, 2015

Uber, the not so disrupting disruptor?

A recent HBR article by Christensen on "What Is Disruptive Innovation?" states that Uber is not "genuinely disruptive" and it doesn't fit into his hypothesis of disruptive innovation. Well, he is certainly entitled to modify it anyway he sees fit but the article does raise concerns over post event classification i.e. the original claim that the iPhone wouldn't be disruptive followed by the article's claim that it wasn't in the smartphone market and it was in the PC market. I happen to agree with the basic premises of disruptive innovation though I do note that there appears to be at least two different forms of disruption - one anticipatable and the other not. That said, let us get to the point of this post which is Uber.

First, I'd argue that a case for Uber being disruptive can be made if you look at the right thing (a bit like the above HBR article which compares the iPhone not with the smartphone market but instead the PC market). The area to examine is whether Uber is replacing the human controller. The person who you called, who co-ordinated taxis and who told you the car would be there in five minutes (it never was) has been automated out of existence. I know taxi firms who dismissed the idea of an application doing this citing that people wouldn't trust it, the benefits of talking to a person, of accounts and a more personal service. Uber however took the controller and turned them into an automated bot creating the barest minimal of interaction.

In the process this automation also expanded its reach, there are limitations on how much any human controller can effectively control. So, whilst I agree that Uber is not disrupting taxis per se, it certainly seems to be disrupting the idea of a human taxi controller by first turning this interaction into volume operations of good enough. However, what's interesting in this topic is when people talk about the potential of Uber to disrupt the automotive industry.

To understand why, we first have to look at a map of the automotive industry. I won't start with today's map but one which has been rolled forward to 2025 (see figure 1).

Figure 1 - Automotive Map 2025

The user has two basic needs - status and getting from A to B. The latter has multiple sub needs from comfort (which includes safety and security) to affordability to route management. These are all encapsulated in the concept of the car and there is a pipeline here from the more product / differential focused automotive to the more commodity like vehicles. You can follow the chain down through systems to provide comfort (including entertainment and infotainment) to OEM to component manufacturers. To keep the map reasonable, I'm cutting down whole sections to nodes (e.g. power supply or material).

In this picture of 2025, intelligent agents have become increasingly common and hence most cars have some self driving capabilities. Cars are becoming increasingly immersive (the inside of the car is just one big set of screens, probably printed). What starts to differentiate cars is not the car itself but the design associated with the immersive experience and the connection between status and route management. By this point, cars provided on some sort of utility basis will be increasingly common. This trend of intelligent agents, immersion and design subscription will continue to diffuse. So what does this all mean?

By 2030, in all probability most of us won't own cars. When I leave a meeting then my car will certainly be there to pick me up but that same car will be the one that you were using 30 minutes beforehand. Cars, for most of us, will have become very commodity. What will distinguish our journeys will be the level of digital subscription service that we have. If you are a "platinum" service member then not only will the outside of the vehicle alter (colour, some other affects to show your status) but the immersive experience will be more tailored for you and your journey will be faster. Why? Well the cars driving us "silver" subscription members will get out of the way for your car. We won't even notice because we're inside in our immersive experience which for us "silver" members probably involves a lot more advertisements. 

The cars themselves will monitor their own performance, drive to the repair shop when needed, communicate between each other and re-route constantly based upon not only the journey time but the subscription services of other car users. Of course, human driving will be increasingly outlawed except for super high end status vehicles where the illusion of human driving (safely managed by an intelligent agent) is given. There's all the usual knock on effects to car parking (we don't need as much) to repair shops to traffic signals etc.

Taxis in this world will become a thing of the past except, in a sense, most of the cars are acting like taxis with automated controllers and automated drivers. We don't own these cars, we just subscribe to our service and pay for what we use. By 2045, well the scenarios get even more outlandish. But who will own this new world of vehicles? Will it be Uber or Google or Apple or Ford or even GM?

If you look at the above map, identify the points of war (i.e. the shift from product to more commodity), the impact of technologies undergoing the same change (e.g. immersive, robotics) and then add in the structural advantages (e.g. education, financial and manufacturing scale) and strategic gameplay of companies and nations (e.g. last man standing, creation of centres of gravity, directed investment etc) then a very different picture emerges. Figure 2 provides major impacts from points of 'war' (red boxes) and overlays examples of known gameplay of significant scale in China. Even by 2025 then China should be edging ahead in the automotive industry by building, designing and operating the most advanced forms of these vehicles. Alas, even today Western companies keep on underestimating the speed, agility and entrepreneurial spirit of China.

Figure 2 - China Gameplay in Automotive

The automotive industry seems destined for an immersive, self driving and digital future provided through highly commoditised vehicles. However, I expect the beneficiaries of this change to be Chinese OEMs combined with service companies such as Baidu and Didi Kuaidi. As for Uber then I agree it is disrupting the human controller. I also agree it will have a part to play in this new world for a time. But, I don't expect Uber to be the company disrupting the automotive industry even though it might dream it will.

Friday, November 06, 2015

When to use a Business Model Canvas or a SWOT?

I've been asked for a bit more detail on my post on "Business Model Canvas, the end of a long road" and so I thought I'd use an example.

I was recently looking into the whole area of identity and access management (something I'm mulling over for future LEF tours) and so quickly put together a basic map of the industry. Now, I'm no expert on the subject and so I turned to others to give me input (I find my Wardley maps are useful for collaboration with others). A basic map is shown in figure 1.

Figure 1

The first thing I'd do with this was to look at weak signals (i.e. points where the industry is shifting from product to commodity [+utility]), add in competition forces (i.e. those areas where competition and hence evolution appears strongest) and add in known ecosystem plays such as ILC. This I've shown in figure 2.

Figure 2

At this point, I'm looking for potential. There are two "wheres" that I might attack for example in the above map. One of which is obvious and the other is a combination of components. The two are :-
  • profiling and the development of an ecosystem around this.
  • personal reputation and the development of a relatively novel system that combines components of both trust and profile.
This I've show in figure 3. Of course, there's numerous other points I might wish to attack and a vast array of games (repeatable forms of gameplay applicable to different contexts) that I can use.

Figure 3

I might have spent a few hours mapping out the landscape and collaborating with others but let us say, I push the boat out and go a bit overboard by spending another day and comparing with other players in the space, adding in inertia and constraints where necessary. Lets add another half a day for gameplay. I'll have a pretty extensive map of the landscape, multiple points (WHERE) that I can attack and a good idea of how to play this and the different games available.

By now I'll be looking for my WHY as in WHY here over there. Once I've played with a few scenarios (a few hours) and settled on one or two main points of attack then this is the point that I'd start using the maps to flesh out one or more business model canvas (and yes, I might even use a SWOT). For me, these tools are more an exercise of confirmation and challenge to the idea of my chosen point of attack. And before you ask, yes I could spend a whole three days on this entire analysis prior to embarking on a major effort but in practice I rarely need to.

I find it incredibly useful to understand the landscape, the points where you can attack and the games you can play before embarking on a chosen route. I never start with business model canvas or SWOTs but I often use them further down the line when I've got a good idea of WHERE I'm going to attack and WHY here over there.

Efficiency vs Effectiveness and why flow isn't enough.

Without naming names, I'm going to talk about a rather ridiculous situation that helps highlight the difference between efficiency vs effectiveness and why flow isn't enough. It concerns computing.

In this company, they have their own data centre which is full of custom built racks. These racks exist because that's the way they have done it but rather than being the standard 19" rack, these are a non standard sized and turn out to be slightly smaller. This unfortunately means that normal servers can't be racked but nevertheless the company has a solution. They buy relatively standard servers, they remove the shell and drill new holes into the body in order to fit it into the rack. Now users in the company can request compute resource but what's of interest here is the issue of when capacity is nearly reached. An order is made, new servers arrive in goods in, the shells are removed and new holes are drilled to modify the servers and then they are mounted. I've drawn the process in figure 1.

Figure 1

Now looking at this process, we find the mechanism of removing the shell and drilling holes (i.e. Modify) to be quite time consuming. It is also occasionally imprecise causing issues mounting the servers and waste. It is also bottlenecked by there being a limited number of people who are any good at doing this. Bizarrely metalwork is actually not a core competency of system admins. So we can propose any numbers of mechanisms to improve the efficiency of this process even to the point of automation with robotics if the scale demands it. 

However, I want to take a mapping view and show the same flow. When using maps, on the evolution axis then I tend to use activities (i.e. genesis to commodity) but do remember you can map practices (novel, emerging, good, best) and data (un-modelled, divergent, convergent, modelled) on the same axis. All of these components share the same characteristic changes as they evolve. 

In our process then order components and goods-in are fairly widely understood and established. The modify server (despite there being a guide written on how to do this) is fairly unusual and a newly employed system admin will probably have little idea on how to do this. Of course, even racking a modified server is reasonably straightforward. Hence I've provided a rough map of the above in figure 2. However I've also marked on a view as to where compute, racks and the practice of mounting a server are in the market.

Figure 2

What should be obvious is that we're trying to make Flow 1 efficient when it is in fact an ineffective process. The only reason why we're doing this is because of our use of custom built racks in a world where racks are standardised. If we use standard racks then the modification process goes away and mounting becomes vastly more standard. However, if we look up the value chain then compute has become far more of a utility and if we take advantage of this then flow 1 is simply replaced by an API call (flow 2). 

In the case of the above, the company shouldn't even own compute but should be using a public cloud service. It certainly shouldn't be investing in robotics to automate a process of customising standard servers to fit into custom built racks in order to make an ineffective system more efficient.

A map gives you two main axis. The first is position based upon a chain of needs relative to an anchor of visible user need. The second is movement (i.e. how things change, evolution). Within maps you have flows but mapping makes it much more obvious when you're trying to optimise and make efficient a highly ineffective flow. Of course, many of you are familiar with compute and would claim it would be obvious not to do this. But if I made a map of World Perception Systems or a Trading Ledger then you might not be so familiar. In which case, I suspect you might fall into the trap of optimising and making more efficient the wrong flow. I suspect this because I see it all the time. Endless efforts in corporations to make the wrong thing more efficient.

You can't also just say, well that company should be asking - "how does this process help us?"  - as the executive don't understand the inner workings of systems and the people involved in the process believe it's the right way. They're proud of their environment and have all the usual symbols of inertia. It's not that they're daft but instead they believe that what they're doing is right - it's what they've always done and they've invested considerable personal time and effort making it better. Of course, making it more efficient would help the company hence investing in robotic automation sounds "sensible". I can easily build a case for this as daft as it sounds (and it is daft).

Showing them a map, even with just pointing out the change if you start using more commodity components such as standard racks (see figure 3) rather than focusing on making an existing process efficient exposes the assumptions and workings of a company.

Figure 3.

Once you've explained that, it becomes far easier for people to make the leap towards not having racks at all (i.e. flow 2). I mention this because people often tell me about the importance of removing bottlenecks and ensuring efficient flow. I happen to think such techniques for value stream analysis are reasonably important but you have to be really careful that you're not making the wrong thing efficient. It's not enough to just look at flow (as in figure 1), you need to consider how evolved the components are (e.g. fig 2 and 3).

Which is why I always recommend you start with a map.