Getting to SoftwareMill's open salary system

The story

This is part 2 of a 3-part blog post series about the salary system at SoftwareMill. You can find the previous part at Flat salaries — How did it work and why did it stop working?, where I described how after a few years of almost equal salaries in the company, we decided to differentiate them and we recognized 4 key aspects that we need to take into consideration when building a new, better salary system.

• Market Attractiveness – while we are aware that we won't be able to compete with top salaries from banks and huge tech firms (for now, at least!), we need to be able to provide sensible rates that are slightly above the market average. We, as an organization, can provide a lot more than just a fair compensation in money, but that part must be fairly taken care of,
• Fairness – the salaries must be fair, that is something we all agree as an axiom, but we need to be able to figure out what that fairness is,
• Formalized growth route – by having automatic raises every year, we lose the ability to be able to guide people in their development – which is a lose-lose situation for all of us: the organization and the staff themselves,
• High-impact – being a fully transparent organization where everyone’s voice matters – we have never specifically recognized high-impacting, out-of-professional responsibilities, activities. Since that culture has developed us so significantly and made us a unique organization, we decided it is about time to recognize this in the salary system as well.

And why have we done this? We decided to design the new system not only to be competitive in the challenging software job market but first of all, we wanted to create a framework that supports individuals in our team in building a collective technical mindset. We want SoftwareMill to be a place where everyone can fulfill their professional goals and have a significant effect on their career, as well as the company.

What we do not want is SoftwareMill to be a stale organization that is reinforcing limits instead of continuous personal development. We saw that the flat salaries system stopped working as we are growing bigger and becoming more diverse, it lacked the versatility needed for everyone to feel there is a good career development support system in place.

For this, we needed to make a salary system that clearly shows the possible rates at SoftwareMill as well as the candid rules to get them.

Learm more about SoftwareMill:

The Research

We started with forming four analytical teams (4-5 people each) that were assigned to take every aspect of the mentioned above: market attractiveness, fairness, formalized growth route, high impact and conduct market research to see how other companies are dealing with these challenges.

Market Attractiveness

The first group got the task to check how different software companies on the market differentiate rates according to the roles of the teammates and geography.

We had a hunch that frontend positions might have slightly lower rates than backend, which should have lower rates than DevOps. It turned out, quite surprisingly, that all these roles have pretty much the same rates. We had a feeling that because there are so many more frontend developers on the market, their remuneration might be smaller, but in the end, it turned out that it is true for junior developers, but mid/senior, trained engineers are so scarce that their rates are not only high but very similar to those in backend positions.

Another factor we analyzed was geography. While it is true that living in Warsaw is a lot more expensive than living in Elbląg, should that be a reason for people living in bigger cities to have higher rates? We wanted to find out what the market norm was. The market, as you might easily guess, is very US-centric, and when companies do use geography-based rates, it’s often San-Fran vs. rest of the world, while it does not matter if someone works from expensive Warsaw, or cheap middle of nowhere. If it’s Poland, it’s all the same. It turns out that those systems are not meant to provide “fair” compensation for those living in bigger cities, but are rather an excuse to pay less to those who are not from Silicon Valley. Hence we decided to skip it in our future salary formula.

Yet another factor we checked was the non-technical role rates. In the previous systems, those rates were bound with the senior developer role at some rate. The market has changed though, IT salaries were one of the fastest-growing in Poland and for example, the Accountant salary that we set on 60% of the backend rate suddenly went down to 45% according to the newest reports. We decided to disconnect these rates and benchmark more on the salary reports rather than percentages.

Conclusions:

• Similar rates for different engineers are OK (update from late 2021 - we might reconsider rates for Machine Learning engineers).
• Geography does not matter in our case (Poland).
• Rates of non-tech personnel should be disconnected from engineering rates.

Learn more about SoftwareMill:

Fairness

The next group was analyzing fairness - the question was: What are the main factors that are accepted on the market to differentiate rates in companies?

We analyzed several companies from different parts of the world - Travis, GitLab, ScrumTrek, Multunus, Buffer, Cogent, Fog Creek, Balsamiq, Keepler, LunarLogic, Niteo, Codurance, and a big unicorn from Eastern Europe. All but the last one have their salary systems described online, so you can freely check for yourself. There is a very useful Open Salaries list, maintained by Eduard Sizovs if you want to learn more.

We gathered all the information we could get from the above companies and prepared a list where we counted how many are using the given factor.

You might be wondering why we’ve put the average rates of a role together with geography - well it’s tightly bound - if you live in an expensive place (like California), rates are going to be much higher.

Conclusions:

• We do not care about geography (see the previous section), but we need to take into consideration average rates on the market (for us - in Poland).
• Individual skills are very important, so is knowledge sharing (and since it is in our company DNA, it makes it even more important).
• Different rates for different roles are OK.

Formalized growth route

Another group’s task was to find out how other companies are building the position ladder and what the rules of climbing on it are. How can it be as merit-based as possible? What is the whole process?

The materials and companies we looked into were: Buffer, Fog Creek, Martin Andrews, Jurgen Apello (Management 3.0), El passion, Touk, Facebook, We Wei Research Institute, Netguru, Noteworthy , Meetup, Rent the Runway, Zappos, u2i, Liip, Virtus, scientific materials and HR materials and reports.

Companies are usually building level-based systems. The number of levels is usually proportional to the organization’s size. It usually starts from 3 (Junior / Regular / Senior) and is, in theory, indefinite - Fog Creek, for example, has levels 8 (intern) to 15 (for significant contributions to Computer Science in general).

Sometimes levels can have sublevels, where the seniority (as in time spent at the company) counts - this is usually for people to get smaller, yet regular raises between advancing to higher levels, which takes more and more time, the higher the level is.

The good question is how people are ranked when they join the companies and then want to advance. There are 3 options (and several mixes between them):

• The direct supervisor of one person is the one to rank and then move the person up,
• The team together with the employee are deciding on their advancement and ranking,
• There are badge-based systems where the employee gathers badges that allow them to advance.

Conclusions:

• The more strict and formalized growth route, the easier it is to market, but we risk shaping everyone to be the same.
• Raises should be frequent, even at the cost of size.
• The system should be evaluated every 6-12 months.
• We need to provide a system that always has room for promotion, otherwise, we’ll suffer from a glass ceiling.

You might also be interested in:

High impact

The last group task was to figure out how others are rewarding high-impacting roles at the company. SoftwareMill being a teal organization has to promote, but also recognize, individual engagement in shaping the organization. Until now, most of those activities were performed in the “meantime”, but as the company grows, it just takes more time and we need to make it easier for people to change things around.

The first thing we learned is that it is common to count some activities as “extras” for people on the lower levels, while those same activities might be expected from those on the higher, leading and strategic, levels.

Some companies use business-impacting activities for bonuses to salaries, while others make it mandatory for advancing to higher levels.

There is an interesting concept described by Jurgen Appelo in Management 3.0, copied in a few companies we have discovered, that people get some kind of points/kudos from others. Those points translate to money when bonuses are given, but in order to make it feel like an “extra”, not part of the salary whether you are given the bonus or not is randomized (using all sorts of ways, but as a simple dice roll in the most basic scenario).

There was also a very interesting case from Zappos where badges were given for all sorts of extra activities.

But let’s return to the diagram I showed you in the previous article:

Our team thinks that “Skills useful for SoftwareMill” and “Extra duties at SoftwareMill” should be a significant part of the remuneration, so this should be included in the new salary system.

Conclusions:

• We are transparent and we want people to feel appreciated for their extra input - especially that we are unique on the market in how we value contribution.
• We’d rather have this to be part of the culture, not a bonus system, so high-impacting activities should be indirectly connected with the money.

More about SoftwareMill:

Summary

Let’s look one more time at all those conclusions together:

Market Attractiveness

• Similar rates for different engineers are OK (update from late 2021 - we might reconsider rates for Machine Learning engineers).
• Geography does not matter in our case.
• Rates of non-tech personnel should be disconnected from engineering rates.

Fairness

• We do not care about geography (see the previous section), but we need to take into consideration average rates on the market (for us - in Poland).
• Individual skills are very important, so is knowledge sharing (and since it is in our company DNA, it makes it even more important).
• Different rates for different roles are OK.

Formalized growth route

• The more strict and formalized growth route, the easier it is to market, but we risk shaping everyone to be the same.
• Raises should be frequent, even at the cost of size.
• The system should be evaluated every 6-12 months.
• We need to provide a system that always has room for promotion, otherwise, we’ll suffer from a glass ceiling.

High-impact

• We are transparent and we want people to feel appreciated for their extra input - especially that we are unique on the market in how we value contribution.
• We’d rather have this to be part of the culture, not a bonus system, so high-impacting activities should be indirectly connected with the money.

After weeks of analyzing many very interesting salary systems at different companies and learning a lot about remunerations (all the above conclusions plus lots more that wouldn’t fit in this article), we needed to come up with a solution that suits us.

But who are we? SoftwareMill is a company that values engagement at all possible levels. We do not only expect people to write good code and transform clients’ business with technology, but we encourage everyone to shape company processes and new business lines in a way they think will be the best. We also value knowledge transfer, self-development in various directions, and we believe that people generally make the best decisions about themselves.

The route we took is not very common - we decided to mix a level-based system with a badge-based one.

Levels, bound with rates, should represent personas of specialists that would be easy to understand what is expected from such a person. Think about different ways of independence - there are different levels of expectations from a Regular Developer (they should be able to provide a reasonably small solution on their own) than from Principals (they should be able to lead a team to provide an end-to-end solution for a client).

What we knew was we never wanted a list of carved-in-stone requirements for becoming for example a Senior Developer from a Regular one. Instead, we decided to introduce Badges, which we divided into 3 categories:

• Technical, representing all role-based “hard” skills,
• People & Development, representing “soft” skills,
• Organizational, representing influence on SoftwareMill.

The idea is that there should be a requirement for several badges between all levels to get promoted. Those requirements should differ, obviously, for different levels. We will expect, for example, more organizational badges from our top staff.

Then, it comes to rates. We decided that each level should have its rate (flat for all people on the same level) plus we need to introduce smaller raises between the actual promotions (because they can take time, especially on the higher levels).

Last, but not least, we decided to start with the system for our technical staff. When it comes to non-technical, they will have the freedom to either use this system or propose their own, if that makes more sense.

Now… How we did it in detail and how it has worked for us for the past few months will be a topic of Part 3. Stay tuned ;)