Salaries project

In April 2012 TouK decided to do an unusual project. We decided to make the salaries in the company transparent. Yes, transparent. Probably there are countries where salaries are not taboo but definitely Poland is not one of those (similar to quite a few countries I visited when I talked about this concept at various conferences)…

Money What Money

When I participated in Stoos Connect 2013 (check out the review here) one of the concepts that I saved to ReadItLater was Agile Management Innovations. This is an initiative describing several (26 at the moment of writing this post) practices inspired by the Agile values and helping build an environment suitable for agile methodologies. These are innovations in a sense that they aim at “substantially altering the way in which the work of management is carried out…” (a quote by Gary Hamel).

One of AMIs is Open Salary Structure. It turned out that this was exactly the thing we implemented one year earlier.

The salaries project

The problem

Question markBefore I’ll get to the solution let me describe the problem we were trying to solve. At the beginning of 2012 there were around 50 developers working at TouK (+ 10 nondevelopers). As in any company from time to time one of the employees was coming to us and asking for a raise. When one of Toukers came in early 2012 we (the board of TouK) noticed there are three issues making it a hard problem to tackle…

  1. Several people were having very similar salaries, although not the same (like 1% difference). We tried to recall why these salaries were different but we couldn’t and we were unable to come up with any justification…
  2. People making the decision (the board) were not working with the person being evaluated (in many cases)… This made the evaluation difficult and sometimes awkward (eg. when we had to base our evaluation on feedback that the evaluated person didn’t agree with).
  3. Finally, a person asking for a raise, especially when the raise is rejected, expected some guidelines what he needs to do to get the raise. Addressing this need (by people not working with him on a daily basis) is very hard.

Of course these issues are not new and there are some standard ways of addressing them. Of course you can do a 360 evaluation. Of course you should help your people with self-development. But the whole idea of management innovations is to look for non-standard solutions that could do better. That’s why we considered opening the salary structure…


Basically we wanted to achieve and maintain three simple things: simplicity, effortlessness, fairness.

  1. Simplicity – the system should be easy to understand to everyone (starting with its creators :D). The basic system we all are used to (the boss decides on a salary) is kind of simple – everyone understands that the boss is responsible – but on the other hand, not really that simple – when we get to the justification of the decision (especially negative decision) it starts to get complicated.
  2. Effortlessness – the less effort will be necessary to make a decision the better. Let’s assume that every employee wants to get a raise once a year and that making a standard 360 evaluation uses 1 manday (5 meetings * 3 people each * 30 mins each – a rough estimation). Now let’s count that times 50 devs and you get a substantial amount of effort that by the way doesn’t create any value (thus in terms of Lean Thinking is a waste).
  3. Fairness – last but not least – TouK has always believed that salaries must be fair – more skilled people earn better money. I often say that in case the salary list leaked the amount of discontent should be minimal (I don’t believe that the perfect fairness is achievable but definitely that was the goal).

Discrete salary levels

Let’s start with the part of the system that simplifies the salary structure and can be implemented even without making the structure transparent.

Personally I hate the idea of pay bands (ie. the idea that on a given position your salary is between X and Y). I believe that systems with pay bands are always abused (I’ve seen it abused many times while I haven’t seen it used appropriately even once) – they are never used to reward people who are slightly better, they are always rewarding better negotiators (and often, unfairly I believe, men are better off than women). One could argue that negotiation skills are also valuable and a better negotiator should have a better salary, but I think that this belief is exaggerated. Of course there are positions where negotiation skills are very important, but then they should be rewarded explicitly. Finally, I know of companies where at a given position (say junior programmer) the pay band is A-B, and at a higher position (say senior programmer) the pay band is C-D, and B is greater than C. That means (at least theoretically) there are senior programmers earning less than some junior programmers. This is madness!

stairsNow, imagine a salary system where all programmers earn X, all senior programmers earn Y and all MegaUberGuruNinjas earn Z. No negotiations, no bragging about your skill whatsoever. Simple? The only question to ask is “Is my/your/his skill level similar to programmers, senior programmers or MegaUberGuruNinjas?”.

After some discussions we decided TouK needs seven levels of salaries. As we believe that job titles lead to dysfunctions we used letter codes. And as we didn’t know if the seven levels were enough we left room for adding more later (we didn’t have to do it so far). This way we ended with level B, level D, level F and so on. Soon, the levels were renamed pots (similar to pots used in the draw for groups for FIFA World Cup, etc). All the levels were assigned a specific salary (no ranges) except for the first and the last level, which were left open for individual negotiations (not more than X and not less than Y, respectively).

One important thing to mention is that we assigned the salaries to the levels in such a way, that getting a promotion by one level means something – you get a significant raise. By significant I mean something like 20-40%. Independently of being promoted, the salaries can be increased by several percent depending on the economy, company situation or due to fine tuning of the system, this way affecting everybody. Fair? Fair.

Open Salary Structure

I love spreadsheetsHaving decided on the salary levels we went on to the main part of our project, ie. opening the salary structure. As you can imagine, there is not much to explain… Open Salary Structure just means that the information about levels is available to anyone. It’s pretty similar to companies with official job titles. This is a typical practice in many organizations and I guess it doesn’t surprise anyone. In our case it was is like that (amounts are fake):

Level Amount Devs
Level B 1000
Dev 1
Dev 2
Level D 2000
Dev 3
Level F 4000
Dev 4
Dev 5
Dev 6

The introduction of this transparency and how it was going to be received was something we were afraid of, thus we paid a lot of attention to this process. I am going to describe the implementation itself in a separate post later. For now I will just say that any employee could opt out – that happened for several (less than 10%) people. For everybody else the whole structure is accessible via the internal wiki.

One can also look at this from a different perspective. At the end of the day we didn’t actually make the salaries transparent. We just implemented a standard salary policy with public job titles and pay bands. And we used meaningless codenames for job titles. And we made pay bands very, very narrow :).

Dynamics of OSS

By dynamics I mean how do people use the information to move around this structure or simply: “How do I get a raise”. And how the decision makers are using the matrix to help them, well, make decisions.

Brno AirshowFirst, imagine you are Dev 3 from the above example. At some moment you feel you deserve a raise. You open the specific wiki page and see the data. Having worked on the last project with Dev 1 and Dev 5 you agree that since Dev 1 is a new hire you are better and you should earn more. At the same time Dev 5 seems better, she was a lead on the project responsible for the architecture. This way you come to a conclusion that you are in the right spot in the salary structure. Furthermore, you now wonder: “what do I do to get a raise?”. And immediately you realize that Dev 5, beside the architecture was also doing all DB schema operations. A skill you don’t have yet, so why not focus on learning that.

Now, imagine you are responsible for setting the salary. This time, Dev 2 comes to you and asks for a raise. You can go to Dev 6 and get some feedback on Dev 2. He now says that he’s been coaching Dev 1 & 2 recently and (1) they both made some good progress since being hired and (2) maybe they both belong to Level D. You cross check this with others and feel they both deserve a raise. This way Dev 2 triggered a raise for Dev 1, good for her. I am sure some will say this drives the costs up. That’s true. But along you also get a fair system and soaring morale. Also, maybe Dev 1 was feeling treated unfair but was too afraid to ask for raise. Or was waiting to be given some credit. And maybe, just maybe, while waiting she was looking for another job with better pay. And now you saved yourself lots of cash and time on replacing a good employee. So the cost argument is not that obvious to me.

Finally, and maybe even most importantly, imagine you are Dev 5, as I mentioned earlier you have just finished a project with Dev 1 & 3. And you see that Dev 3 made some brilliant decisions during the project, and also he started getting involved in the communities, gave a talk on a conference, etc. Why not nominate him to be promoted to the next level? Of course, as always, this opinion is cross checked and verified. But there seems to be no reason to wait. Clearly, Dev 3, in the first story here, underestimated his skills, but still deserves a raise.

Of course I have simplified those situations but I hope you get the idea of how the system works. All these situations, and many more, did actually happen during last two years.

Outcomes and results

Let me start with the goals… Is the system fair? I believe it’s as fair as you can get. Of course some people are not content, but I believe it’s due to the fact that many of us tend to overestimate our own skills and value. Is is simple? The system boils down to a few simple questions: Are you the best of all on the same level?, Are you as good as those on a higher level?, What someone on a higher level can do that I cannot (or maybe I ask him/her)? Is it effortless? Yes and no. Some of the effort is distributed and is done by the team. I believe it’s a step in a good direction.

Most of employees liked the system but I must also admit, that not everyone. Some ignored it, some accepted without enthusiasm, some opted out. I will try to gather some opinions later on and blog about it.

Some people stopped asking for a raise. I believe they see they are on an adequate level and are not improving. I am not saying it’s good or bad – that’s a decision everyone should be allowed to make for themselves. Some people are promoted rapidly (like 3 levels in 6 months). I like to think that it became a self-balancing system – when someone inside detects some flaw (unbalanced salary) often they mention it.

I am really proud of it (although I am far from claiming I am the only author of this solution).


problemsAfter adopting this salary model we found out that not everything was as simple as we would have liked. Here are a few issues we faced.

When determining the initial salary levels we found out that several people had higher salaries than we would agree for at that moment. This has nothing to do with the new system itself, it can happen anywhere (and I guess – it happens in many places). Why it can happen is an interesting topic itself, but I will not digress here. When salaries are secret you have one easy option – you can ignore the problem. When you open the salary structure this option seems less attractive, as others will find out and some will consider it unfair. In this situation you can:

  1. fire the man – the last option to be considered…
  2. lower the salary to a fair level – a very bad option impacting the morale of the person and probably having the same effect as the option above
  3. hide the fact from the public – a very bad option, you are opening the structure to provide transparency

No good options available… What to do? Every case is different but I would recommend some mixture of 2 and 3 as well as lots of coaching.

Another issue we faced were difficulties in comparing skill between people with different technology background. In TouK most of the devs are either application developers or DBAs. App devs can be divided to web app devs and middleware devs (although this division is much less pronounced). I hope you can imagine that comparing an experienced JavaScript developer to experienced Oracle developer can be nontrivial. To make things worse, salaries of people with different technology skills can vary (eg. senior .NET devs can earn more/less than senior Java devs – I mean in general, not only at your company). Similarly to the previous issue, this is not a property of the system I described here, but having such system implemented you are delegating this difficulty to everybody. That’s something to have in mind.

Part of the previous problem is the fact that we can try to compare ourselves to people we work with on a daily basis. But we work with only a few people on a daily basis. Think about a reasonably small team consisting of a frontend dev, two application devs and a DBA. Now, these guys will have something to say about each other after some time, but will struggle to decide who should earn more (in many cases) as their skillsets differ. At the same time they will struggle with comparing to others, who they haven’t been working with recently. We addressed this problem with high rotation between teams (I heard many times that this is something one should never do intentionally (move people around) but TouK does so to its benefit, accepting problems it brings along – another topic worth a blog post on its own).

Finally, I had a conversation some time ago pointing that nondevelopers (that were excluded from this system) would also like some kind of structured salary policy. In case you have larger nondev groups you could adapt this system, but in a company where HR, office, accounting, administration, etc is 5-8 people combined this model is an overkill. In such case you will have to address these people’s need of some kind of structure for career development in some other way.

Ah, one more thing to consider here. This is clearly a one way road – when you make salaries public it will take a lot of effort (and time) to make them closed again. I don’t say it cannot be done, but definitely it would be difficult.

The cost

There are two parts of the total cost of the implementation of such system.

First, there is the direct cost in cash. In TouK the introduction of the discrete salary levels increased monthly salary budget by around 2%. You can decide for yourself if it’s worth it or not. I have not regretted it. Good thing is that you can easily estimate this cost and then decide – this system can be easily modeled in a spreadsheet.

Secondly, there is an indirect cost of changing the organization culture. Or maybe even not changing, just stating really loud what the culture is, what is rewarded, where employees are (in the salary structure). And the introduction of a system I described is a loud statement. Some will not like it and will look for an opportunity to leave your company. Is it good or bad? Hard to tell. You get a better aligned team but you have to accept some risks coming with people leaving your organization.

Was it worth to do something like that? If you ask me – yes, it was worth it. Now, decide for yourself…

My theories 🙂

At some moment I came to a conclusion that deciding how much people should earn in a company is somewhat similar to doing an initial project estimation. Thinking about a typical software system to be implemented – often you start with some decomposition of the system’s functionality and then you try to estimate size or effort for each function. In Agile methods a typical practice you use is planning poker. One thing about planning poker is important here – you don’t estimate using all possible numbers (either meaning time or points) but you restrict yourself and use only some of them (typically people use Fibonacci numbers, ie. 1, 2, 3, 5, 8, 13, 21, …).

When I was thinking about the process of deciding on salaries I thought I have my backlog (people in a company) and I have to assign a number to every person. Why not use the same thinking that underlies using Fibonacci numbers? Use only some values so that the differences between the levels are large and make the values nonnegotiable.

Another reasoning behind agile estimation practices is focusing on comparing instead of assigning arbitrary numbers. It’s a lot easier to answer a question “Is A larger than B?” or “Should C earn more than D?” than “How big is A?” or “How much C should earn?”. As human beings, we are way better in comparing stuff.

Further writing

There are several things that I would like to elaborate more:

  1. How to implement Open Salary Structure, especially pitfalls and things to watch for.
  2. How this system was received by the staff and what are the opinions after two years.
  3. How to hire having such system operating.
  4. How different models of salaries fit into complexity landscape using my favorite Cynefin framework.

This post is already long, thus I hope to post on these topics soon. If you read it all and didn’t bore to death and would like to hear more don’t hesitate to subscribe to updates on this blog and follow me on Twitter.

Also, if something is unclear, you think this system is great or quite the opposite, you think it sucks, let me know in the comment section below.

Money…What Money
Question mark in Esbjerg
Alexander Henning Drachmann
Kim MyoungSung
I love spreadsheets
Craig Chew-Moulding
Brno Air Show september 2008
Adam Pniak
mike krzeszak

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s