I think this is a decent way to operate in a hierarchy–particularly when it comes to big decisions like hiring/firing/approving new policies. We first assume the hierarchy is a tree (i.e. each member has only one immediate supervisor) and that there is a maximal element, called an “administrator”. The setup is that if something happens at level in the hierarchy (say hiring/firing someone at level (presuming the action is consistent with other policy)), then the relevant supervisor makes the nomination/recommendation for the action, and his/her supervisor confirms the action.

Hence let be a tree, and denote the supervisor of Typically in trees, minimal elements are considered level Here we reverse the ordering and call the maximal element the **administrator**, denoted by and say We define a **rank** **policy** as a policy that affects all successors (subordinates) of an element such that Hence we have:

**The n+2 Operational Policy**. Let be a rank policy and denote the member whose subordinates are affected. The policy then becomes activated provided *proposes* it and *approves* it.

Hence the Operational Policy itself is a rank policy as it affects everything in the hierarchy. But we arrive at a problem in continuing to execute this policy at levels and So we adjoin another set to the hierarchy called the **board**, denoted and redefine our hierarchy as where denotes the initial tree with unique maximal element We then define and

The main positive of this method is the minimizing of micromanagement. The only big negative that stands out is the possibility of actions diverging from intentions of a level member as one goes down the ladder. But I’d argue that this just means more level policy needs to be implemented in order to prevent that.