Most companies work in a similar way when it comes to determine starting salaries and pay increases. When a job offer is made, a starting salary is agreed and at some point in the year salaries are reviewed and adjusted. The rules are usually determined by managers and/or Human Resources departments. This is stuff that is usually not included when we talk about ‘self-managing’ teams.
One company that we visited in South America, as part of our Agile Around the World study, were experimenting with moving away from this traditional way of managing people’s salaries. The company has been using Agile for the last few years and continuously seeks new and innovative practices.
Until recently it was always management who decided which people gets what pay rise. These reviews would happen bi-annually. However, they reasoned, if we really are an organisation with self-managing teams, who is better to decide salary awards than the teams themselves? As a team member, who knows better what you deserve to be paid other than your peers who you work with day-to-day? A few months ago, the company in question began an experiment with this idea with one of its most mature teams consisting of 4 software engineers. The team were given complete empowerment over their pay rises. Note that inflation in the country in question runs at about 10%, so salary increases that keep pace with this are going to be significant.
We met the team and had a chat to see how they were getting on…
The first thing they did was to set out 3 phases that they wanted to go through:
Step 1: Create transparency. Everyone in the team had to get full transparency of each other’s salary and packages.
Step 2: Create equality. The team agreed that equality in salary was essential as a base to start from as they were doing the same job.
Step 3: Devise a rewards system. Team members to agree a system on how to divide future pay rises in the team once equality in salary has been reached.
Step 1: make salary packages transparent
Once the salaries were made transparent, it was obvious that some people earned more than others for doing similar jobs. This had to be tackled in step 2. Everyone was still on the same page and agreed it was the right thing to do.
Step 2: Equality
All team members agreed that the priority was to ensure everyone earns the same. They all have the same role after all. So, the first pay rise was used to make all salaries equal. It was interesting that this appeared to cause no resentment, demonstrating perhaps as to how close they were as a team. It would be interesting to know if other teams around the world would be as harmonious.
This paved the way to step 3 – so they thought… The unexpected challenge they ran into was a change of personnel. One of the team members received a great opportunity elsewhere and so left the company (nothing to do with the experiment we were told). The team was now actively looking for a new team member. At this company, the teams get involved in the recruitment process. Considering finding a new team member who ticks all the required boxes can take up to 6 months, they were extremely lucky to find someone who was a perfect match. The new recruit had all the skills expected, except for one: the skill to negotiate a good salary that reflected his worth. His salary demand was way lower than the current team members were on, and hiring him on his requested salary would mean the team would need to go through another round of salary equality if they were to stay true to their previous beliefs. It was a subject for debate within the team and with management.
The team made a point to management: people should be offered what they are worth, it should be based on their competency and not on their salary negotiation skills. This raised interesting questions: What would this mean for future recruits? What basis should starting salary be made on? Would the team be made part of starting salary decisions for new recruits?
Step 3: agree a ‘system’ to divide future pay rises
The team had some difficult discussions to come up with a fair way of determining future awards, even seeking guidance from an Agile coach from outside of the company. Various ideas were put forward: ‘should we just divide the bi-annual pay rise equally among us?’, ‘Should we do performance reviews?’
One of the more debated suggestions was to measure the number of work items a team member successfully closes. They thought about that idea but dismissed it quickly for the following reasons:
– They like to experiment, learn new things and work out of their comfort zone. By measuring the number of work items a person closes, they were afraid that they would lose this innovative approach. They wondered; ‘would we be tempted to stick to what we know best to make sure we keep closing work items and therefore not learn anything new?’
– There are times that certain team members close less work items as they are helping others in the team and they felt that helping each other should be encouraged and not punished.
– How would it work when multiple team members are involved on a work item, for example if they are pair programming, who gets the reward then?
– Quality is key for the team. They asked themselves; ‘if we are “competing” to get work items done, would we compromise quality?’
It was interesting to hear how seriously the team took the experiment and how determined they were to come up with something that was fair and worked for them. They were stuck for quite a while, going in circles and getting frustrated. They almost thought it was an impossible task. But they came through with a solution that was agreed among all the team members.
The team has a big letter box on their desk. Each team member can put in a note when they believe another team member has contributed something that is valuable to the team. For example, someone found a new way of working which saves the team time, or someone went out of their way to help another team member.
For each note that someone gets, a point is awarded to them. No ‘negative’ notes are allowed – so no minus points. After each 2-week sprint, the team opens the box and counts the points. The higher the points, the bigger your share is of the pay rise.
We liked this idea, it was focussed on team work and had a positive angle. We loved that the team trusted each other to follow these rules. We did however question what ‘valuable for the team’ meant. What is valuable for one person can be regarded as unimportant to another. For example, one team member may reward another for bringing in doughnuts for the team, but others may feel that is not worth a point. They told us that they had exactly the same discussion, but they agreed to trust and respect each other’s opinions: if a team member feels another deserved a point for whatever reason, this is to be respected. And since this experiment is new, they recognise that they will need to keep on inspecting and adapting their system if needed.
It all sounded like a good starting point to us. We exchanged contact details and they promised to let us know how the experiment turns out.
And just as we were saying our goodbyes to the team, they threw in one last comment. ‘Of course, if by June one of us needs the pay rise more than another then we need to revisit the point system. For example if one of us needs money because they are expecting a baby, or their house catches fire.’
This team surely has challenges with the experiment to come, but this comment showed us how together they were as a team. Looking at how methodically and maturely they have approached the experiment so far, we believe they have every chance of making it a success. We look forward to hearing about how the experiment goes; just maybe their outcome can become a template for other teams and organisations. 😊
What do you think about this approach? Would you like to try it? Would it work in your team? What other systems could be used for teams to self-manage pay awards? Please share your thoughts below.
