Thursday, July 28, 2016

Show me a map!

A Geographical map is a map

A Chessboard is a map

A Wardley map is a map

They are all maps because they share the most basic elements of a map which are visual, context specific, position (which requires an anchor e.g. compass, the board or user) and movement of the components. Some of them have advanced properties like flows of information between components (NB a flow between components is not the same as movement of a component). These maps are all useful for learning, communication and strategic gameplay.

I often visit new companies and they tell me that they use maps. I get excited and ask to look. Unfortunately what they show me are usually box and wire diagrams which lack basic elements of mapping. From a strategic point of view they are next to useless. They then often try to show me their strategy based upon their maps which invariably is the usually endless round of meme copying, consultant blah blah and wasted effort.

Please note, the following are NOT maps. That isn't to say that don't have their use, they do in specific context e.g. improving efficiency on an existing process. They can also be a damn good start towards mapping and are certainly better than nothing. But from a point of strategy or learning then these won't lead you to improved situational awareness.

Business Process map (Lacks movement, not a map)

Mind Map (Lacks anchor, position, movement and is not a map)

Flow diagrams (Lacks position, anchor and movement and is not a map)

Value Stream Map (Lacks movement and anchor is not a map)

SWOT diagrams (Lacks pretty much everything, not a map)

Strategy Map (Lacks position and movement, not a map)

Trend Map (Lacks pretty much everything, not a map)

Tube like Map with bits added (Lacks pretty much everything, not a map)

Customer Journey Map (Lacks position and movement. Not a map)

What I'd like to see from Brexit - part one of many.

Following on from my post of less of, more of regarding nation states - I'm firmly in the "more of" camp and would like see Brexit taking this direction. As I said I have my own strong biases here.

Figure 1 - Nations States

I thought I'd write a few posts and scribbled thought processes around this over the next few weeks.

Structure & Market
The neoliberalist ideals of less Government, laissez faire, market knows best are quaint but a simple examination of Western society shows that they are both divisive and less effective compared to a more social capitalist system such as China.  Without addressing these issues then the neoliberalist concepts is the road to serfdom as much as national socialism. 

Let us explore one aspect of this discussion, the market. This is not a force for good or evil, it is simply a mechanism of exploitation which can be used for either good or evil. It contains many failures from discounting the future to asymmetric information to externalities and as such it needs management. Hence my preference is towards social capitalism, a view of the use of the market where appropriate as a tool to achieve an end. In the words of Deng Xiaoping "It doesn't matter in the cat is black or white, so long as it catches mice"

For example, industrialised utilities need to be regulated to prevent exploitation but the full force of the market should be allowed to rage in areas of product development. We should be mindful that the market works well when investing in applied R&D (the exploitation of research for a commercial opportunity) but tends to underinvest when it comes to basic R&D. This creates problems for the future (something the market tends to discount) because basic R&D tends to be the source of applied R&D. Accidental discoveries happen more often when experimentation is invested in.

Of course, this is all complicated by the simple fact that things evolve due to supply and demand competition. Hence the system you require to encourage basic R&D is not the same system you need to encourage its exploitation and that is not the same system you need to manage its provision as an industrialised utility. To summarise, I've put the simple path of an activity in figure 2 along with some basic approaches.

Figure 2 - Structure & Market

For example, in the exploration of new fields (a pioneering stage of wonder) then the role of Gov should be directed invested to encourage and enable exploration. It's a gamble on the future but all exploration of the uncharted space is. Large investment programs around basic R&D without the paraphernalia of exploitation (e.g. ROI) is required.

When things are discovered, the market should be allowed to exploit (with potentially the Gov taking a VC position). This is more a settling stage, a more peaceful stage of product development where sustaining development tends to rule, it is a time of refinement and learning. A more hands off free market approach is required (as per Hayek) with light regulation to encourage competition in all directions but to limit obvious market failures.

As the industry develops it will naturally gain inertia due to past success and hence a more directed is required again to force it towards utility forms. Though inertia exists in earlier stage changes e.g. custom to product, none of these are significant or more threatening than the change from product to commodity. That change is also essential for strong componentisation effects and future development. Hence Gov will need to take a pro-active and directed approach to force change usually by encouraging new entrants with more commodity forms into the market and reducing any regulatory barriers to entry.

As the change finds a new equilibrium around a commodity, a more free market around tighter regulatory constraints can develop to be provide well ordered components. This is more the town planning phase and it's here that nationalisation may become necessary if markets cannot behave and attempt to force differentiation on a commodity for reasons of self interest.

Everything evolves through the path but the trick is when does Gov invest or switch given we have a mass of activities evolving?  In the case of basic R&D that should be a constant, set at a high % of GDP. As soon as the market starts to exploit and custom build in a space that previously was being researched then the Gov should cut back in that space and re-invest in future explorations. Evolution during the settling phase is highly unpredictable because each step depends upon individual actors action. The best a Government can do here is in the early stages to encourage the formation of hubs or physical ecosystems with firms located near each other. Obviously this also gives opportunities to cope with other social pressures by dispersing those hubs around the country. However, beyond such encouragement the Gov must step back and interfere only when there are examples of clear market failure - health and safety, monopoly etc.

The inertia phase between product and commodity (a time of "war" as in "war with the past") is broadly predictable because it depends upon aggregate competition - see figure 3. Once companies have started to move across the boundary then defacto standards will emerge and the market encouraged to develop around. Since we can anticipate it, the Government can also effectively direct investment to encourage the change.

Figure 3 - Points of change

Hence using the above (from early 2014), as a Government then I would have been -

1) Focusing on defacto standards and encouraging industry adoption with IaaS / PaaS (i.e. cloud). Hence encouraging growth and development of a commodity market around Amazon, Google and MSFT.  This is something I'm glad to see the UK Gov has been doing with all those companies setting up operations in the UK. Unfortunately even within Government there are some departments (e.g. HMRC) that seem to be stuck in a product mentality (i.e. building rental services such as private cloud). I'd probably be looking at regulating in favour of standards around AWS, Google and MSFT and given free sovereignty introducing laws to enable Gov to declare specific APIs as open standards.

2) Encouraging creation of utility services around Big Data with Gov acting as a VC in this space with significant scale investment but less of them. This field was just at the cusp of entering the "war" and a bit of directed investment by Government to encourage new entrants providing utility forms was required to overcome inertia that many product vendors would have.

3) For the vast majority (IoT, Robotics etc) then a free market is appropriate. I certainly would be looking at providing incentives to create hubs of companies purely due to the effects that local proximity and the movement of staff have in encouraging competition. Over time, some of the markets will need directed investment as inertia barriers are reached and new entrants will need encouragement to create commodity forms.

4) In the area of intelligent software agents, just on the cusp of leaving the genesis stage (the wonder) and entering the stages of custom built and products (known as peace) then I'd probably be planning to cut back on Government funded R&D and directly investing in creating hubs of companies to exploit and develop the space. I'd be acting again as a Gov Investor but more like seed funding with a high degree of uncertainty i.e. lots of very small bets.

5) In certain areas, Materials, Epigenetics, Bio Manufacturing, Hybrid printing then Gov would need strong R&D efforts to encourage exploration. I would certainly be providing disproportionate funding in those areas compared to say Robotics or IoT in which the market players should be investing.

It's probably worth noting in the above that there are different styles of investment from a few big bets in the product to utility "war", to incentives and encouraging hubs (i.e. physical ecosystems) to Government seed funding and directed funding into basic R&D. Do note, the way you invest in the creation of a company around a new activity is very different from the way you should invest in a new entrant building a utility for a pre-existing system. There are very different risk profiles, practices and gameplay that should be followed.

The point of this post is simple, even with something like managing the market then the Gov needs to be adept at applying multiple methods and techniques at the same time - using a Keynesian style approach in one industry whilst using a Hayekian style approach in another. This is, of course, just one small aspect of social capitalism and to operate it requires high levels of situational awareness and gameplay within Government. 

If we don't become better at this gameplay, don't expect other nations to the return the favour.  In particular, China has become very good at directed investment, encouraging markets around hubs of companies and applying appropriate Government methods to the context. The level of strategic play in China vastly exceeds that which I normally see in the West.


For reference, there are various post describing the cycle of peace, war and wonder. Two that I particularly like are Revolution and The Best Summary.

More of, Less of and Nation States.

Many years ago, I talked about how organisations evolve caused by a particular cycle known as peace, war and wonder (an economic counterpart to Holling's adaptive renewal cycle). This cycle is caused by an interplay of evolution from competition, co-evolution of practice, inertia caused by past success and network effects creating a punctuated equilibrium.

The most interesting part of the cycle is the "War" part (as in "War with the past"). What happens is underlying activities shift from product to utility initiating the rapid spread of emerging and co-evolved practices which in turn cause new organisational forms. 

Back in 2011, the change in underlying activities (e.g. compute shifting from product to utility) was leading to a change of practice and a new organisational form, described in the diagram below. Firms were either becoming "less of" traditional and "more of" next generation or potentially putting their future at risk. I'm pinching the less of, more of moniker directly from GCHQ's most wonderful document boiling frogs.

Figure 1 - Changing organisational form.

The point of "War" (i.e. industrialisation from product to commodity) is broadly predictable in terms of when and what (general effects) but not whom. This is because the change itself is driven by competition of all market actors whereas the company that initiates it depends upon an individual actor.  In other words we can say roughly when something is likely to evolve to a more industrialised form, we can say what general effects will occur (co-evolution of practice, inertia of those stuck in previous models of products) but not specific effects i.e. what the co-evolved practice will look like or which company will lead the charge. 

For example, we knew that something like Devops would emerge but not what the detailed practices were (until they emerged) nor which individuals would drive it. However, even those small areas of broad predictability can create an advantage because we can prepare for change. Hence back in 2005 at Fotango we knew that compute would become a utility and could prepare for it. Ditto with Canonical in 2008, we knew many of the changes that would occur and could keep an eye out for it and exploit it.

These points of industrialisation (known as "war" as in "war with the past") are calculated from changes in publications and in early 2014 this data provided figure 2. 

Figure 2 - Points of Industrialisation

Now, one aspect I get asked about is "Social Change". Well, I'm expecting significant changes in society broadly 2025-2030. I re-ran the weak signals used in the above in late 2014 and still expect the same.

But whilst I'm expecting change, what that change will be (i.e. what practices will emerge), I don't know. I do expect some nations to resist it (due to inertia caused by past success) but I don't know what they'll resist and which nations will drive it i.e. who will gain the advantage and who will have to adapt just to keep up. Remember, the weak signals in figure 2 are purely driven by changes in publication - so it gives me some information of a point of change approaching but no more than that.

I put this "social marker" in more for myself, as a reminder to examine changing nation states at that time. In much the same way I had anticipated long ago that organisations would change due to the evolution of underlying components from product to utility and waited until late 2010 and early to mid 2011 to test it. I hope the same population techniques I used to create the phenotypic differences of figure 1 should be applicable to nation states. I have no ideal whether the techniques will work, I'll just have to wait and see. But this is an ongoing test for me as to the validity of the cycle.

Whilst I might not know what those characteristics are or who will drive it, I can guess based upon existing shifts in geopolitical power.

I suspect the country that will represent the future nation state is China (hence my interest in researching into China during end of 2014 and 2015). If I was going to make a stab in the dark towards what those characteristics will be, then I'd probably bet here based upon factors which appear to help drive greater competition. Some of the characteristics that I'll pick have already emerged in China but others are somewhat lacking but exist elsewhere (see figure 3).

Figure 3 - Best guess for changes in nation states.

Obviously this is a guess, not based upon data and as such is hugely subject to my own personal biases and wishful thinking. The result (if it occurs) maybe nothing like this. However, this again is more a marker for myself i.e. what I hope advanced nations will become more of which I then can compare to what actually happens (if at all).

Added 28th July 2016

Was asked one of those "China is a communist country, not neoliberal" questions. Actually, that's a really interesting topic and China (from my perspective) is firmly in the social capitalism camp and acting as a venture capitalist. However, the problem here is one of perception, see figure 4.

Figure 4 - Perception and Economic Thought

So, on average it seems when you're talking to someone in the US they often have a difficulty in agreeing with Europeans over what China is (and vice versa) because even within Western philosophy we have different ideas of where economic thought is placed.

Monday, July 25, 2016

What makes a map?

Topographical intelligence is ultimately a mechanism of communication and learning, but what makes a good map? The first thing a map has to be is visual and context specific.

Figure 1 - Visual & Context Specific.

But then any box and wire diagram is visual and context specific. However that isn't enough to learn. In order to understand a context and to learn from it (whether with a chess board or a geographical map) then you need to have position and movement of the pieces on the map. Position is relative to something e.g. position on the board or this piece is north of that piece. That something is the anchor of a map.

In the maps that I've used for the last decade, the anchor has been the user, position is visibility to the user and movement is evolution (i.e. how things change).

Figure 2 - Position and Movement.

With a visual system that is context specific and has position and movement, you finally have something which I would consider is worthy of being called a map. Without position and movement then you have a nice diagram which is not much use for learning, communication or strategic play. However, this is just a starting point. The components of a map don't have to be the same type of thing i.e. there's no reason to limit yourself to activities as you can map practices, data and even knowledge.

Figure 3 - Components and Type

Also within a map, you have flows of risk, information and money. These are also worth investigating. Be careful here, you need a map otherwise it becomes trivially easy to make efficient the most ineffective of things.

Figure 4 - Flow

Finally, with a map you can start to learn climate patterns (the rules of the game), context specific forms of gameplay (strategy) and universally useful patterns (doctrine). The point of a map is you should be able to add on climatic patterns and discuss strategic play around this. You should be able to communicate and challenge assumptions. 

Figure 5 - Climate

Strategy is all about the why of movement and this starts with where do you attack? The strategy bit is determining why here over there. This is different from the why of purpose as in "be the best tea shop in Kent". Acting upon your strategic choices (the why of movement) can also ultimately change your goal (the why of purpose) ... and there was I thinking there was something called permanent "core" (circa 2005). It's an iterative loop known as the strategy cycle.

Figure 6 - The Strategy Cycle

Of course, navigating and learning effectively without some form of map is almost impossible. Instead we find ourselves unable to distinguish between that which is context specific and that which is universal. We become the archetypal Themistocles with a SWOT.

There's an awful lot to a simple diagram like a Wardley map. Most of which we don't mark on the map as it becomes intuitive i.e. we don't have to remind people that the anchor is the user or that you have position & movement, that is taken for granted.

Figure 7 - A Wardley Map

However, topographical intelligence in business, the art of strategy based upon situational awareness remains one of those topics which are barely covered in business literature. The overwhelming majority depends upon alchemist tools such a story telling, meme copying and magic frameworks like SWOTs. It is slowly changing though and every day I come across encouraging signs.

So does mapping make an impact? It certainly seems to on a personal level and there exists a tentative link between situational awareness and success at the corporate level. However, all models are wrong but some are useful. It's a tool that I've found useful is the only claim I'll make.

Figure 8 - Personal Impact

Figure 9 - Corporate Impact

If you are completely new to this form of mapping then I've provided a basic introduction.

Wednesday, July 06, 2016

Observing impact

I've been running an experiment looking at how mapping changes gameplay. I've taken 181 executives through a basic mapping course (i.e. you learn how to map, learn basic economic patterns, basic forms of gameplay) but before I do, I give them a scenario.

In the scenario they are members of the board of a company. They have financial information including P&L, competitor reports, market data, operational reports and a range of strategic options that are presented using SWOT diagrams to business model canvas. They usually work as a small team of 2-4 and are asked to prioritise the strategic options or add their own. Invariably they decide to build some form of digital cloud service, invest in efficiency, expand overseas and invest in product development.

I then teach them how to map and ask them to look at the scenario again. It's worth noting they are giving no additional information on the scenario other than the ability to map. There's a noticeable change in choice with a little more confusion over what to do. The confidence of previous choice is questioned.

I then teach them basic economic patterns and forms of gameplay. Again, they are asked to look at the scenario and no new information is provided to it. At this point a radical change seems to happen. Overwhelmingly after mapping and applying basic patterns then they want to invest in marketing to "pump up" the company in the eyes of outsiders, flog it quickly and rebuild a new company. They've gone from viewing the company as having a great future to viewing it as going over the cliff and hence they need to maximise return.  Their perception has fundamentally changed by simply mapping the environment. 

It's a small sample, 181 executives and we shall see how this develops. Details of the results are provided in the figure below.

What's interesting is they now start to question the basis of previous strategic choices. It's a particular delight to watch someone map something they've done and go "crap, we need to fix this". Makes it all worthwhile to see grizzled executives change.

Thursday, June 09, 2016

How Cloud Foundry will save the world from Yak Shaving

I'll make no bones about the fact that I'm a huge fan of Cloud Foundry. It's the right play, by the right people at the right time. Despite all the attempts to dilute the message over the last eleven years, Platform as a Service (or what was originally called Framework as a Service) is about write code, write data and consume services. All the other bits from containers to the management of such are red herrings. They maybe useful subsystems but they miss the point which is the necessity for constraint.

Constraint (i.e. the limitation of choice) enables innovation and the major problem we have with building at speed is almost always duplication or yak shaving. Not only do we repeat common tasks to deploy an application but most of our code is endlessly rewritten throughout the world. How many times in your coding life have you written a method to add a new user or to extract consumer data? How many times do you think others have done the same thing? How many times are not only functions but entire applications repeated endlessly between corporates or governments? The overwhelming majority of the stuff we write is yak shaving and I would be honestly surprised if more than 0.1% of what we write is actually unique. 

Now whilst Cloud Foundry has been doing an excellent job of getting rid of some of the yak shaving, in the same way that Amazon kicked off the removal of infrastructure yak shaving - for most of us, unboxing servers, racking them and wiring up networks is a thankfully an irrelevant thing of the past - there is much more to be done. There are some future steps that I believe that Cloud Foundry needs to take and fortunately the momentum is such behind it that I'm confident of talking about them here without giving a competitor any advantage.

First, it needs to create that competitive market of Cloud Foundry providers. Fortunately this is exactly what it is helping to do. That market must also be focused on differentiation by price and quality of service and not the dreaded differentiation by feature (a surefire way to create a collective prisoner dilemma and sink a project in a utility world). This is all happening and it's glorious.

Second, it needs to increasingly leave the past ideas of infrastructure behind and by that I mean containers as well. The focus needs to be server less i.e. you write code, you write data and you consume services. Everything else needs to be buried as a subsystem. I know analysts run around going "is it using docker?" but that's because many analysts are halfwits who like to gabble on about stuff that doesn't matter. It's irrelevant. That's not the same as saying Docker is not important, it has huge potential as an invisible subsystem.

Third, it needs to provide a mechanism of billing down to the function. One of the things we discovered with Zimki (the first PaaS) was that in a single application it was often discrete functions which generated most of the cost (Zimki had billing at the function level based upon Javascript operations, I/O and network). By having billing at the function, you cause a radical change in the way people write, refactor and refine code. There's nothing like seeing that 70% of your application running cost is being caused by one function to get you to evaluate that function. It also tends to help performance. The existing usage events in Cloud Foundry are fine but not enough. It needs to go deeper (hint to providers - that needs an asynchronous mechanism of logging, things like network taps, it worked a treat in 2005).

Fourth, and most importantly, it needs to tackle yak shaving at the coding level. The simplest way to do this is to provide a CPAN like repository which can include individual functions as well as entire applications (hint. Github probably isn't upto this). One of the biggest lies of object orientated design was code re-use. This never happened (or rarely did) because no communication mechanism existed to actually share code. CPAN (in the Perl world) helped (imperfectly) to solve that problem. Cloud Foundry needs exactly the same thing. When I'm writing a system, if I need a customer object, then ideally I should just be able to pull in the entire object and functions related to this from a CPAN like library because lets face it, how many times should I really have to write a postcode lookup function? 

But shouldn't things like postcode lookup be provided as a service? Yes! And that's the beauty. 

By monitoring a CPAN like library you can quickly discover (simply by examining meta data such as downloads, changes) as to what functions are commonly being used and have become stable. These are all candidates for standard services to be provided into Cloud Foundry and offered by the CF providers. Your CPAN environment is actually a sensing engine for future services and you can use an ILC like model to exploit this. The bigger the ecosystem is, the more powerful it will become.

I would be shocked if Amazon isn't already using Lambda and the API gateway to identify future "services" and Cloud Foundry shouldn't hesitate to press any advantage here. This process will also create a virtuous cycle as new things which people develop that are shared in the CPAN library will over time become stable, widespread and provided as services enabling other people to more quickly develop new things. This concept of sharing code and combing a collaborative effort of the entire ecosystem was a central part of the Zimki play and it's as relevant today as it was then. By the way, try doing that with containers. Hint, they are way too low level and your only hope is through constraint such as that provided in the manufacture of unikernels.

There is a battle here because if Cloud Foundry doesn't exploit the ecosystem and AWS plays its normal game then it could run away with the show.  The danger of this seems slight at the moment because of the momentum with Cloud Foundry and because of the people running the show. Get this right and we will live in a world where not only do I have portability between providers but when I come to code my novel idea for my next great something then I'll discover that 99% of the code has already been done by others. I'll mostly need to stitch all the right services and functions together and add a bit extra. 

Oh, but that's not possible is it? In 2006, Tom Inssam wrote for me and released live to the web a new style of wiki (with client side preview) in under an hour using Zimki. I wrote an internet mood map and basic trading application in a couple of days. Yes, this is very possible. I know, I experienced it and this isn't 2006, this is 2016!

Cloud Foundry (with a bit of luck) might finally release the world from the endless Yak shaving we have to endure in IT. It might make the lie of object re-use finally come true. The potential of the platform space is vastly more than most suspect and almost everything, and I do mean everything will be rewritten to run on it.

I look forward to the day that most Yaks come pre-shaved. 

Friday, June 03, 2016

Recruiters and daisy chains

The only recruitment firm that I would ever consider using is Superstars. It's run by a dear friend of mine Steve Hutson who I've known for last fourteen years. Steve used to work in the mainstream recruitment industry but began to loathe it because of its practices. He decided to change the way he worked and how recruitment was done. In Superstars, there is no margin, no fees and people are treated as talent, as individuals rather than a commodity shunted about by "human traders" - as one particularly vile firm likes to refer to itself.

There's a lot to dislike about the recruitment industry, so it's good to see Steve succeed in building a new style of firm which changes those practices. One of the worst practices (which I've just caught sight of again, hence the post) is daisy chaining.

Daisy chaining is a based upon the obvious premise that once you find someone a new job then that leaves a hole to fill i.e. their previous job. You can therefore chain a long list of people together and get them to each jump into the next role. This practice is beloved by recruitment consultants as they earn fees on each person jumping, the bigger the chain the more the fee. It also creates a promotion ladder for those in the chain,

I suspect daisy chain is also partially responsible for why I hear large companies complain they can't find big data / IoT talent (when there's plenty out there) whilst real experts in big data / IoT complain they can't find jobs and keep on meeting muppet VPs of big data / IoT who don't understand the basics. The problem is the recruiters want to use the chain (i.e. it's more fees for them) and if you're not part of the chain then you're not very useful. To be part of the chain, you need to have a job so that the recruiter can fill that one to extend the chain and so on.

So basically, just in case it's not clear, the chain works as follows.

Recruiter gets wind (dinners with execs / golf course or whatever) that Company B requires an SVP. Recruiter says they've got the perfect candidate C1 who is currently VP with Company C and offers to make the arrangements, even offering to waive some of the fees because they are friends. Execs agree to meet.

Recruiter phones up C1 and tells them that Company B is desperate to meet with them. 

Recruiter immediately phones up Candidate D1 who is CTO for company D and tells them they have heard that Company C is going to be looking for a new VP. Lines up Candidate D1 for the role.

Recruiter immediately phones up Candidate E1 who is a Engineering Head for company E and tells them that they have heard that Company D is going to be looking for a new CTO. Lines up E1 for the role.

... and so on.

C1 accepts the job of SVP at Company B. The Company B thanks the recruiter for their help - "well, we're partners in this" says the recruiter. Since the recruiter is part of the process, they know roughly when candidate C1 has told their company C that they are leaving.

Recruiter immediately phones up a friendly exec at Company C (those dinners have purpose), chats about how they've heard C1 is leaving. Says they've actually got the ideal candidate D1 who they know is looking and is keen to work there - saves all the hassle of advertising etc. Hint, after laying it on thick about hard recruitment is, many execs are just pleased to hear that a possible replacement can be found quickly. Make introduction. 

 ... and so down the chain you go, every time clocking a % of salary as a finders fee. 

Of course, suppose there is the ideal candidate for one of those roles who is unemployed or not employed in a valuable role that can be easily replaced by another?  Well, they're unlikely to be offered the job because this breaks the chain. Hence if you bother to look, there's oodles of big data / IoT talent out there looking for roles along with companies looking for big data / IoT talent. The problem is your recruitment processes and the companies that you use are broken. 

Friday, May 20, 2016

Wardley's Doctrine

Whenever examining an industry then there is the landscape, the common economic patterns and the context specific forms of gameplay that need to be used to determine strategy. However, these are context specific and vary from industry to industry and player to player. This area of strategic play is the most fun part of leadership and where your true Machiavellian spirit can let rip. There are however some basic principles i.e. doctrine that are applicable to all industries regardless of context. These are universal.

I keep on getting asked by former employees and friends when I'm going to build a company again, so that they can come and work for me. First of all, that's a incredibly kind thing to say and I'm very touched by this. Second, I have no interest in leading again - I'm a reluctant leader only doing so when necessary. Lastly, I think some of those who worked for me have forgotten just how harsh I can be and are looking through rose tinted glasses. For example, I have commandments of operations regardless of what you are doing and from which I do not tolerate any deviation from.

However, in the hope that it might help others, I thought I'd scribble out my current list of commandments - yes, these refine and change with time and experience. NB, these have nothing to do with strategy nor even leadership, they are simply the universal doctrine that I apply everywhere.

Wardley's Doctrine.

In accordance with the wishes of the High Priest Thought Lord, the following commandments will be followed in all circumstances on pain of a most terrible punishment normally involving a good talking to (e.g. hair blower with choice expletives) and then a slice of cake or two in order to recover from the aforementioned terrible punishment.

Thou shalt ...

Focus on user needs. Any value we create is through meeting the needs of others. A mantra of "not sucking as much as the competitors" is not acceptable. We must be the best we can be.

Use a common language. Instead of using multiple different ways of explaining the same thing between different functions of the business, we use one - a map. If you can't map what you're doing then don't do it. Situational awareness is not optional.

Be transparent.  We don't hide our maps, we share them and allow others to challenge and question our assumptions. The act of sharing is essential because it helps us to learn. Transparency also requires us to remove all the noise, the pointless gibberish that gets in the way of learning. Anyone not willing to learn, will forgo the slice of cake and be helped to find a new job with a competitor. 

Remove bias and duplication. We not only share maps, we collate them in an effort to remove duplication (i.e. rebuilding the same thing) and bias (i.e. custom building that which is a commodity). This is not optional and no, your accounting system is not unique because of the colour of your invoices nor do you have a unique way of purchasing advertising space. We all have a duty to remove duplication and bias in the organisation. 

Challenge assumptions. It's a duty for everyone in the company to challenge assumptions. Where possible we use data collated from maps as the purpose of the maps is to expose the thinking. I don't care if it was my pet project, you will openly and honestly tell me why you think I'm wrong. Challenge requires transparency and trust. Any form of retribution or bias against someone for challenging is a deadly sin that will not be forgiven and you will be carted off to work for a competitor. For reference, as the CEO of Fotango, I made my CFO the XO back in 2004. One of his duties was to challenge me and agree / disagree with my choices.

Think fast, inexpensive, simple and tiny.  Ok, Dan Ward might say FIRE (and do go buy his book) but I'll stick with his original terms. You will move quickly with a bias towards action, you will use inexpensive components and be frugal wherever possible, you will simplify the problem as much as possible and you will build in small components ... otherwise you WILL not build.

Use appropriate methods. NB, anyone suggesting we should be all agile, all lean or all six sigma will get a right good talking to without the cake. Same with others suggesting one size fits all purchasing methods.

Use standard components where appropriate. NB anyone suggesting we should build our own cloud service where a defacto service exists runs the risk of getting hauled up in front of company as the person trying to spend the entire cake budget on a vanity project. Unless you can clearly show you can out industrialise and make more of a commodity whatever exists, then use it.

Optimise flow. Whether it is with what we build or how, we are required to remove bottlenecks and improve throughput where possible. However, care must be taken not to make the ineffective more efficient rather than making the ineffective more effective - hence the importance of situational awareness. Anything which gets in the way of meeting user needs, being fast, transparency on relevant information will be treated ruthlessly and for the guillotine e.g. corporate expense processes. Hint, it's usually way more effective to just to give everyone company credit cards, say "spend in the interest of the company" and get accounts to sort through the credit card bills rather than having staff fill out expense forms.

Use small teams. Everything must be broken down into small teams. As a guide, when exploring the uncharted space a team of 3-5 seems appropriate. When building a product / service capability then two pizza (i.e. 12) seems more apt. When providing an industrialised component then a larger team can be argued for. Under no circumstances will that team size approach anything close to the Dunbar number. Anything larger than 40 should be considered as highly dubious and an immediate candidate for dividing into smaller teams based upon user needs.

Think aptitude and attitude. Each team may contain discrete skills (e.g. networks, marketing, engineering, finance) known as aptitudes. But each aptitude has an attitude i.e. the culture, methods and techniques for agile development of an entirely novel act are not the same as those for building a highly industrialised component. When determining composition of team, it is a duty to consider not only the aptitude but the attitude. The combination of both is what we call capability.

Provide purpose, autonomy and mastery. Each team shall be autonomous within the confines of what it is supposed to do (described by a fitness function). Each team will therefore own what it does. Each team shall be able to see how they fit into the whole (hence maps) and develop mastery in both aptitude and attitude.

Design for constant evolution. Whilst a team might become a semi permanent structure, the work it undertakes will evolve. It is therefore a duty to ensure that work evolves through the organisation e.g. a pioneering team discovers an uncharted space, a team of settlers take the work and productise it hence forcing the pioneers to move on. A team of town planners then industrialise the product when appropriate forcing the settlers to move on. 

Manage inertia. We all have it. It's caused by past success. You will realise that you have it. There are about sixteen different forms and you will learn how to recognise this. When you find yourself saying "but this is how we do it" or "but this has always worked in the past" or "don't fiddle with the machine as it ain't broke" then you will question why you are saying this. If someone is challenging what is being done then you will LISTEN and you will ask why you are responding in such a way.

Learn by playing the game. Common economic patterns and context specific forms of gameplay are discovered by playing the game. Hence strategic choices must be made by those who play the game and strategy developed internally and not externally. We must also share what we've learned (hence again, maps and the purpose of collating them). Hiring strategy consultants to write documents telling us what to do will get a another good yelling at and absolutely no cake whatsoever. Certainly use outsiders to learn context specific forms of gameplay but we're the ones playing the game.

Understand that strategy is iterative not linear.  This is for anyone thinking of writing long winded strategy documents, target operating models and step by step plans of how the future will be. Immediately book an appointment with HR. You are a valuable asset for the company particularly if we can deploy you within a competitor. HR will help you find a strategy position in a competitor and you will be given glowing references especially about how sad we are to lose you. We might even try to put up a "fight" to encourage the competitor to think you're an attractive acquisition. We will even pay you to join them. Instead of long winded plans, we will have direction towards a position and adapt as needed. We will "cross the river by feeling the stones".

A final note

The above is my list of universally applicable doctrine. Note, there are many context specific patterns that I use e.g. open source, open data that are not universal but suitable in specific contexts. They are hence not included as they are part of strategic play. For example, I'm not a fan of Open by default as a universal doctrine but rather Open by thinking i.e. the use of open in specific contexts.

These are also not "leadership". This is doctrine which is universal and hence operational. Leadership is more the act of setting the direction (i.e. where we are going) and using context specific play to change the environment in our favour.

Thursday, May 12, 2016

Stopping Self Harm in Corporate IT

If you've worked in any corporation for a time then you will have come to realise that it's not the Darwinian, survival of the fittest, lean and mean chess playing machine that exists in the fantasy land of Harvard Business Revenue (ed. sounds more apt than Review)

Your average organisation is full of

  • duplication. Examples of 100+ projects doing exactly the same thing in an organisation are not uncommon
  • bias.  Lots of custom building that which is already a commodity
  • miscommunication and alignment issues
  • strategies which are a tyranny of action (how, what and when) with little to no strategic reasoning (why here over there) but instead endless meme copying from others
  • constant restructuring to bolt on new capabilities followed by further restructuring to remove it
  • constant missed opportunities where obvious changes are not taken advantage of.

The list goes on and on. As one chief exec told me not so long ago, "We survive because the other guys suck more". It's not so much survival of the fittest (which gives a positive image) but instead survival of the least sucky.

In this post, I'll talk about one relatively simple method to stop the worst excesses of self harm through the use of spend control. This is not about gaining some advantage over others but to solve a particular problem highlighted by another executive - "I've a hundred CIOs running around spending millions. They're like new born infants out of control. My first problem is not they keep burning the cash but that I need to stop them causing self harm. In other words, how do I stop them from wiping their faces in shit?"

Wiping their faces in shit? Sounds a bit excessive. But lets look at the problem. You've a 100 CIOs each operating IT within a business unit. That means you've probably got at least 100 different ERP, CRM, Order processing, Account receivable, Payroll, Storage and other systems. I say at least because it's actually common for a single business unit to have multiple of these things on its own. 

As a naive youth, I used to think 380 customised ERP systems built by 380 different teams was a lot of duplication for a single company but in my more gnarled experience, I realise that a lot is when we get into the thousands. In my naive days of youth, I used to think that 80% of IT spending being wasteful was an outrageous and rare figure. These days, I assume that when I walk into a company that 95% of IT spend is being wasted on duplication, bias and no hope projects. 

When people talk to me about enterprise content management (ECM), I know that in all probability we've got 200 to 300 different ECMs spread among those 100 business units along with at least 2 or 3 global ECM efforts being built by teams who don't know the others exist or only discover each other by accident. The old "We're building a global single sign on solution" followed by the "Oh, but that's what we're doing" followed by the "really? Same here" is an not an uncommon conversation when IT folk from a single corporation get to meet at conferences.

Of course when we talk about popular topics like IoT or big data then there'll be a few hundred business unit efforts, many more hundred skunk works along with a dozen or more global efforts buried under the portfolios of executives looking to be in charge of the next big thing. In a topic like this, you can easily get many hundreds and in the worst cases thousands of people involved in rebuilding the wheel again and again. I know of one global corporate that has 170 different teams building the same cloud projects. 

On top of all this, you'll get projects trying to create interfaces between all the other projects. If you've got 80 different ERP systems and you want inventory list then you'll probably have half a dozen different projects either building interfaces or data warehouses or some other mechanism trying to get all the data together, translated and transformed into a single view. I say half a dozen because why build one when we have such a glorious history of doing the same thing many times at the same time.

Into the mix some CIO will be planning to spend another $10M or so on a data lake, oblivious to the 10 or 20 other data lakes we already have and the further 5 under construction. Naturally, a highly expensive consultancy report being commissioned will probably recommend a lake of lakes - to be home built of course - and is doomed to fail because everyone argues that their lake is special.

This is what most corporate IT is like. If you don't recognise it then you're either very lucky or you need to open your eyes more. For most of you, take your annual IT budget - in the above case say $3 billion. Now double it to $6 billion because a lot of IT costs get buried in other budgets (including basics like power, buildings or contracted out projects). Now multiply by 10% i.e. $600M. This is what you probably should be aiming to spend in total if you're a typical company. In the process of saving huge pots of cash, you'll be making users a hell of a lot happier. Except, you won't actually save anything as you'll end up doing more stuff. This is really all about efficiency.

However, you won't make the efficiency savings. Not because it's impossible but because you lack transparency, challenge and any common mechanism of describing the problem space and removing waste.  Unfortunately, chances are you won't fix this problem. 

Instead you'll probably hire a consultancy firm which will recommend several floors of consultants (surprise, surprise) and a death star project which involves massive cost overruns and never fixes the problem. If you're lucky, a strong CEO or CIO will go "bugger this" and force the entire company down the route of single cloud services. All hell will break lose as business units (egged on by local IT) claim that using Google mail (for example) doesn't fit their needs or the regulators say we can't or it'll impact differentiation or God or some random bloke on the street or the aforementioned consultants (out of fear of not gaining another floor) said it was a really bad idea or isn't "Enterprise Ready" or legal says the contracts aren't "right" for them or "we want to but we don't have time to migrate as we have to sign the new 10 year extension tomorrow" ... blah, blah, blah, blah. Using the axe is a good thing at times like this. 

Anyhow, lets assume you want to fix this and I mean permanently going forward. Well, this has to be iterative and so you can't do a big bang approach.  You can't also just take the CIOs budget away from them. Instead what you want to do is encourage transparency and challenge. Spend control to the rescue!

First, create a spend control group staffed with a a dozen or so people from inside the organisation who have elements of engineering, business and architecture skills. The job of the group is simple - to create transparency and understanding about the IT landscape, to introduce challenge into the process of spending, to advise and support the CIOs on making better decisions and overtime to help the organisation learn and devise strategy. The latter parts are for another day, for the time being our only strategy is to "try and suck less".

The job of spend control is easy to explain. Before a CIO spends any sum of money above a specific limit (use $100K to begin with) then they need to submit a form to spend control, outlining the amount, who with, the user needs being met, the customer journey and a map. This is information the CIO should have and if they don't can be created in a day or so. The spend control group should help here by providing support on how to write a customer journey and a map.

A Wardley Map

Once spend control has this, they should look at the map and check does it focus on user needs? Focusing on user needs should be a core doctrine of the company and something that everyone does.

Now compare the map with other maps. To begin with, you start with no maps to compare or just a few but over time you have many and can create a profile of common components reappearing on different maps. What you're looking for is bias and duplication along with building a common lexicon and you can do this because the maps provide a common language and you have some transparency because people are sharing them.

Once you've identified duplication and bias in your map, you can challenge it.

Some of the components you'll have no other reference to in your other maps but you can still use a cheat sheet to challenge by looking at the properties.

You can also often find unmet needs i.e. those covered in other maps but should be in this one.

You can also look for more industrialised and common components that are suitable for shared services or cloud or common components (the green dots). Later on, you can use this to find new opportunities but that's not the focus of this post.

So, spend control, after a couple of hours work can go back to the CIO and say 


Thanks for the info. 

Around 80% of your project is currently being built by Team [XYZ]. By using those components you should be able to reduce your project cost from $10M to $2M.
The parking system you're thinking of building is likely to be available in the market as a product and doesn't have to be built from scratch. We've had a look and found this project [DEF] which might be suitable.
You're missing a bunch of user needs we think it might be useful for you to include [ABC].


The more maps you collect, the better your understanding of the entire landscape and the more you can challenge. This is an iterative process, you don't try to boil the ocean with floors of mega bucks consultants designing a death star but instead every time a system is designed or comes up for re-compete then it loops through spend control. Bit by bit you clean up the mess building common components as you go.

Now, sometimes spend control has to say No because a CIO wants to do something anyway. Hence it's important that spend control is involved early as some will try and railroad i.e. we have to sign this contract now or else .... blah, blah, blah. The key is, Spend Control doesn't take away the budget but instead introduces challenge and can (in the worst cases) force a CIO to find a better way.

Spend control fulfils the essential corporate roles of understanding the landscape, teaching others how to do this, introducing challenge to project and where necessary enforcing basic doctrine (focus on user needs etc).

Before someone says, we do this already - ask them how many ECMs they have in their organisation and how do they determine duplication and bias. In over 99% of cases, they don't.

Overtime, you can increase the doctrine i.e. you can ensure appropriate methods are applied ...

... or you ensure projects are broken down into sensible contract size and FIST (Fast, Inexpensive, Simple and Tiny) principles are applied.

... or you ensure a sane organisational structure is applied (use small teams).

... or you can ensure that the organisation is designed for constant evolution by considering attitude.

After quite a long time, once you're on the path to getting rid of much of the waste then you can start to look towards more strategic play and at this point then spend control grows into your strategic arm of the company. You can start learning about common economic patterns, start anticipating change in your market through weak signal detection, find opportunities through common services and discover context specific gameplay which you can then use in iterative strategies. However, that's way beyond this post. 

To begin with, we're focused on simply stopping self harm.

Oh and be warned ... lots of people don't like the idea of challenge or transparency especially vendors and consultancy firms. Keep a close eye on those who try and derail it. You're going to get some and whilst the overwhelming majority will simply be innocent inertia, I'm afraid there's a more seedy side. You might well find a few who are "influenced" by your own suppliers - conference events, jollies, gifts etc etc. The problem is that by reducing waste you'll be hitting the bonuses of others. The same approach can also be used in finance, marketing, operations and the business but I'll leave that to another day.

Friday, May 06, 2016

Strategy, Plans and World of Warcraft.

Your plan is your general direction of travel and what you intend to achieve. It describes the goal and your purpose for a mission whether you "plan to win the war" or "plan to take a building".

The battle (whether military or in business) will occur in a landscape. You can choose to consider that landscape or ignore it. The effects of this can be best seen in an online game such as World of Warcraft in the battlegrounds. Often you'll have two teams - one consisting of newbies who run around the landscape because they are lost and uncoordinated and one which isn't. The result ... well, it's a bit one sided with the newbies often blaming the equipment of the other players and each other rather than their lack of competence as a team.

In business, you tend to have multiple companies that don't understand the landscape instead relying on story telling, meme copying, magic thinking and the odd "hero" character that wins the battle. But let's assume that you do decide to understand the landscape.

You now have to decide how to play the game. One of the benefits of mapping a landscape is it not only provides you a mechanism to communicate strategy and challenge assumptions but also to learn from past engagements. We can use our past experiences to determine context specific play i.e. how to deal with the game in hand. In this case, we'll go for a ground assault with some element of suppression fire.

Of course, that's the strategy (i.e. part of our plan) and we now have to implement this i.e. put it into effect. This is the operation itself and for this we'll normally apply common forms of universal doctrine. In the above case, breaking into two small autonomous teams is apt.

So now we act, we're into the game itself. Ideally the speed at which we move from the general plan (take the building) to understanding the landscape to the strategy to operation should be lightning fast. In an online game like World of Warcraft then such choices should be made in seconds which is why you need a well trained, co-ordinated group. In business then the pace is a lot slower, so you can afford to give yourself a day or two. Unfortunately most take many months by which time the landscape and game has changed and yet they still continue to pursue the original strategy. For many that works because you're competing against others who are equally slow and have equally poor understanding of the landscape i.e. it's ok to suck as long as everyone else does - ask newbies, they only start moaning when they come up against a well trained group and get spanked.

Of course, as soon as we play the game then we can experience climatic changes i.e. changes to the environment because of economic effects or competitor actions. In the case of our "take the building" plan then we suddenly find ourselves under fire. 

At this point, doctrine again should kick in which is why we do so much training. There isn't time to immediately create a new strategy, you need to be able to react to the situation. In our case, one group returns fire, the other seeks safety.

Now, our plan of taking the building hasn't changed but our landscape needs to be updated with the presence of a sniper. A new strategy is quickly formed, we organise around it and move. The maps are used to communicate to everyone the play at hand.

This is what strategy should be, a constantly iterating process of observing the landscape, orientating around it and acting. The plan is not some checkbox list but a general direction with fluid strategy and movement. It's an adaptive cycle.

But most companies (and I do mean most as in the overwhelming majority) have no understanding of their landscape. They have no mechanism of communicating strategic play, no mechanism of learning and no way of determining context specific techniques from doctrine. The overwhelming majority are like the newbies charging into the battlefield of a World of Warcraft game. They have a purpose and a plan (what they call the why) as in "Win the game" and then vague hand waving aspirations of how to do this. Sometimes they get lucky.

Of course when they lose, it's all about the "equipment" or other excuses i.e. their people, their culture, the lack of execution or how the plan was wrong but the strategy was right etc. It's almost never about the fact that they had no strategy or anything worthy of the name. Alas, if you don't understand the landscape then you can never learn climatic patterns or doctrine, you're simply jumping from purpose to hand waving and statements like "it's all about the Why".

I've seen billions wasted by companies cluelessly charging into battles that they have no hope of winning because they do not understand the landscape. I've seen endless SWOT diagrams, stories and other magic thinking used to justify such actions. I've seen companies tear apart industries with a modicum of situational awareness.

I'm now a great believer that all executives (with a non military background) should spend three months playing World of Warcraft before being given a position of responsibility in order to learn about team play, situational awareness, adaptive responses and so forth. If you can't learn the basics in such an environment then you shouldn't be let lose on a company with real people.