Thread by @swardley

X : How big should a team be?
Me : Well, based upon experience and using a map then in the "pioneer" area about 2-4 people. In the "settler" space about 6-15 people. In the "town planner" space .... hmmm, I want to say 30-50 people is fine but this is not the day for that.

.. the point is, you should keep your teams relatively small. Certainly far less than the Dunbar number. The Amazon rule of two pizza i.e. less than 12 people is probably a good measure overall but Haier has a bit more of a nuanced approach. I'd learn from them.

X : What is wrong with today?
Me : Gosh. I've been trying to avoid the whole Feral Hogs thing. Thanks for that.

X : So "town planning" teams should be larger?
Me : Ideally you should be outsourcing those "town planning" activities. But if you can't because there is no provider, then you have to act as the provider and ideally a public provider yourself. A single, larger team is ok ...

... on the "pioneer" side, you want to focus on much smaller teams and preferably many of them i.e. it's fine to have 5-6 teams of 3-4 people trying to solve the same problem ...

... by the time it evolves to a more "settler" stage then you're looking at 1 or 2 products to fulfil the need, eventually one. If you're going to build this in-house then think small teams of 6-15 people and yes, I see you no reason why you can't have two teams competing ...

... a bit of duplication can be beneficial but it has to be with intent. The vast majority of duplication I see in organisations (and the scale is huge) has no intent behind it or at best, post-event justification of why we have 300 teams building content management systems etc.

Of course, the best way to do the "pioneer" thing is to get everyone else to do it for you. Hence create an underlying component that people will use in building, expose an API, encourage an ecosystem to develop using it and most importantly ... monitor meta data (consumption).

As with all things however, these are not hard and fast rules but guidelines. Try to understand the context of what you're doing first as no-one actually has the answer. Everyone is still exploring organisational structures. Look to the military however i.e. more experience.

X : Any rules of thumb?
Me : Gosh. Yes, keep it small. Break into components. If you really need a rule ... then I would start with no more than 20 people in an area i.e. 5 teams of 4 (pioneering space), 2 teams of 10 (settler space), 1 team of 20 (town planning space).

X : You'd have multiple teams doing the same work in the pioneering space?
Me : Ideally, I'd aim to get a wider ecosystem to do that for me. If I can't then I'd certainly experiment with several very small teams on the assumption that most would fail but we could learn lessons.

X : Isn't duplication inefficient?
Me : Duplication without intent is. The whole point of the pioneer-settler-town planner structure is to replicate evolution (caused by competition) within an organisation. Unless you have a crystal ball, you have to experiment in pioneer space.

X : That seems wasteful.
Me : What's your solution?
X : Build the right thing with the right people.
Me : Easy words. First, recognise you need different attitudes (i.e. there is no "right for all contexts" person). Second, recognise the uncharted pioneering space is uncharted.