What is a Hierarchy?

To operate a peer-to-peer recognition program you must be able to provide a position feed which represents your hierarchy and employees. In simple terms this means that we need to know which employees work for which employee (i.e. line managers). If the data was mapped out in a diagram it would show every employee in a pyramid leading to the MD/CEO at the top.

There are 2 types of hierarchy:

1. Employee based hierarchy
2. Role based hierarchy

This document will describe each and discuss the Pro's and Con's along with some samples of data.

What is Employee based hierarchy?

This is the most basic hierarchy that can be used and should only be used when position ID’s (unique IDs for individual roles) are not available. In this model you could use the username, employee ID or any other unique ID that relates to the individual to identify them and their line manager.

Let's start by describing a hierarchy and building a sample data set. The following example shows a simple hierarchy with each employee using the EmployeeID from the HR system as the position ID:

This would give us the following position data:

It is extremely important that your data does not create orphans. Orphans are created when a position is empty and the employees that report to them are not updated to report to the correct line manager.

For example, from the previous example if the Sales Manager Paige Hammond left the company this would create an empty space and create a broken hierarchy as shown below:

This must be resolved by changing each of the employees that used to work for her (i.e. Evie Grant and Charles Jenkins) to point to her line manager (i.e. The Sales Director JH-01). The new hierarchy would be:

This would give us the following position data:

As you can see her role has been removed and the 2 employees now report directly to the Sales Director and the hole has been removed. You can now trace every employee through the hierarchy and up to the MD/CEO.

What is Role based hierarchy?

A role-based hierarchy is the best way to operate a peer-to-peer recognition program. It requires that your data shows each unique role within your organisation without regard to individual employees. Roles are allowed to exist without employees assigned but the hierarchy must always remain intact i.e. you must be able to trace any position up through line managers until eventually arriving at the MD/CEO.

We will take the same corporate structure as the previous example except here you will see we are using the roleID from the HR system as the position ID:

To avoid confusion there isn’t any employee information shown above, this is because this is a role-based hierarchy and therefore the employees are not relevant when discussing hierarchy.

This would give us the following position data:

Unlike the employee-based hierarchy when an employee leaves a role the position does not have to be removed nor does the line manager position have to be updated. This is because the role has not been removed rather the employee has just left and therefore the role has become vacant.

Budgets and Historical Data Restrictions

If you are running a program with financial rewards, you will assign budgets to managers, these are stored against the positionID. As we can see from the above examples there are very different responses when an employee leaves or change's role. In an employee-based hierarchy when an employee leaves, the position must be removed from the hierarchy whereas in a role-based hierarchy there is no change required. Also, when a new employee starts even though they were replacing an existing employee they will occupy a new position.

This creates 2 problems for employee-based hierarchies:

• Budgets cannot move with the position
• Data cannot move with the position

Any budget holders that leave and are replaced by a new employee will need the budget transferring manually. Also, the previous data (although available in Admin) is no longer connected to the previous role therefore the new manager does not see any history. This is a side effect of employee-based hierarchies as there is no way for us to know that employee A has replaced employee B. i.e A role may go vacant in January and only be replaced in June.

In contrast when running a role-based hierarchy there is no change to the position and hence we still know everything about it and how it sits within the hierarchy. This means that when a role is vacant the budget and all history relating to that role is maintained until a new employee is assigned to it. As soon as a new employee starts, they automatically inherit the budget and all the historic data.

The big advantage comes when managing budgets. Employees can come and go; budgets will still be available to the role without any admin required. Compare that to an employee-based hierarchy where budgets must be re-assigned manually.