Sunday, April 05, 2015

The only structure you'll ever need ... until the next one.

Back in 2004, I was the CEO of Canon subsidiary and I faced multiple problems. We had issues of business & IT alignment, poor communication, dissatisfaction and clarity of strategy.  Don't get me wrong we had strategy documents but they were pretty much identikit copies of every other company out there. What we did, and what I've later refined solved [for us] many of those problems because they're all associated with a lack of situational awareness.

The first part of this journey was creating a map of our landscape. The map has two elements. It showed the position of the pieces and how they could move. The position was expressed through a value chain from the user needs to the components required to meet those needs. The movement was expressed through an evolution axis that covers activities (what we do), practice (how we do things), data and knowledge. I usually simplify that axis to show activities alone but in this case (see figure 1) I've added a table to show all the different elements. In other words on a single map you can show activities, practices, data and knowledge if you choose to do so.

Figure 1 - A Map

Table 1 - Different Classes. Terms used.

Oh, and where did I get the idea of producing a map from? I nicked it straight out of Sun Tzu's Art of War and the emphasis on understanding the landscape before taking action. Don't get me wrong, these maps are imperfect but they act as vehicle for discussing, learning and understanding the environment.

When I first produced the map of my company, I didn't realise the importance of sharing it outside the executive team. Our map had our strategic play on it. We had quickly learned a number of common economic patterns, how characteristics of components changed as they evolved (from the uncharted to the industrialised) and methods of manipulating the landscape (from open source to patents to constraints).

We used the map to determine where we could attack and from this formulated the why (as in why here over there). Hence we moved into the cloud in 2005 building the first public platform as a service.  I used the same technique to help Canonical successfully attack and dominate the cloud space in 2008 against massive (and vastly better funded) foes.

I subsequently learned that by sharing the maps I could not only improve situational awareness but also help remove bias, silos, misalignment and inefficiency in organisations and also provide a clarity of purpose throughout the organisation. Every team knows the maps (there's often a master and many sub maps for specific areas). They know where their part fits in. 

When it came to organisation then I used a Pioneer - Settler - Town Planner structure. This is a derivative from Robert Cringley's Accidental Empires, 1993. By derivative, I mean I nicked it or shall we say repurposed a description of companies to running a single company.

The first step is to break the map into small components managed by small teams. Today, we describe this through cell based teams with each team less than twelve people (the Amazon two pizza rule) or use other concepts such as microservices, composability etc. The team should have autonomy over how it organises and runs itself but should have certain conditions (i.e. a fitness function) that it is measured against. Oh, you can guess ... this was nicked from the 1970s and the use of workgroups.

The problem however is that whilst each team will require certain aptitudes (e.g. engineering, finance, market), those skills change in attitude as the components that team manages evolve. For example, engineering in the uncharted space is agile but in the industrialised space it is more six sigma (see figure 2). Oh, and that diagram is a derivative from Solomon and Storey's innovation paradox of 2002.

Figure 2 - Changing Characteristics and Methods with Evolution.

Back in '04/'05, we had Agile and Six Sigma and were struggling with the missing middle and methods associated with it. We saw the same problem with purchasing, with finance, with operations, with marketing. We also noticed that some people were more adept at one end of the spectrum than the other.

We also knew that new things appeared in the market and were bolted onto organisations, just like Chief Digital Officers are being bolted on today. We also knew that the new stuff is tomorrow's legacy. So, we decided to mimic the outside process of evolution internally within the organisation. We created a structure based on pioneers, settlers and town planners and let people self select which group they were in. We started with IT and rolled the rest of the business into it. We also introduced a mechanism of theft to replicate the process of evolution in the outside world. See figure 3.

Figure 3 - Pioneer, Settler and Town Planner

The advantage of this method is we recognised that there isn't such as thing as IT or finance or marketing but instead multiples of. There are multiple ways of doing IT and each have their strengths, their culture and a different type of person.  In 2005, we knew that one culture didn't work and enabling people to gain mastery in one of these three domains seemed to make people happier, more focused. Try it yourself, take a pioneer software engineer used to a world of experimentation and agile development and send them on a three week ITIL course. See how happy they come back. Try the same with a town planner and send them on a three week course of hack days & experimentation with completely uncertain areas and lots of failure. 

What we realised back then is we needed brilliant people in all three areas. We needed three cultures and three groups and each one has to excel at what it does.

Pioneers are brilliant people. They are able to explore never before discovered concepts, the uncharted land. They show you wonder but they fail a lot. Half the time the thing doesn't work properly. You wouldn't trust what they build. They create 'crazy' ideas. Their type of innovation is what we call core research. They make future success possible. Most of the time we look at them and go "what?", "I don't understand?" and "is that magic?". In the past, we often burnt them at the stake. They built the first ever electric source (the Parthian Battery, 400AD) and the first ever digital computer (Z3, 1943).

Settlers are brilliant people. They can turn the half baked thing into something useful for a larger audience. They build trust. They build understanding. They learn and refine the concept. They make the possible future actually happen. They turn the prototype into a product, make it manufacturable, listen to customers and turn it profitable. Their innovation is what we tend to think of as applied research and differentiation. They built the first ever computer products (e.g. IBM 650 and onwards), the first generators (Hippolyte Pixii, Siemens Generators).

Town Planners are brilliant people. They are able to take something and industrialise it taking advantage of economies of scale. They build the platforms of the future and this requires immense skill. You trust what they build. They find ways to make things faster, better, smaller, more efficient, more economic and good enough. They build the services that pioneers build upon. Their type of innovation is industrial research. They take something that exists and turn it into a commodity or a utility (e.g. with Electricity, then Edison, Tesla and Westinghouse). They are the industrial giants we depend upon.

I know Lou Adler talks about how there are only four different types of jobs in the world - thinkers, producers, builders and improvers - well, I've found you can get away with three. Pioneers are more thinkers / builders. Settlers are more builders / improvers. Town planners are more improvers / producers.  Of course, every group needs to think and communicate (which is what maps help with) but this approach seems to work fine. Also, whilst everyone tends to have a bit of everything they also tend to dominate in one attitude over another. So encourage that specialist attitude, let them develop into master pioneers or master town planners. Lastly, it may well turn out that a four party or even more spectrum like approach is needed. I've never pushed it beyond three distinct groups, so I don't know. I do however know that breaking into two groups tends to end up with internal warfare and them vs us whereas three distinct groups seems to resolve that conflict.

Combining with a map and a cell based approach then what you end up with is figure 4.

Figure 4 - PST in a cell based organisation.

It's important to note :-

1) The maps are essential to this process. They also give purpose to each team. You know what you're doing, where you fit in.

2) The cell based structure is an essential element of the structure and the maps should be used to create this. Those cells need to have autonomy in their space, they must be self organising. The interfaces between the teams are used to help define the fitness functions. Co-ordination between teams can be achieved through Kanban. If a cell sees something they can take tactical advantage of in their space (remember they have an overview of the entire business through the map) then they should. 

3) The cells are populated with not only with the right aptitude but attitude (pioneers, settlers and town planners). This enables people to develop mastery in their area and allows them to focus on what they're good at. Let people self select their type and change at will until they find something they're comfortable with. Reward them for being really good at that.

4) The process of theft is essential to mimic outside evolution. All the components are evolving due to supply and demand competition which means new teams need to form and steal the work of earlier teams i.e. the settlers steal from the pioneers and the outside ecosystems and productise the work. This forces the pioneers to move on. Equally the town planners steal from the settlers and industrialise it, forcing the settlers to move on.

5) The maps should also show the strategic play. Don't hide this, share it as well as target of opportunities.

6) As new things appear in the outside world they should flow through this system. This structure doesn't require bolt-ons which you need to replace later. No chief digital, chief telephony, chief electricity, chief cloud officer required.

7) As the cells grow they should subdivide into smaller teams (keep it less than 12 to a cell). The map can help them subdivide the space, each with new fitness functions. As you get larger, you'll need to structure the communication between cells more using a hierarchy. Yes, that means you need a hierarchy on top of a cell based structure.

8) The map MUST start from user needs at the top. It has to be mapped over evolution (you can't use time, diffusion or hype cycles to do this - none of that works).

9) The executive structure becomes a CEO, a Chief Pioneer, a Chief Settler and a Chief Town Planner (think of Cringley's original commandos, infantry and police) though you'll probably use more traditional sounding names such as Chief Operating Officer, Chief Scientist etc. We did. I'm not sure why we did - can't remember the reason for this. We also called the groups when we started in IT - developers, frameworks and systems. These days I wouldn't bother, I'd just make it clear and move. You will need separate support structures to reinforce the culture and provide training to each group. 

10) Any line of business, described by a map, will have multiple cells and therefore any line of business is likely to contain a mix of pioneers, settlers and town planners all operating to a common purpose. See figure 4.

Now, PST is a structure I've used to remarkable effect in a very small number of cases. That's code for 'it might just be a fluke'. However, in the last decade I've seen nothing which comes close and instead I've seen endless matrix / dual and other systems create problems. Is it suitable everywhere? No idea. Will something better come along ... of course it will. However, to invoke Conway's law then if you don't mimic evolution in your communication mechanisms (e.g. through a mechanism of theft) then you'll never going to cope with evolution outside the organisation.

So how common is a PST structure? Outside certain circles it's non-existent, never been heard of. At best I see companies dabbling with cell based structures - which to be honest are pretty damn good anyway and probably where you should go. Telling companies they need three types of culture, three types of attitude, a system of theft, a map of their environment, high levels of situational awareness is usually enough to get managers to run away. It doesn't fit into a nice 2 x 2. 

It also doesn't matter for most organisations because you only need high levels of situational awareness and adaptive structures if you're competing against organisations who have the same. Will it become relevant over time ... maybe ... but by then we will have found the next 'best thing'.

A debt of thanks
A bit of digging in the old memory banks, brings me to Robert X. Cringely's book, Accidental Empires reissued in 1996, page 235 - 238. Copying some quotes from that book (which I recommend people go buy and read), the ideas of pioneers, settlers and town planners are all there but used to describe companies rather than how a single company operates. I knew it had come from somewhere.

Think of the growth of a company as a military operation, which isn't a stretch, given that both enterprises involve strategy, tactics, supply line, communication, alliances and manpower.

Whether invading countries or markets, the first wave of troops to see battle are the commandos. Commando's parachute behind enemy lines or quietly crawl ashore at night. Speed is what commandos live for. They work hard, fast, and cheap, though often with a low level of professionalism, which is okay, too, because professionalism is expensive. Their job is to do lots of damage with surprise and teamwork, establishing a beachhead before the enemy is even aware they exist. They make creativity a destructive art.

[Referring to software business] But what they build, while it may look like a product and work like a product, usually isn't a product because it still has bugs and major failings that are beneath the notice of commando types. Or maybe it works fine but can't be produced profitably without extensive redesign. Commandos are useless for this type of work. They get bored.

It's easy to dismiss the commandos. After all, most of business and warfare is conventional. But without commandos you'd never get on the beach at all. Grouping offshore as the commandos do their work is the second wave of soldiers, the infantry. These are the people who hit the beach en masse an slog out the early victory, building the start given by the commandos. The second wave troops take the prototype, test it, refine it, make it manufacturable, write the manuals, market it, and ideally produce a profit.  Because there are so many more of these soldiers and their duties are so varied, they require and infrastructure of rules and procedures for getting things done - all the stuff that commandos hate. For just this reason, soldiers of the second wave, while they can work with the first wave, generally don't trust them, though the commands don't even notice this fact, since by this time they are bored and already looking for the door. While the commandos make success possible, it's the infantry that makes success happen.

What happens then is that the commandos and the infantry advance into new territories, performing their same jobs again. There is still a need for a military presence in the territory. These third wave troops hate change. They aren't troops at all but police. They want to fuel growth not by planning more invasions and landing on more beaches but by adding people and building economies and empires of scale.

Robert X. Cringely, Accidental Empires, 1996 (the reissued, I don't own the original).

What Robert called Commandos, Infantry and Police is what I later called Pioneers, Settlers and Town Planners. The two are identical except Robert was there much, much earlier. In fact 1993, a good ten years before I implemented the "trimodal" structure and 21 years before Gartner and others came up with the bimodal / dual operating system / two speed IT concept

I owe Robert Cringely a debt of thanks. Also, I'm not a fan of dual operating system as I take the view that continual and sustainable competitive advantage comes from managing the middle not the extremes.

[1st October 2015]

Added the descriptions of Pioneers, Settlers and Town Planners and why every group needs to be awesome / brilliant.

Added a link and comments on Lou Adler's four roles.