Bonuses, part 1: Why

This is a two-part blog series in which I’ll try to explain the a few things about the bonuses at OSI. The first part focuses on the the “why” and “what”. The second part goes into more details of the “how”.

Employee bonuses are an increasingly common practice in the corporate world, and nowadays in IT they seem to be taken for granted. In some geographies and verticals up to 50% of the total annual compensation is paid as bonuses. Even with this level of ubiquity of the bonus mechanism a few people outside of the management teams routinely think what bonuses are and how they should be implemented and determined. At OSI we also distribute bonuses, and this is our view on why and how this is done.

There are two main components to any bonus: the desire of the organization to give such bonus, and the way in which such bonus is distributed among employees. Usually businesses and some non-profits give out bonuses based on their financial performance in some preceding time period. This is done to both show appreciation for the results of the company, and to better align the performance of the enterprise with that of its employees. Some factors that used in determining the distribution of the bonus are retention, morale, market pressures, individual’s outcomes, and a few others[1]. We at OSI think the biggest weight in the distribution should come the individual’s outcomes.

Let’s take a look at those two, the organizational outcomes and employee performance separately.

Organizational outcomes

You can think of organizational outcomes as the amount of money that the organization has earned extra and decided to distribute this year as bonuses.

In the most common case that would be how much money did the business made and was it profitable. In some more exotic cases that may how much money did the organization receive in grants, or even did it achieve some predefined KPIs set out by its management.

We at OSI think of this as the money pot that is left after we have paid all our expenses (salaries, rent, taxes, benefits, etc.) and we are usually sharing that number with our employees.

Employee performance

There are two aspects here that need to be considered: growth and extra effort.

Take a look at the work contributions and salary of Joe between two consecutive promotions of his:

Graph showing the salary and contributions of an employee and the area locked between those two, determining the bonus one should receive.

In the ideal case Joe’s performance is slightly above what his company pays him. In the same ideal case Joe’s performance grows steadily until he is ready for his next promotion.

A bonus is compensation for the growth that an employee has achieved above the expectations[2] of their current salary level. In other words, bonus is earned money, not gifted money.

The trouble with the ideal case is that only superstar performers achieve that kind of a smooth linear or even exponential growth, but for the rest of us there is a non-linear component to it and often there are direction reversals.

The extra effort is different from growth in that it did lead to better results. Those were temporary in nature and, as the name suggest, require extra time or something else that was not usually expected of the employee. Some companies may pay overtime for such efforts.

The difference between the growth and extra effort is best described with the ditch example. Imagine that my job is digging ditches and I am expected to dig a 10m ditch every day, and this is what I get paid for. Growth is when my ditches become neater, better organized, and in the meantime, I also help others’ ditches get better too. Extra effort is if I start digging longer ditches – 11m, 12m, or even 13m. Both intra-promotion growth and extra effort call for some extra compensation between the two promotions[3].

Since in most companies, the present one included, the salary changes are not as frequent as needed to capture ups and downs of everyone’s individual performance, let alone that adjustment-down of a salary is usually hard to do properly[4], there exists a need for a mechanism to absorb those changes – the bonus schema.

Defining the problem was the easy task. Now to the more challenging topic of how to actually determine where does the orange line of performance lie?


Traditionally it is up to managers to determine their reports’ performance and compensation distributing some portion of the total bonus pool set by their manager. If you have good managers, this is not a bad approach although it has a few drawbacks.

Adding to it that in a matrix organization, like a scrum team[5], the managers do not work directly with their reports, the problem becomes somewhat non-trivial. Also, as you may have noticed none of the agile frameworks, like Scrum or Kanban, mention a word about the whole people management aspect of the self-organized teams.

Considering that increased freedoms go hand in hand with increased responsibilities who better to assess the individual’s contributions than the people that work together with that individual?

We at OSI are big on teamwork. So, 3 years ago we decided to ask everyone to express their view into points that get turned into bonuses. We figured we’ll ask everyone in the organization to assess everyone else. In this way, we are being more transparent with each other, involving everyone in the decision process, reducing the bias that a single person would inevitably have, and ultimately making the process fairer.

In next post I’ll describe how we do that peer assesment at OSI.

[1] Let’s not forget the ugly side of bonuses – addictiveness of rewards of unknown size, and sometimes unknown frequency. We do try to mitigate that by giving bonuses only once a year and being methodical about it. More on that later.

[2] How expectations are determined is a whole other topic better left for another episode.

[3] Of course, the ditch analogy can only go so far – nobody digging ditches will be a salaried employee. They will be paid per unit of work, e.g. per meter of ditch dug. But we all know how paying per kLOCs ended up.

[4] And is also illegal in some geographies.

[5] If your manager works in your scrum team, there is not much of autonomy and self-organization, now is there?

This post was written by George Kremenliev