Pioneers, Settlers and Town Planners

How to organise product teams

Back in the dark ages, technology teams were grouped in terms of aptitude (DBAs, Sysadmins, Developers, testers etc). Code was thrown over walls and somehow shipped to the customer.

Over time, it was established that the best way to organise teams is to set them up to be self sufficient. This meant a people with different aptitudes form a team and ideally own the end to end delivery of a product.

Yin and Yang

Simon Wardley of the Wardley Maps fame also settled into this conventional wisdom but found that there was a lot of conflict between his teams. He hypothesized that the conflict was caused because there were fundamentally two types of work - new development and core operations. A similar theory is behind Gartner’s Bimodal IT assertion which asserts that there are two streams of work — one focused on predictability, the other on exploration.

This setup is extremely popular with the rise of platform teams supporting product teams. It was even formalised in an AWS service (AWS Proton) announced at ReInvent 2020.

What Simon found was by grouping his multi-aptitude teams into two groups, somehow it increased the amount of infighting but more importantly the evolution of services/components was not happening.

Evolutionary flow of a Service

One of the central thesis around Wardley maps is

Standardization of components enables creations of better complexity.

This means services evolve from Genesis -> Custom Built -> Product -> Commodity. The services that you choose to evolve basically defines your strategy.

Anyways, so back to the story. Simon Wardley found that in his bimodal world, the evolution of services wasn’t happening. Instead, the operations people kept complaining how lassez-faire the new development people were and the new development kept complaining how much the operations people had a stick up their a**.

Pioneers, Settlers and Town Planners

The hero of the new development people is the ‘Pioneer’. The Pioneer is great at breaking through the organisational ennui and bringing change about. He does get bored quite easily and cant be trusted to write proper documentation.

The hero of the operations people is the ‘Town Planner’. The town planner obsesses about operational health and minimising risk.

You need both of them in your organisation but if you stick them together, they fight. This is something I have seen from personal experience and it benefits neither of them.

The missing ingredient to make them work are the ‘Settlers’. The settlers get along with both pioneers and town planners. They are the Salieri to the Pioneer’s Mozart. They recognise the brilliance of what the pioneers build and make it functional. They give their creation enough structure that Town Planners can take services from them and commoditise them.

The trio also setup a nice cycle for the evolutionary flow of the services. Settlers take services from pioneers and make success happen. Town Planners steal from Settlers and commoditise services. Upon these commoditised services pioneers build their newest innovation. A healthy food chain for the enterprise.

So, Simon realised that the best way to organise team was to make teams of people which had the same attitude (pioneer/settlers/town planners) and different aptitudes (PO/dev/designer). This both kept the peace and allowed for the evolutionary flow of services.

I will be honest, I haven’t seen this in practice anywhere, but I have seen all of these personas. The most successful team I could think of which was a combination of the three but with immense respect between each of them which probably made it work.

What I have instead seen is this happening more organically, because pioneers get bored and moved on. Pioneers usually have a settler than hangs around them who then takes over. Occasionally some of these services are commoditised, though being a town planner is truly an art form. Many town planners often end up designing ghost towns. On the other hand the pioneer’s lassez faire attitude and the zombie systems they left in their wake rubs enough people the wrong way for them to become a political hot potato. Being a settler is a tough balancing act.

I hope that this writeup makes more managers realise the need for all three attitudes and to manage the evolutionary flow of a service. You can do worse than following Simon Wardley on twitter or read through Wardley Maps.

For what its worth very similar ideas first expressed by Robert X Cringely in Accidental Empires, first published in 1993 about the type of personalities that drive innovation in Silicon Valley. The equivalent personality types were Commandos, Infantry and Police.

Also, you should probably follow me on twitter.