Automating Variable Compensation: Getting the most out of your Position Design

In variable compensation it is very common to see reference to an entity called ‘position’.  A position is a capacity/role in which a payee functions and for which they receive compensation.  A position often has a name, (like ‘Director of Advanced Widget Sales Northeast’) and a title (like ‘Director’).  Positions often too have a life of their own, that, for example, the Director of Advanced Widget Sales Northeast exists independently of whether Sue or Tom is holding the role.  It may even be empty for a time, but like a physical chair, it does not disintegrate when the sitter stands up.  Object constancy, and all that. 

These position objects are often related to one another, for example that the position ‘Director of Advanced Widget Sales Northeast’ reports to the Vice President of Sales Northeast, or perhaps to the VP of US Widget Sales. This relationship usually looks like a hierarchy, but there are cases where it is more a filtered matrix of some sort, or really it can be as rich and nuanced as the imagination.  It is important to model both positions and their relations accurately to get correct compensation and good analytics.  

 

One dimension that is often lost in this exercise is the organization.  Most companies, in addition to the type of positions described above, have some type of organizational structure.  Perhaps they are organized by geography at some varying levels of depth (Geo, Area, Region, Market, District, Territory … etc) and also perhaps product or customer bands ripple through that characterization of the business.  Usually the relationships between positions are conditioned by this organizational structure.  For example, the reason that the D of AWS NE reports to whatsoever position has to do with the way that the organization has been defined.  In many ways it would be accurate to think that most larger companies have positions with various relations between them, organizational nodes with various relations between them, relations between positions and organizational nodes.  As far as the relations between positions and org nodes, they are usually of two major types: ‘is part of’ or ‘member of’, and ‘manages’. 

In the picture below we see orgs with their hierarchy, and positions with their own hierarchy, some red lines indicating that a position manages an organizational node, some green lines that indicate the membership of a position within an organization.  It gives some idea of what exists and what therefore is important to model.  It is exceedingly common in variable compensation implementation that the overt modeling of the org nodes and their relation to the positions – as a time-keyed relationship – is neglected. This failure is often not understood until quite late, when someone says that Pat is paid on the total sales of the EMEA for products in some list and it is realized that nowhere are the total sales for EMEA stored, except that they are correlated with the VP of Sales for EMEA, but she does not get paid on subscription renewals or maintenance agreements and that the old VP of Sales for EMEA left the company and the position was vacant for seven weeks and how do I get that number?

 

The main idea I’d like readers to take away is that, in order to provide the fullest sales compensation capability and in order to provide meaningful analytics, all of the elements in the picture should be modeled.  At first glance it may not look as if your tool can handle this, for example perhaps it only has a notion of position and no notion of organizational nodes. That’s probably OK.  In the picture below you can see all of the same relationships represented using just positions.  All that has been done is to consider org nodes as a type of position, a type of position in which no one sits, nominally, and which is managed by the position or positions holding a ‘manages’ relationship to that node (the red line, as previously)

 

The point of this discussion is not to suggest that one size fits all.  There are certain industries in which the notion of position has been slow to take hold.  They are of two sorts, mostly.  Those who believe that "There are no positions" (!)  Tom is Tom's job...  We pay Tom.  Also there are those who focus very specifically on the capacity of function, as in, “Under which contract?  With what special arrangements?”.  These latter frameworks don’t so much eschew positions but imagine them as a very naïve device.  The best general advice is to model what’s really happening, as best as possible, and try to take advantage of whatever optimized behaviors the position related functions in your comp tool are designed to deliver.

In sum then, for the predominant cases, considering organizational nodes as just another type of position is a best practice.  It's not that they really represent a role or a capacity of function, nor that anyone sits in them per se.  It is that by including them in the model we reap a lot of simplicity and truth not otherwise easily found.  Considering that one of the most important uses of these hierarchies is the rollup of credits, and considering that it is critical that methods and totals should be shared (we should not have multiple ways of deriving total sales of X, or total commission paid of some dimension), such a combined structure is a key enabler of fundamental integrity and coherent analytical insights.