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.

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. 

I do recommend you read GCHQ's report on managing organisation and disruption. 

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.

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.