In a LeSS course and a LeSS adoption, the question is asked how do we pay team members, Scrum Masters, and even managers. The reason why this question is raised is due to significant reduction of organizational complexity. The number of roles, layers, positions is much less to choose from or grow towards. This seems to create some kind of communist system :-). Nothing is further from the truth.

Let’s go through what is already known and described by others.

Esther Derby advises in her blog post () to:

• Don’t rate and rank individuals. Get rid of performance reviews and merit pay.
• Adjust salary based on the cost of living
• Do profit sharing with employees
• Adjust salaries based on the current market rate for skills and roles
• Increase salary / promote an individual who is “performing above others”
• Use existing short feedback loops (instead of an annual cycle) to know how to improve as individuals. ScrumMaster plays an important role here.

In the book “Scaling Lean and Agile development”, Bas and Craig give several general advices: “Avoid…Job titles”, “Try…Create only one job title”, “Try…Let people make their own titles; encourage funny titles” , “Try…(if all else fails) Generic title with levels”, “Try…Simple internal title map to special external titles”, “Avoid…Job descriptions”, “Try…Simple general job descriptions”, “Avoid…Career paths”, “Try…Job rotation”, “Try…Start people with job rotation”, etc. This overview of advices give a basis for the question on how to pay people.

In the book “Practices for Scaling Lean and Agile development”, Craig Larman and Bas Vodde advise completely in line with Esther’s advises:

• Avoid career paths that encourage people to see coding as just an early phase
• Connect salary directly to the skills of an individual
• Teams should define their own targets and measure themselves, not management.
• Management should measure product performance instead of each team or individual contribution.
• If, for some reason, an organization doesn’t want to remove performance appraisals, at least reduce the harm of such policies (page 408)

In addition to the above, I would add:

Sustainable over current performance

The following is based on teaching from Bas Vodde in his course, but he cannot remember stating something similar :-).

Although individual or a team performance is important, the more pressing question is whether we wish an individual to perform well now or continuously. If we wish continuous or sustainable performance then we should assess for sustainable performance. In other words, the ability of an individual to perform. Also, we should stop measuring current performance since it might have the opposite effect on a sustainable one.

What does this mean concretely?

Sustainable performance is a result of learning, an increase of one’s skills. In the context of Scrum and cross-functional teams, becoming multi-skilled is highly beneficial for the team and individual. This should be reflected in rewards.

Replace bonus with a one-time salary increase

Individual bonus essentially emphasizes temporary performance over a sustainable one. In reality, most HR departments have already figured out that emphasizing temporary performance and hence giving very different bonuses over the years is a bad idea. It becomes more a bonus in the name only. I have seen 2 forms of bonus systems:

1. If the bonus is a significant percentage of yearly salary, then it barely fluctuates over the years unless the company has some financial problems. Fluctuations would seriously kill motivation and invite gaming of the bonus system. Initially, the bonus becomes an easier way for management to do salary corrections.
2. If the bonus is a minor percentage of yearly salary, then it becomes a symbolic way to recognize the more sustainable growth and behavior of individuals.

So, we start to see the trend here that already materializes in an increasing number of companies. Even banks are ditching bonuses. All major Dutch banks have already removed individual bonuses for employees.

So, you would pay people more if they read more books?

What if someone is making sure that he is advancing his future career by learning and getting more skills at cost of current contribution? What if someone is learning stuff and in the meantime not delivering what he is supposed to deliver?

The assumption in this thinking is that there is a disconnect between becoming multi-skilled and actual delivery in this sprint. Hence the thinking that an organization must measure and reward current individual performance in addition to sustainable aspects (skills, experience).

That happens indeed. It happens in dysfunctional teams and organizations that have serious problems of disengagement. One should understand and solve the root cause. Low level of engagement due to the unhealthy environment cannot be remedied with financial incentives.

It could also be that an individual is simply not fit for the job, or doesn’t see the job as a chosen profession. The rest of the team (or manager if the team is unable) should fire the person in that case. Btw, hiring should be done by teams too.

In the end, an individual with increased skills and experience will contribute more and have a positive impact right now too.

Who and how determines skills level?

The following is my interpretation of a practice I learned from Craig Larman.

Introduce a scale: Developer level 1, level 2, level 3, level 4, level 5. The baseline (level 2) is the market average for let us say a C++ developer if the product is a C++ based product. Difference between levels should be significant enough since developers skills can differ significantly. Level 5 is someone who is a well-known name in the C++ worldwide community.

Who and how assesses this is a very easy question to answer. If the manager doesn’t already clearly sees who is which level compared to each other, then he already is not present enough and hence doesn’t understand what is going on. This should be an easy job for a manager, and he doesn’t require any special HR process or tool. A developer doesn’t grow from one to another level suddenly.

As mentioned before, the hiring process should preferably be done by teams instead of a manager. Also deciding level for a newly hired person should be quite easy for a team to do. But, since this is quite sensitive and obviously effects company cost, it should usually involve the manager.