Saturday, January 24, 2015

Maps and the Target Operating Model

I was asked a question about my post on getting stuff done and then noticed a relevant but unrelated tweet by Tom Loosemore

.... so I thought I'd better answer. Does the map represent your target operating model? No, but not for the reason you might think.

My original post discussed more the process by which you get something started, a key part of which is creating the map to determine, communicate and then challenge what is to be done. One this has been done the map gives you an initial target (see figure 1)

Figure 1 - Initial Target

From the map you have a set of user needs, numerous components to meet those needs (a chain of needs or value chain), a necessity to use multiple methods (due to changing characteristics), a division into small teams, use of components from others, delivery of components to others and a set of strategic plays ... read the original post for details.

Now, a few things are worth noting.

1) The map is imperfect (all maps are). So other components and needs are going to emerge on route.

2) The map is not static. All components evolve due to competition (supply and demand) and hence their characteristics, how you might treat them will change.

3) Others will develop systems which impact your map i.e. provide opportunities for either re-use of their components or supply of your components to them.

The map is a guide not a target operating model because the map is not static. It will change and you will have to adapt as it changes. Maps of a competitive environment are fluid - evolution doesn't stop because you're building a big project. This actually can be extremely useful because you can use timing to assist you. In very long projects, you can de-prioritise selected components for as long as possible to give them the maximum time to evolve to more industrialised (e.g. commodity) forms.

I'm not a fan of the target operating model concept because it implies that a static, steady state can be achieved. That's a rare exception in my view and whenever I have been able to reach it, I've generally found that life has moved on and I need to change again.

Sunday, January 18, 2015

How to refer to mapping?

I often get asked what IP exists around the mapping technique that I talk about? Well, it is IP protected under Creative Commons 3.0 Share Alike. This means you are free to use it, free to modify it and free to distribute it as long as you use the same license. I'm not in the business of trying to extract rent from people for drawing maps, I'm in the business of helping others run their organisations more effectively.

This does leave a question of attribution. There are numerous forms that I'm happy with. As long as its similar to this in spirit then I don't grumble.

1) Wardley Mapping
If you call the technique "Wardley Mapping" then this is fine and there's no need to attribute further in presentations and talks. I happen to quite like this term these days to avoid confusion with other 'value chain / stream' mapping techniques that are not equivalent. 

If you want to add a more explicit attribution line (e.g. you're writing an article) then "courtesy of Simon Wardley, CC3.0 by SA" or "courtesy of Simon Wardley (LEF) CC3.0 by SA"  or even a simple "courtesy of Simon Wardley" is appreciated. 

2) Wardley - Duncan Mapping
If you call the technique "Wardley - Duncan Mapping" then this is fine as it pays homage to James A. Duncan who was instrumental in the early stages of mapping. If you want to add a more explicit attribution line then any of the above are fine.

3) Value Chain Mapping 
This is an alternative name of the technique and if you're going to call it this, then ADD an attribution line. Since the LEF does provide me time to promote and teach others how to map, I have a preference for the attribution "courtesy of Simon Wardley (LEF) CC3.0 by SA".

The only thing that will actually annoy me is seeing the technique without any reference to my name. Since, I've put the hard work in over the last decade then I'd be grateful if you could at least mention me when using it.

Saturday, January 17, 2015

David Cameron in 'cloud cuckoo land' over plans to deify security services

The prime minister’s pledge to give security services omnipotence is ‘crazy’, experts say. Religious and security specialists have told our gallant reporters that David Cameron is “living in cloud cuckoo land” when he suggests a new Tory government would ascend ordinary intelligence agents to a new pantheon of Gods. 

Independent expert Ive Noclue said: “It’s crazy. Cameron is living in cloud cuckoo land if he thinks that this is a sensible idea, and no it wouldn’t be possible to implement properly. You can't just go around turning ordinary intelligence officers into divine beings and creating a new omnipotent pantheon. This is obviously what the Tories are planning to do and it's not sensible."

Other security experts echo Noclue, describing the approach as “idiocy” and saying Cameron’s plans are “ill-thought out and scary”. The UK’s data watchdog has also spoken out against “knee-jerk reactions”. One expert privately voiced concerns that "Many of today's problems occur from an already diverse pantheon of Gods. Adding more could exacerbate the problem. This Tory policy is just downright wrong. What happens if these new Gods start competing religions? What happens if one of these new Gods decides they're going to change reality or has a bad day and starts lobbing lightning bolts around? The consequences of this should have been thought through".

Meanwhile a start-up has warned on the possible effect on Britain’s nascent technology sector of Cameron’s plans. BurnYourCash has said it is already making plans to leave the UK if the Conservative party is re-elected with this policy of creating new Gods in its programme. 

On Monday, Cameron made a speech in which he decried the ability of ordinary people to have conversations on which the security services were unable to eavesdrop.“In extremis, it has been possible to read someone’s letter, to listen to someone’s call, to mobile communications,” Cameron said. “The question remains: are we going to allow a means of communications where it simply is not possible to do that? My answer to that question is: no, we must not.”

Noclue said "It is obvious from Cameron's statement that he plans to turn ordinary intelligence officers into divine beings giving them omnipotence and impacting the whole religious, social and economic order of the world."

Other experts have thrown cold water on the plans, “Yes you can pass laws in Westminster until you’re blue in the face but it's not practical” said Renta Os, another expert in the field. “Citizens, businesses, and nation states need to protect themselves but creating a whole new pantheon of Gods is just not the answer. Cameron’s plans appear dangerous, ill-thought out and scary."

This new debate has political implications with alternative parties claiming "We will not be making any new Gods as part of our policy programme. That's our pledge to the public. Your Gods are safe in our hands". Our reporters were unable to get a response from the Conservatives, providing further clear evidence of the nefarious plans.

Off the record, one political commentator did state "I don't think Cameron said he was going to create new Gods, did you check the text? I think you're extrapolating wildly. It's about as daft as saying he intends to ban encryption. He didn't say that either."

For more on this breaking story ...

Friday, January 16, 2015

The use of SWOTs in strategy

Two simple graphics ...

SWOT is a useful analysis tool for determining whether a particular or combination of attack / defence points have any potential. In order to understand where you can attack or defend you first need to map the environment, identify likely competitor moves and then determine your options. After this you can apply your SWOTs to evaluate options.

However, once you have determined your most favourable option then you still need to determine whether it is feasible i.e. you need to examine resource requirements, how you're going to achieve this etc.

When developing a business strategy, the order I use is ...

1) Map
2) Determine options (wheres)
3) SWOT each option
4) Determine preferred option (the why as in why here over there)
5) Business Model Canvas on preferred option (feasibility)

I don't see a great deal of point in use in tools like SWOT if you're not going to first map out the landscape.

Getting stuff done

You've been given some project / business line / whatever to examine and get going. How do you start?

The following steps are what I find useful. If you're working in a large organisation then based upon experience, I can confidently state that if you follow the steps you'll be able to reduce costs significantly in the organisation over time (i.e. as ridiculous as this sounds, 90% reductions are not unheard of). You'll more effectively capture markets against competitors, you'll reduce failure, improve communication and you'll increase your speed of delivery.  I don't expect you to believe me and I'm not going to waste my time trying to convince you. Talk it all with a pinch of salt but ... have a go.

This is more of a refinement for those who have already started mapping.

1) Needs!
Start with user needs. Identify what the real user needs are. DON'T start with what your needs (e.g. make profit, be successful) ... start with the end user.

2) Value Chain!
Now work out what components are needed to meet those needs and create a value chain.

3) Map!
Now map it by adding evolution. NB, I use the terms uncharted to industrialised to describe the different areas of the map (the old lingo was chaotic to linear). These different areas have polar opposite properties and everything evolves from one to the other.

4) Challenge!
Now compare your maps to other maps for other projects or lines of business in other departments. Look for the clusters i.e. in the following diagram, the everyone treating the activity in the same way - the red dots - with you standing out on a limb - the green dot. I collate my maps to find common activities in multiple maps and produce the distribution chart shown below. I find this very useful in tackling bias in a group e.g. the insistence that their ERP is a rare and poorly understood activity requiring a custom built system.

Don't skip this step - there's nothing more annoying in a large organisation than to start implementing something like a rules engine and then discover halfway through the process that the organisation has six other rules engines hidden away in different groups. This will help you find who is already building what you need.

Also try and compare your map to how competitors treat actions. If you're really lucky your organisation has some form of intelligence unit that keeps tabs on this and they can do it for you. If your organisation doesn't have multiple maps, well ... that's a pity. You can still challenge by asking questions such as how are we treating this, trying to find areas of efficiency etc. Suggest to your executives it might be a good idea for the company to learn about situational awareness.

5) Adjust!
Now adjust your map accordingly. Many of the things you were planning to build are already built by others (the red dots), so use them. Some of the things you were treating inefficiently, so change it. If you're lucky then some of the components you're going to build can also be provided to others e.g. a more commodity form of an existing act.

If unfortunately you don't have maps of other departments / groups or any intelligence function then you won't know what others are really doing other than by going around and asking people. This is incredibly tedious, so try and encourage them to map in future as it'll help find stuff.

6) Think!
Now add a bit of strategy. Since you can see the environment then you might as well take advantage of it e.g. commoditise some things, create ecosystems, exploit inertia or buyer / supplier relationships, anticipate others moves, try to differentiate, there might be unmet needs ... whatever. Lots and lots to choose from (the wheres).

Try and determine why this route over that. Ideally your organisation will have an overall map with the high level strategy defined. Use this. Look at competitors, what their likely moves are, how you can manipulate the market to your favour. Again, if you don't have an intelligence unit or maps then you're a bit stuck on this. Still, it's better to start somewhere.

Tools like SWOT are perfectly useful for examining an individual where however use the maps and all the different points of attack to determine your overall play.

Once you've worked it out, mark up the map accordingly. This intended strategy needs to be shared with all parts of the organisation as others will be able to take advantage of your moves i.e. your move to build a commodity service might enable another part of the organisation to now build something they need.

7) Methods!
Now you have an idea of where you can attack, why you're going to attack one route over another, what the user needs are, what components are involved, what you already have or already use in the organisation (avoiding duplication), likely competitor moves etc then we can get onto the how. Treat the system as small components, don't try and treat it as one thing by applying single size fits all methods. Remember the characteristics of activity (and practice, data and knowledge) change as they evolve and so multiple methods are needed.

8) Simple!
Now, use those FIST principles (Fast, Inexpensive, Simple and Tiny) to break up the system into small teams. Any time a team looks like it's going to get bigger than twelve people then break it down again.

9) Evaluate!
At this point, you've probably done a lot of work ... maybe as much as a whole day (unless you've had to go around different groups finding out what they're doing because no-one has maps). Give yourself some applause.

You'll understand the landscape, you'll know your user need, you've got an idea of where you can attack, some ideas of potential competitor moves, you've determined why one route (or multiple routes) over another, you've even got an idea of how to build the whole thing without duplicating etc. You're in pretty good shape but you're not done.

Now, you need to determine whether this is financially viable and whether we can play this game. Using the map, estimate some of the costs, determine your business model and fill out a business model canvas or something like it. Most of the information you'll need for this (e.g. key activities, partners, resources, value proposition, potential revenue streams etc) you should have already discovered on the journey to it but give yourself another half day.

At this point, I normally have a map of the environment (possible sub maps), a strategy based on the multiples wheres (with often some supporting SWOTs of individual wheres - many of which get rejected), a business model canvas for my plan of attack and a pretty decent idea of how to play the game. 

Now, if for whatever reason the current approach is not financially viable (e.g. some of the components are too expensive) then you can go back and look at the strategy i.e. maybe we should commoditise those components first or save the play for a later day. Do remember that eventually components will commoditise due to supply and demand competition, hence what is not viable today might become viable tomorrow. The map alone will be useful to other groups, so share it with the rest of the company.

Approval (i.e. any need to gamble investment) is hopefully a relatively quick process given it's easy to challenge a map and you have all the supporting information (e.g. BMC, SWOTs, comparison to competitors etc). Most of the time I've found the usual response to be "this is so obvious why is no-one else doing it?" which brings its own challenge. 

At worst, you should find that you're spending two days on this entire process but remember, those maps aren't wasted effort as others can use them. If you're spending more time than this on getting to an approval state then either :-

a) You lack experience in mapping out environments - that's ok, you'll get quicker. Don't try and create perfect maps, there's no such thing.

b) There's a lack of maps elsewhere i.e. you're spending too much time trying to find out what others are doing. This could add weeks to the process in a large organisation and it's highly inefficient. Try and encourage others to map, it'll help you find the duplicates. One of the worst examples I know is of one organisation with over 120 different implementations of the same thing in different groups / functions and departments. Though, for totality of duplication and uselessness, it is beaten by another that has managed now to reduce their application estate from over 8,000 applications to slightly under 700.  Yes, 87% of the estate was pointless. Of course that was obviously great for vendors and sucked for the company. As a rule of thumb, in any large organisation then I'd ask how many instances of this thing do you know of (e.g. the one you're  planning to build and maybe the one other you know about of the top of your head) and whatever you say, I'd multiply by 10 - there's always vastly more duplication than you realise. 

c) You've no intelligence function and so you're trying to learn basic economic lessons, competitor moves etc. Always a nuisance, this can add further weeks to the process and without maps then you have no way of recording what works and what doesn't. If necessary, set yourself up as the "intelligence" unit and get everyone else to send their maps to you. 

d) Determining strategy is hard - this is normal. Most people have no real experience of strategic play having been bought up in a business world which relies on copying others and little to no situational awareness.  It takes quite a bit of practice to get good at this and certainly if you're playing strategic games at a high level (i.e. overall company strategy on a national scale) then this can take a few days to a week (though that's a bit of overkill). I'm afraid it can take you years to get good but don't panic, you're playing usually against others who have little to know situational awareness hence even basic moves like "fool's mate" work. You've got to start practicing and so this is as good a time as any.

e) The approval process is slow. There's not much excuse for this, ask why?

The other line which comes up is it's complex or the line of business is complex. That's almost always complete gibberish and is more a signal that people don't want to think about it. Mapping tends to expose people to hard questions and that's not always popular.

9) JFDI!
Now, once you get approval then you've got everything you need to form your teams, fill them with the right sort of aptitude and attitudes. Get your teams to put up kanban charts and just get on with it. They should all now understand the landscape, what's available, the strategy, what methods are best suited etc etc.

10) Iterate!
Remember keep an eye on the map, watch for competitor moves, make sure teams are kept small etc etc.

--- tools

The mapping technique is Creative Commons 3.0 Share Alike. If you need a tool to help you map, well ...

a) The LEF (Leading Edge Forum) has a free mapping tool available online. It's not open source yet but that'll be announced soon enough.

b) The Wardley Maps Group has an open source tool available. I've no involvement with this group but I'm absolutely delighted they are they doing this and taking the spirit of Creative Commons to heart.

c) Lots of people just use pen and paper, Visio or equivalent.

--- books and variations

There's three books which refer to mapping. The excellent Digitizing Government by Alan Brown, Jerry Fishenden and Mark Thompson. Also Jez Humble includes it in Lean Enterprise which I've not read yet but I'm looking forward to it. 

The WardleyMap crew have also stitched together a community book based upon many of my old blog posts on the subject and there's a community effort to make it better. 

There's also this blog which has mapping scattered throughout it.

There's also variations of the map concepts e.g. 18F has an interesting take in their post on 'How to Use More Open Source in Your Next Federal IT Acquisition'

--- notes

This post is an update on the "basics repeated again". I've added the comparison to other maps more explicitly (this is an incredibly useful first step) and simplified the management of the different methods into one single step.

The accidental consequences of connecting 100 billion+ dumb things together

Back at Ignite SF in 2007, I gave a talk covering commoditisation, evolution, 3D printing and the web of things. I finished the talk with a concern that I had repeated before and since. That concern I summarised in this image - the matrix will be built from a lot of basically dumb things.

I'm not a fan of the pantomisation of science and hence I'm uncomfortable with the recent open letter on AI research with celebrity endorsements. This is not how we should be funding investigation into science and the intent of the letter can only be seen as attempting to lobby and influence funding directions. I view it as misguided.

I do share concerns about the future of AI but then I take a different view from most on where it will come from. Neurons whilst complex components (receiving, transmitting and storing signals using a mix of electrical, sound and other transmitters, able to connect to other components, responding to the environment and changes in the environment) are essentially dumb. The "intelligence" is in the interconnections, the constantly adapting matrix of all the signals and signals processing.

My concern is not that we will create "AI" through some concerted effort (I view this as hubris) but instead that we will accidentally build "intelligence" through the simple act of connecting 100 billion+ complex but ultimately dumb components with the ability to receive, transmit, connect and store using a mix of mechanisms and sensors. 

Let me emphasise that point - we are already building the matrix, it's called the Internet of Things. We just don't know it yet. We're not deliberately doing so and when the "intelligence" is discovered then it certainly won't have been created through any planned effort of our own but will have emerged and evolved in the space between devices. It'll simply exist in the interconnectedness of billions upon billions of dumbs things. 

At that point we're going to have to work out how to communicate and reason with it whilst knowing our lives, supply chains and economic systems are all dependant upon the billions of dumbs things that enables it. We simply won't be able to switch it off, separate it or apply "rules" to it etc.

When will it happen? We don't know, it'll need to emerge and evolve first. We don't even know the starting conditions for this nor whether some constraint would prevent it from happening. It could be hundreds of years away.

Does evolution imply competition? Yes. In all likelihood if it does occur then there will need to exist multiple competing forms of simple intelligence in this space to drive its development to the point that we notice its existence.

Can we influence its development if this happens? We're unlikely to notice it until one form becomes advanced enough that we  can discover its influence. All we need to do is connect huge volumes of these dumb things together, write endless non related systems that interconnect them and wait.

Isn't this like monkeys writing Shakespeare? Nope, think more along the lines of swarm intelligence (e.g. from ant colonies to co-operative behaviour in populations of bacteria).

--- 17th Jan 2015

This all depends upon nodes, connectedness and the ability for multiple forms of intelligence to emerge and compete in an environment.

Remember :-
* life itself is fundamentally about maintaining and reducing entropy
* the cycle times between such populations (unlike in biological systems) could be exceedingly short (orders of milliseconds)
* competition will naturally drive to more stable components enabling higher order systems and therefore higher orders of intelligence to emerge
* life and the development of intelligence is itself simply a series of bugs, unforeseen circumstances and accidents interacting with competition.

Out of interest - Google's secretive Omega tech just like LIVING thing. Even a cockroach has a million nodes with a billion interconnections. Then of course, you have to multiply up to create competitive environments. Still, with a 100 billion devices and say a trillion different interconnections then you might find space for a few roundworm like intelligences to emerge. Don't expect to be having startling and witty conversations over dinner with it.

The real question for me is therefore will we create artificial intelligence before it emerges?

Friday, January 09, 2015

On services ...

When mapping a complex environment, the connections between components (whether activities, practices or data) are interfaces. Those interfaces maybe provided through programmatic means (e.g. APIs), user interfaces (i.e. a webpage) or other means (e.g. physical interfaces). 

However, those interfaces evolve as the component evolves. The interface starts as highly unstable (e.g. constantly changing) due to the chaotic and changing nature of the component. It's novel, it's new, we are operating in the uncharted space of the uncertain. Over time as the component becomes well understood then the interface becomes more stable, even giving an impression of order as the component becomes more of a commodity. For example, a plug and socket are well understood, well defined interfaces which mask the complexity of generating electricity from your average user.

So whenever you map out a complex system or business, you not only have evolving components but the interfaces have different levels of stability (see figure 1).

Figure 1 - Interfaces in a map.

When a component is consumed by others within a more complex systems (e.g. electricity consumed by a computer) then there is a cost associated with any change of the interface or the operation of the component. We experience this (in a trivial sense) when we visit a different country with a different regime of power supply / power standards and we need to take adaptors to cope with the change.

With a large volumes of users consuming an interface in a plethora of complex systems then the total cost of change can be significant. For example, try changing national power supply standards or currency (such as decimilisation in the UK) or the switch to digital TV. Users will tend to collectively resist such a change unless overwhelming reasons are given.

This resistance tends to stabilise the interface and discourage the provider from changing it. This is why your electricity provider can't decide to change the interfaces (e.g. frequency, voltage range) every week and if they attempted to there would be a huge public outcry. This is also why volume operations based services such as cloud services are really only suitable for when the activity has become a commodity and the interface can become relatively stable in a short period of time.

This doesn't mean that you can't provide your brand new "never invented before" concept through an external API to others. However given that the interface is going to change an awful lot in the beginning as we explore what the new concept is, this will limit the volume of users you can support i.e. for some brand new concept then we're talking very few consumers. If you don't believe me, then when you next invent some brand new (never invented by anyone else before) activity then try providing it as a utility service and start changing the interfaces weekly as you discover more about it. The one thing you're not going to build is a volume based service with a large volumes of users. It's simply not ready for it.

Volume based utility services provided through APIs are only suitable for well understood and well defined activities - things like provision of computing infrastructure, CRM, databases, platforms, specific widely used applications etc. These have all had decades to become widespread and well defined enough to be suitable.

Now, when you look at an interface, it simply provides a mechanism of meeting the need for a higher order component (remember these Wardley maps are based upon a chain of needs vs evolution). Hence, from figure 2, the user need is met by component A. However component A needs both component B & C and so forth.

Figure 2 - User Needs and Interfaces

Remember sometimes those interfaces can be provided by APIs, sometimes they are physical interface (e.g. plug in socket), sometimes a user interface etc. Now, in the above diagram, let us consider three user needs - represented by components A, B and D - that we wish to provide as external APIs to others. 

Component D represents a highly evolved commodity-like activity suitable for volume operations where the interface should be relatively stable (an example would be infrastructure such as EC2). These can be provided as utility services and will normally end up over time having multiple providers or ways of implementing.

Component B represents an activity which is in the product phase of competition (i.e. it's still evolving). Hence there will be lots of competition between alternatives on feature differentiation and as a result change. It could be provided through an external API and is more likely to be a very "product" specific rental service rather than generic utility service.  There is usually only one provider for each product type, little duplication of interfaces and no guarantee that your product vendor will end up being the long term utility provider. You can usually see this difference in the language people use, naming specific providers rather than the generic activity. Hence rather than talking about a generic activity such as collaboration, people will often talk exclusively about the specific instance such as Microsoft Sharepoint. This doesn't mean Sharepoint can't be provided as a service, it can and is. However, it represents more of a rental service (often more suited to a subscription basis) as opposed to a utility service.

I know people call both Amazon EC2 & Microsoft Sharepoint both "cloud" services but then that's the awfulness of that dreaded word cloud. Amazon EC2 is far more of a utility service than Microsoft Sharepoint which is still more of a rental service for a product provided over the internet. Collaboration software isn't quite there yet.

You get quite a lot of this "cloudification" of things (for want of a better word). For example, if I take MySQL and run it on EC2 have I created a MySQL Cloud? No, I've stuck a product on a utility service. The process of trying to provide this to a large numbers of users and billing as a utility will certainly end up converting this to a more utility service (databases are evolved enough to be suitable) but whilst the interface to MySQL might remain the same, the system will be very different.

I try to avoid the word "cloud" and instead break down systems into their components. Some are utility whilst others are more products. The two are not the same.

Component A represents an activity which is relatively new (i.e. not widespread and well defined). Though it can be provided through APIs to others, the interface will change very frequently. It really isn't suitable for attempts to provide it on a volume basis through a rental / utility service to others but that won't stop people from trying. This is more suitable for discrete provision to a single or few clients whilst the activity evolves.

I suppose what I want to emphasise here is that the interfaces also evolve as the component evolves. That's a fairly obvious point but one to emphasise. Also when we talk about a services based organisation, then in the technology sense we're mainly talking about building an organisation where many of these interfaces are provided through APIs. However, just because you provide APIs doesn't mean all APIs are the same - some are inherently more stable than others due to how evolved the activity is. You need to factor this in.

The best guidance to building a services based organisation was apparently written in a memo by Jeff Bezos in 2002. I've not seen better since, so I thought I'd copy the spirit of that memo here.

1) All teams will henceforth expose their data and functionality through service interfaces.

2) Teams must communicate with each other through these interfaces.

3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

4) It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter.

5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

6) Anyone who doesn't do this will be fired.

This was 13 years ago. I just thought I'd emphasise that point because I hear people talking about building a services organisation (e.g. use of micro services) as though this is some radically new idea. I'm not against this, it's a good idea but just be aware - it's not new and this is more about keeping up with the pack rather than gaining an advantage.

Thursday, January 08, 2015

Basic Rules on Conference Speaking Requests ...

I (like everyone else) submits talks via CfPs to conferences that I'm particularly interested in - sometimes I'm lucky, sometimes I'm not. I also get invited to speak at many conferences around the world and whilst it is pleasing to be invited, the majority of these I turn down. There are some basic reasons why I turn down conferences. So, I thought I'd put together a checklist for conference speaking requests. This, of course, excludes LEF & LEF member events, O'Reilly Media, London Cloud Camp and requests from friends which are dealt with differently.

The basic rules are ...

Q1) Is this a specific request or a vague enquiry? If "vague" then I'm busy - even if you haven't told me when your mystery event is.

Q2) Are you paying my expenses? If "no" then I'm busy. I wasn't planning on being at your event, I expect you to compensate any costs.

Q3) Am I travelling business class for any long haul travel? If "no" then I'm busy. If I didn't submit via CfP then I certainly don't want to add discomfort to an event I wasn't planning on attending.

Q4) Are you paying my expenses including flights and hotels directly or do you expect me to pay and then claim them back? If "pay and claim back" then I'm busy. By asking me to pay and then submit a claim, you're asking me to either personally loan you the money or invoke internal company expense and travel policies as the company will need to invoice.  Both circumstances are a quick route to "I'm busy". Make my life easy or I won't attend.

Q5) Is this relevant to my research on competition? If "no" then I'm busy. I'm not going to put the work into speaking if I don't see any value in attending.

Q6) Do I need to fill in lots of forms? If "yes" then I'm busy. Make my life easy.

Please note, the following things don't count as alternatives to direct payment of business expenses and avoidance of form filling …

1) A prestigious event  [please note, everyone claims this]
2) A great opportunity [ditto above]
3) A large number of CxOs attending [ditto above]
4) Potential for marketing [ditto above]

If you pass this list AND if I'm free then I'm happy to consider speaking. However, save yourself the time of asking me if you don't. 

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) - 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 - see 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).