'You built it, you own it!' vs P/S/TP

Recently, I have been asked to explain the conflict between Pioneers, Settlers and Town Planners concept and the ‘You built it, you won it!’ rule that comes from the DevOps environment.

While I do have a couple of ideas about why there is no conflict between those approach, I am very curious to see your thoughts first!

Best,
Chris

I was surprised when I read the question also.
In my view (but I have very limited experience with P/S/T ) there is no conflict also.
Pioneers will want to own everything anyway.
Settlers are habituated to work across teams to a certain extent so the “community” can leverage the knowledge of many different individuals.
Town planners share anyway the same mindset of “scale” and “standards” so they can have the devops work done well across harder boundaries (if the org structure has such).

It’s all about having groups of people which share the same approach to solving problems and clearly identifying the problems / mission in relation to the evolutionary stage nthat product / system is in.

Yes, exactly!

The ‘You built it, you own it!’ approach is to make people responsible for things they built and avoid situations where one team leaves in a world without consequences (as somebody else has to deal with a poorly created solution). That is also one silo less, less communication barriers, and overall, better experience for solution users.

P/S/TP (I :heart: that notation!) recognises the desperate need to rebuild things with a slightly different purpose and a completely different attitude in mind. It recognises that when market characteristics are about the change, the group of current owners may not be the best to adapt - sometimes because they do not have right skills, risk appetite, or are just to focus on what worked so far, without understanding how expectations has changed.

In such situation, it may be worth to form a new team better suited for the new set of requirements. The new team builds a new solution and owns it (until the next transition).

However, to avoid conflicts (and this is most difficult thing), you have to have mechanisms that will reduce the stress of having a solution taken away. Pioneers and Settlers will probably look for a new job unless they understand that their role is to build and drive a solution up to a certain level of maturity, and that they are expected to do it again and again.

The borderline between P/S/TP can be sometimes troublesome, namely, what we call in the manufacturing industry change over. There are specific lean tools but all obey to the 4 golden rules: takt, sequence, lay-out and flow (systems). In addition to that, the user stories and viable products at each step of the process should be coherent regardless if we are talking about code, things or a service item. Hope this helps.