Exploring Pioneers, Settlers and Town Planners
It’s all about Attitude and Aptitude
Several months ago, I came across the writing of swardley, and read about value chain mapping with great interest. As I read through Simon’s thoughts (which are now being turned into a book — Chapter 1 starts here), the discussion about doctrine, and in particular aptitude and attitude was a particular interest. He talks about the importance of ensuring different small teams in an endeavour having the correct aptitude and attitude, and introduced the terminology of Pioneers, Settlers and Town Planners. He is of the view that there is a need for those different types, according to the level of evolution the work they are involved in.
The idea of different attitudes and aptitudes resonated with some of the challenges we were experiencing in our work on NHS.UK; trying to keep a high volume live service running whilst working on transforming for the future. In simple terms, it could viewed that we had some pioneers and some town planners, but a big gulf where the settlers ought to be.
The great thing about the model is that:
- Pioneers are BRILLIANT!
- Settlers are BRILLIANT!
- Town Planners are BRILLIANT!
As I read more about this model, I wanted to find out who had implemented this model in their organisations. This turned out to be harder than expected. With the aim of giving anyone on this journey of discovery, this post will simply summarise my findings to date.
On evolving products
Neil Perkin provides a great summary of the model and in particular how its application may differ in small and large organisations. He concludes by using some thoughts from a podcast:
“Eric Ries makes a good point about how in most companies the problem is not a lack of ideas, but the lack of a process to test out those ideas and to take them out of the lab and commercialise them. Too often early stage concepts emerge from a lab situation into a business-as-usual environment and are immediately shackled with expectation, targets, forecasts, departmental silos, strangling the idea before it’s had chance to find its place”
Mapping PST to Leadership and Management?
Another post from Neil Perkin, who does a brilliant job of drawing together emerging thinking from a number of different sources. In this post he highlights the importance of attitude and aptitude — adding that when recruiting, direct experience is often overrated and a demonstrable ability to learn from experiences are underrated. He goes on to refer to three types of business leader:
“Tim was kind enough to point me (in a comment on my post on insourcing/outsourcing), at David Smith’s post about achieving effective change through the right person in the right place at the right time. It’s interesting, says David, that the business world has more recently prized leadership over managers and entrepreneurs when of-course all three are critical to the effective running of a business. Yet they are very different beasts:
The Entrepreneur dreams about the future, is strong on ideas, and brilliant at vision
The Leader plans for tomorrow, is strong on people and brilliant at behaviour
The Manager delivers today, is strong on process, and brilliant at capability”
Applying PST to Networking Teams
Lindsay Hill writes about attempting to apply the Wardley PST model to networking teams, with an acknowledgement that it doesn’t map directly to the broader PST model.
I found this structure useful, in that it breaks each area down into:
- Deal with
- Worried about (as opposed to Happy With)
- Technlogies (rather than uses)
Source: https://lkhill.com/networking-pioneers-settlers-and-town-planners/ [LINDSAY HILL]
The Danger of Single Modes of Operation
Andy Budd observes the temptation to apply a single mode of operation over all else, which can leads to clashes in the realm of digital design, where there is a chance of a clash with the dominant tempo and get rejected.
You can even apply PST to Drinking?
Ministry of Justice and PST
Really tantalising article from Dan Searle, which ends by referring to some future article which I can’t find.
“Many of the products we are building from the ground up can and should be used across government by other departments.
With so many departments now building digital services we need to make sure that we’re not reinventing the wheel every time. Not doing everything ourselves was a key message on day 1 of the tour.
The way we deliver services is maturing with each day, and next week we will be reviewing how we build and looking at what components we should:
- create (as ‘pioneers’)
- reuse (as ‘settlers’)
- industrialise (as ‘town planners’)”
GCHQ’s Operating Model
GCHQ have published a paper called ‘Boiling Frogs’. This has lots of general, useful information, but nothing specific about how the models were applied and the learning arising from that, but worth a read all the same.
Source: https://github.com/tomski/BoilingFrogs/blob/improved-visual-design/GCHQ_Boiling_Frogs.pdf (this is a version of the original doc by Tom Loosemore, with an improved visual appearance — see his blog article).
Experiences from America
One of the few people who appeared to have implemented PST in practice is Chad Thomas, I came across him as a result of him replying to a tweet from Simon Wardley. Chad responded to say he’d implemented Pioneers, Settlers and Town Planners (PST), so we arranged to talk. Here is the summary of the conversation.
Chad is director of Tech for a consultancy company. He sees implementation of PST according to three paces of IT delivery:
- Systems of Record — snails pace so Town Planners
- Interfaces/middleware — medium so Settlers
- Mobile app — Continuous delivery so Pioneers
Chad found that when consulting, clients are often unwilling to implement PST, because companies feel they don’t want the Pioneering — they want to lop that off as can’t see it adding as much value as other phases. Chad’s approach in that scenario was to implemented a metric, measuring the cost of delay — which described the cost of the delays on work, in order to justify the work that pioneers do in getting stuff done fast.
Chad has used PST three times:
- Grouped people in teams of P, S or T. Some people natural fit in different modes, so happy to peel off. Also found that lots of people wanted to be pioneers, then wanted to stick. When used with the consulting model, it helped with the peeling as could drop people off the contract and bring different people on.
- Work for a financial institution. Mainly mainframe folk — very much in T mode. Not enough pioneers.
- All legacy no process. Client didn’t like PST names or phases, so did a 4 pillar model — an additional type of person between settler and town planer. Called them Pioneers, Settlers, Urban Planner and Town Planer. Client didn’t like those names, so they’ve gone with colours. Have experimented with people moving teams every 6 months.
On reflection, Chad prefers to use the PST language explicitly. In one company, he worked with HR and the design team to come up with posters about what the modes are. Also articulated a path to move between them.
Dependencies — have implemented project firewalls to prevent the Ps being slowed down by too many T dependencies.
So my understanding is that Chad sees the model as being applicable for three speeds of IT delivery, not necessarily as the product itself evolves, which is not how I’d interpreted it.
A colleague and his daughter made this excellent video about applying PST:
PST for Digital Product Development
And finally, my thoughts captured in a slide deck, exploring how PST might be applied to evolving digital products.