March 27, 2018

The Squad Tree

Let’s look at Organic Deep Hierarchy again. This time we’ll try to reduce it to its essential core, disassemble it into parts needing separate justification, and then critique and reengineer as necessary.

Let’s look specifically at the “Squad Tree” idea:

One core idea of the Organic Deep Hierarchy model is the “Squad Tree”. That is, a hierarchical tree of “squad”-sized groups of men.

Every squad has a squad leader. The squad leader is in turn a member of some higher squad. Each squad member in turn may be squad leader of a lower squad. Loops in the hierarchy aren’t allowed. Pretty simple.

The model has a parameter, which is the upper-limit or characteristic size of squads. More precisely, the number of subordinates. We chose 5 as the number, because 6 can be evenly subdivided into two sub-squads of 3, which are themselves viable squads.

The size parameter doesn’t have to be strictly enforced; it’s not like the thing is going to break if someone has a squad of 12 in there somewhere. The point is just to hierarchicalize early and often so that you can always have a clear division of roles and chain of command when you need one, and guys are stepping up to leadership and learning the ropes quickly.

After all, you can always compose larger working groups of a squad and its immediate sub-squads. With saturated 5-subordinate squads, this gets you up to 5x5+5+1 = 31 members in the room, with some hierarchy to manage the inherent chaos of a meeting with 31 people. You wouldn’t want to get bigger than that.

Realistically, two-layer working groups would probably be about a dozen.

Back to where to set the size parameter, 5 is clearly reasonable, but the idea of a hard limit is not clearly reasonable. Is there never a situation in which you want 6? Or rather, do we get anything by making a rule instead of a suggestion?

Making it a suggestion to build sub-hierarchy just about as early as possible, using the holistic judgement of the men involved as to what they’re ready for, might be a better default.

As a test case, let’s consider a squad with 4 subordinates that gets eager about hierarchicalization. Maybe two of the members are more rookie, and one of the others is a decent leader. After a reorg, you have a top squad with two subordinates, one of the members of which himself has a squad of two subordinates. This is fine.

Any earlier and we start to get into squads that have only two members including the leader, which starts to break the model. We could put a hard lower limit of 2 subordinates, but again, why bother? Use judgement.

So, hierarchicalize early and often, with soft lower limit of 2 subordinates, and soft upper limit of 5 subordinates. You should probably have a specific argument for going above or below these.

That covers the model itself.

This is clearly inspired by the military, specifically platoon structure. The military is among the bearers of the most functional social technology today, though they have problems.

This is absolutely not the “flat” structure that is in vogue in modern startup companies. It is deliberately the total opposite of “flat”. Someone will have to explain to us what the point of “flat” is. We assume it’s just a fashionable way to repackage having only one guy who can manage at all, and he not having the skill to delegate. If we are to be charitable, it is probably something about fluidity and organicity of coordination structures. We will need to address those concerns in this model.

There are many other ways to structure things, even hierarchically. Why this model? To be honest, because it was what occured to us while trying to solve a specific problem, which you may hear more about soon. As we get experience with it, we will be better able to examine the alternatives and critique this model.

Edited and curated by Wolf Tivy

Comments? Email