Openness and rates

In the quest for openness in the company, there is one area that is conspicuously not open: hourly rates. This is something that is set when one first joins OpenCraft, and isn’t discussed again except for unusual circumstances. Raises are open and consistent across the board (which is awesome), but the rates themselves are absolutely private.

Interested to hear your thoughts on whether more transparency in this area would be useful, in the interests of fairness to everyone.

Here is GitLab’s policy on this, since we often compare our model with them: https://about.gitlab.com/handbook/total-rewards/compensation/

Note: I know this is a sensitive topic, but I am curious about the decisions here, and do believe that more transparency is a good thing. Many software devs I know here in Australia have had bad experiences linked to no-one discussing their rates, and now are really pushing for openly discussing rates and reasons for them. I’m not suggesting there is a problem here at OpenCraft, but in general it seems a good thing to move in this direction.

3 Likes

My feeling on this is that I don’t feel that rates should necessarily be publicly broadcast, but I see no reason why individual members shouldn’t be able to reveal their rates if they want to.

There are traditional ‘taboos’ involved with discussing conversation, some of which are just the desire for privacy and others which have likely come from less savory places, but there are some practical reasons as well.

There are a few things to consider here:

  1. We all are human. Compensation can be difficult to decouple from feelings of worth. Seeing another worker who has a higher rate than you when you feel you do comparable work can cause friction. This isn’t necessarily bad, as if your understanding of your abilities is correct then you know what you may actually be worth to the company.
  2. Your rate is a single number combining a host of factors that may not apply to other members of the cell. Cost of living is the biggest one I can think of-- one GitLab’s page talking about using ‘local rates’ is how they handle it, looks like.
  3. This is the biggest one. Information is best when it can be acted upon. Let me elaborate…

The way we handle pay increases isn’t by individuals going to Xavier and asking for a raise. It’s done by looking over the numbers at the end of the year and then bumping the team by a percentage amount. This is actually very nice for a number of reasons-- it’s a way to ensure that everyone benefits from the company’s improvements without having to do individual negotiations for each person, but if our response to this information is to go renegotiate our rates, then we’re changing the deal. We probably won’t be able to use the ‘everyone gets a percent-based raise’ method anymore, because each person will be doing their negotiations individually.

That might be good for some of us who can negotiate well. It could be bad for those who aren’t. It might also mean some feeling of competitiveness will rise up among us, since at that point we are all sharp enough to realize that if we aren’t the developer who gets the marginal increase, someone else will be. I can be a very competitive person when I’m incentivized to be, and I like that I don’t have a reason to compete against my coworkers right now. Since any individual can be an epic owner in a given day, it could wildly change the dynamic if we were in competition.

If we aren’t willing to transition to individual negotiation or some sort of collective bargaining, then if we have this information, we’d just have to live with what it reveals.

What I think it would reveal is less ‘what is someone worth to OpenCraft’ and more ‘what was the intersection of this member’s negotiating ability and OpenCraft’s willingness to part with cash when they joined?’ @antoviaque asked me my rate. He didn’t tell me what OpenCraft was willing to pay. In fact, the first time I joined OpenCraft, I was asked to reconsider the rate I gave because Xavier thought it was too low! He absolutely could have gotten away with letting me pick that lower number.

So for an organization that has one point person making those decision, I could scarcely think of someone who is more mindful than Xavier about how the compensation structure works and making sure each person is treated fairly. BDFL is an appropriate title here ;)

The question does bring to mind one thing which I always felt was interesting about OpenCraft, which was that I feel like it runs more like a model cooperative at times than a normal private firm, since it’s so flat and every member takes part in its governance and management-- and the profits are even made to ripple out in the form of calculated across-the-board raises. However unlike other cooperatives, workers don’t have ownership in the company itself and these raises aren’t dividends. I don’t have any inherent issue with this, of course, I just always thought it was kind of neat, since I’ve not seen it anywhere else.

Anyway, those are my (probably more than) two cents. :)

5 Likes

I have been wondering for years when this topic would come up :) I actually hesitated a few times to bring it up myself, as it is definitely part of being transparent, and I wouldn’t be against it on principle – on the contrary.

What held me up from bringing it up myself is very much what you have very well explained @fox - it runs the risk of introducing a lot of politics, by creating a perceived hierarchy between people just because of salary differences, along with the associated envy and dismay it can create. We are a nice bunch of people, but we are human, and it would be really hard to avoid that.

I’ll be curious what we think about this as a group though – it’s something I think about regularly, and I haven’t come up with a definitive answer.

One additional contributing problem to consider alongside it though is the fact that there is currently no way to have a truly equal and fair approach to set everyone’s salary – all approaches will make some people feel undervalued if we start comparing them.

Gitlab and others try to solve the equality issue by having a salary calculator, based on location, taking into account the fact that there are disparities in salary and cost of living across the world. But imho it’s hardly fair – if two people produce the same thing, it shouldn’t matter which country they live in, and there are plenty of costs that are the same for everyone (computers, online services, travel, etc.). So having the same “standard of living” will actually depend as much on the person’s preferences as the location, and it just perpetuates world inequalities to say that someone in India can’t be paid more than someone in the US.

On the other side, setting a unique salary for everyone brings the issue of which salary standard to choose – if we align on the highest end like Silicon Valley-type salaries, we just instantly become non-competitive, and lose most of our clients, or our sustainability. If we align with the average world salary, we end up with half of the team feeling underpaid, or simply won’t have anyone in the team from parts of the world. And it also still leaves us with differentiating depending on experience, which brings its own set of politics, as well as ending up having to compare apples to oranges.

The way we approach this isn’t perfect either, but the idea is for OpenCraft to stay out of taking the decision of setting a value for each member, as much as possible. This is the way all hourly rates have been set:

  • New team members decide on their hourly rate themselves when applying
  • OpenCraft has a range of hourly rates that we can accommodate - we filter out candidates that we can’t afford, but we don’t negotiate the hourly rate at all, we simply hire candidates with the rate they set.
  • There is also a lower end of the range, ie a minimum hourly rate. Someone asking for a rate that is too low gets raised to the minimum hourly rate upon confirmation as a core team member
  • Then raises are applied to the whole team without distinction or negotiation every year, and made very significant whenever possible (often x2-3 what would be applied in other companies), to make sure there is a better progression than almost anywhere else, for everyone.

Imho this process has been critical at avoiding the usual politics and issues that come with salary decisions, and I wouldn’t want to move away from it, independently from the question of transparency.

5 Likes

Thanks for your response @antoviaque :slight_smile:

I agree that it’s a difficult topic, and my intention is certainly not to cause any politics around this. I appreciate your response, and hearing that it’s had a lot of consideration brings confidence.

Maybe there isn’t a perfect solution to this.

Same here. :+1:

Oh this is nice to know. :+1:

Very good topic to raise @swalladge, and I really appreciate @Fox’s and @antoviaque’s responses here.
Since we haven’t been transparent about this, all I knew was my personal experience with the hiring process, and I didn’t know what policies @antoviaque had in place.

This would be worth putting into our handbook, and sharing with newcomers in some form prior to their contract rate negotiation. Transparency around the process is more important than the numbers themselves, I think, especially if everyone understands that we request the rate they want to receive.

This was the biggest red flag for me when reading everyone’s responses. I love the culture here, and I love our flat and flexible structure. I personally am ok with sharing my hourly rate, but I would hate to sully our interactions by bringing money into the room.

OpenCraft’s raises truly are spectacular – and a great incentive for long-term retention. I love that they’re across the board, and I don’t want to change how we do this.

That said, if there’s anyone on the team who is feeling like they low-balled themselves, or whose circumstances have changed, then maybe this is a good opportunity to discuss a personal rate change?

1 Like

I’ve had discussions with @antoviaque about this especially since the way rates are handled here was very different from how it works in other organisations, especially the ones I know of and have worked in. I’ll leave it to him if he wants to share that.

My perspective on this is that I judge my rate by local standards, so I am not very concerned if others have different rates based on their local standards. It seems fair to me. I am not going to dissect how well the difference in rates correspond to differences in local standards because that is an impossible bar to reach. I don’t really care if others from India are paid more than I am since I’m happy with my compensation.

That said, I very much agree with @Fox myself, and I, personally, would lean towards it not being worth making this information open in case it hurts the dynamic here I like so much.

1 Like

Kshitij nicely summarized my views on this topic :slight_smile:

(Please provide tasks to log time when participating in forum threads, except if off-topic). @antoviaque should there be a task to discuss this topic? (openness of rates)


I’m working on the Billing v2 epic (SE-4009), it’s the program that runs at https://billing.opencraft.com/admin/, gets JIRA worklogs and generates our invoices in PDF. In the feature wishlist I see that some people are expected to have access to it (Gabriel, Xavier, Tim, Daniel), this includes access to invoices and rates and bank account data. I’m a bit surprised by that, since:

  • I don’t really need access to the servers or to that information
  • we’re ok with keeping that information private as mentioned in this thread. (I agree too)

Shouldn’t we have a stage billing server instead, and limit production access to those dealing with invoices and money (Xavier, Gabriel)?.
Everyone else (including me, and Tim) can use test data and test invoices.

We can run the server in local (docker image), but we may still need a stage server to do shared testing or to set up integrations (TransferWise etc.), though not yet.

It also means that Xavier would have to deploy the code to production after it has been tested on stage, and help to debug issues that happen only in production.

What do you prefer?

Agreed, this would be great in the handbook. Same for information about what members can do to negotiate if circumstances change.

I remember when I joined, the takeaway I got from the handbook was “rates are final, no later negotiation”, which didn’t really sit well with me. Of course that not exactly the case, because Xavier is very understanding, but it puts a lot of stress on getting that initial rate correct in the application form. (I’m sure some have not bothered applying because they think the rate will be the competitive field and they didn’t want to enter a low rate, or entered a low rate to be competitive and regretted it later. Many people also have a range they’ll be happy with, but this model has no opportunity to discuss before applying with that fixed number.)

1 Like

Same here, this seems the most logical approach. The hard part is actually finding the local standards. :grimacing:

That is indeed hard. Personally, to me even raw money values don’t really matter. Even in my own country there are different regions that have different cost of living. Even within my own city/state we have different living costs depending on where you live. Additionally, different people have different requirements for what would make a comfortable living for them. My needs are met, I’m comfortable, so I don’t care as much how much others make. There will always be people who earn more than you while doing lesser work, and there will be those who work a lot harder and make a lot lesser. I know both kinds :stuck_out_tongue:

1 Like

I appreciate @fox and @antoviaque’s responses here. :slight_smile:

Before this post, all I had was my personal experience with the hiring process too (same as @jill), so it’s good to have some extra clarity.

When I applied, it was my first ever remote job, and I didn’t knew what to expect or what rates to put, and so I ended up falling in the lower range rule.
When I was confirmed as a core team member the raise came as an unexpected (but awesome) surprise - I initially though it to be a bug in the billing system and immediately emailed @antoviaque.

I’m pretty happy with my compensation and each year that passes leaves me more and more surprised, the raises are unbeliavable and the work is super rewarding! :rocket:

:+1:
Same here, my compensation allows me to live a happy life and that’s what matters to me :slight_smile:

:+1:

3 Likes

Thank you for all the thoughtful comments on this! I was not sure at all how this discussion would go, as compensation can be such a sensitive topic – as noted, for the better or the worse, it is often so closely linked to the feeling of self-worth, that it’s easy for a discussion about compensation to go sour pretty quickly. I’m really proud to see how we are able to approach even this kind of topic with wise reasoned discussion – kudos to all of us for that. :slight_smile:

Btw, would it be fine to make this thread public?

That sounds like a great approach, I agree with this. It actually matches well the compensation mechanism itself. Its goal is to replace the piecemeal and often arbitrary assignation of worth by a manager/company (which is what causes the individual rate to be the critical information, as it allows understanding how people are judged and compensated) by a process that is systematic and open. In this process, OpenCraft stays clear of assigning a specific hourly rate and can be fully transparent about the process itself and its decision mechanisms – without touching or publishing the individual rates, which can be considered as private information set by each team member for themselves when they join, within the constraints of the public process.

I have created a task to prepare a pull request in the handbook, to describe the process, as well as incorporate elements and reasonings discussed in the current thread: https://tasks.opencraft.com/browse/MNG-2083

That is indeed one of the weaknesses of this approach. I’m not sure if there is a perfect solution to address that, as allowing team members to change their rate after they have joined would open the door to other issues. Like, what would be considered as having lowballed oneself, or what would justify a change of circumstances. Either:

  • OpenCraft / a manager would have to start evaluating those reasons and reintroduce the individual assignment of individual worth (which would be contained in answering “yes” or “no” to “has X low-balled themselves?”)
  • Or there would be no individual counterbalance, ie anyone could always decide to reevaluate their own rate freely, and then inevitably someone would just end up bumping themselves to a high rate in a way that wouldn’t be the intended goal here, triggering either other people to do the same in a classic tragedy of the commons scenario, or resulting in other types of disparities, effectively penalizing people who wouldn’t take that approach.

Here too, I think it’s best to have a systematic approach which, even if it isn’t perfect, tries its best to minimize adverse effects, ie:

  • Try to describe clearly to new candidates how we take into account rates, ie that it’s not a race to the bottom, but actually part of a process to keep things as fair as possible. We already have a description in the handbook, where I’ll reinforce this point, and describing that process in the handbook is another great step to help with this.
  • Have a decent minimum hourly rate – this is one of the reasons for this to exist, to make sure that everyone in the team has an hourly rate that allows living a comfortable life, and that nobody can lowball themselves to the point of not being able to have a happy life because of their low hourly rate. The strong yearly increases should also help with this, by making sure that even someone starting with the minimum hourly rate and never trying to renegotiate it, but who sticks around, comes to exceed the average international hourly rate after only a few years.

Don’t hesitate to talk freely about our discussions - I’ve always tried to consider the fact that these discussions might eventually become more public one day, and many of the constraints I laid out then were to ensure it could be considered as fair by everyone, even under the light of transparency.

Basically, @kshitij helped me to realize that a minimum hourly rate was necessary. @kshitij’s rate was too low, and I wanted to find a way to solve that issue for him, in a way that wouldn’t endanger the core principles of the systematic process, for the reasons discussed in the current thread – if I went to agree and say “yes, let’s make an exception for @kshitij because he shouldn’t earn so little and deserves to be paid more”, then I would have started assigning specific values to specific people, and it would be hard to say no to anyone else coming with a request for a raise later on, even if it were a very different situation. I would end up being the one making the calls, and we would revert to the usual approach for compensation.

So instead, I established the minimum hourly rate, as a way to handle this not just for @kshitij, but for everyone who would be in his specific situation, while keeping the existing principles in place. Of course, this is also quite imperfect, as it still opens an angle – I still had to set an amount for the minimum salary, and some might still want to raise it further, to also get a raise this way… But given that it would need to apply to everyone, it at least ensures that it is done on an equal basis (ie, that not only those who are vocal about something get the advantages), and this in turns creates a pressure for me to keep the minimum rate reasonable too, to keep OpenCraft sustainable – ie, a balanced compromise. Hopefully, that was the right call!

I answered on SE-4009 in the meantime, but I’ll copy my answer here too for reference: I differentiate between having technical access to that server & data, and actually going to look up people’s rates. Just like a sysadmin handling emails isn’t supposed to go and read people’s emails, or like we aren’t supposed to access personal data on any of the client servers that we manage.

I think it’s fine that some people have access to the billing server, as long as there is an understanding that it should be limited to access required for debugging. I don’t really have much time for handling technical issues anymore - that’s part of why FAL-313 is currently in progress, taking responsibility for debugging the billing server would be going backwards there. And if we can all be trusted to handle the clients’ and users’ personal information, hopefully this is also fine?

7 Likes

Fine with me :) :+1:

Me too! I like where the discussion has gotten to as well – transparency about the approach, but not the actual numbers. As perfect a balance as can be.

Yes, to both points. In our offer letter, I think it’s worth linking directly to the area of the handbook that discusses this, so when people are asking themselves, “how do I choose my rate?” they know specifically where to look.

I’ve never worked anywhere so genuinely passionate about being fair and sustainable. It’s truly wonderful.

Thank you, everyone!

5 Likes

I’m good with that. :slight_smile:

I immediately thought about doing that while reading the topic. Sounds good to me.

I like the idea of a minimum hourly rate. :+1:
And even if this rate may not be suitable for someone living in Silicon Valley, for example, everybody is still free to search for another company or to move to a more reasonable region of his country or world.
I understand it like this: “With this minimum hourly rate, everybody should be able to to accept or to have to opportunity to move to another place.”.

Yes! Please let’s put it in our handbook. Knowing that we have this transparency mindset and a minimum hourly rate would have made me way more confident and be less stressed while applying.

It doesn’t really matter but the first time I got a little frustrated about my hourly rate at OpenCraft and we already talked about that with Xavier (thanks again btw :smiley:) was because my freelance taxes suddenly bumped up like crazy so I felt “trapped” with an hourly rate that I cannot negotiate anymore and the taxes that I have to pay. But then I took a sip of my favorite tea and realized how lucky I am today to enjoy almost everything I want to.

In my previous jobs, the few times I shared my salary with coworkers was because I was pretty sure one of my coworkers had a very very low salary and when I discovered that I was pretty angry. So knowing that we have a minimum hourly rate, completely fix that for me.

This way of doing raises is fantastic, really. I totally agree with you. It makes me never leave our company. :slight_smile:

While that’s honorable and that I don’t have any better idea to offer, I don’t really like the idea of salary based on location. Work is work, and OpenCraft won’t ask clients to pay differently based on the location of the members who worked for them. And what about people moving all around the globe? I agree with you. :+1:

It really highlights how difficult it is to find the perfect solution, so the best we can do is to properly establish the rules and hardly stick with those. And that’s exactly what you are doing @antoviaque. So thanks a lot and big kudos for that.

Well, I am a little late for the discussion (I kind of messed up with my Discourse notifications settings…) but I am very happy that I found this thread and wanted to reply. :smiley:

4 Likes

As promised, I have created a merge request to add a description of the process to the handbook, for determining compensation. It is heavily based on the text content from this thread - so you will recognize some of the merge request’s text :)

Reviews welcome! I’ll give it two weeks before merging, to give time to schedule a task in your next sprint.

For this, I’m planning to add the following mention to our candidature form, which is where the candidates are asked to choose their rate (the part added is in italics, the rest is the current description):

What compensation are you expecting? (euros per hour)

Hint: Please provide a hourly rate in euros (if your country is supported, we will use TransferWise to send you the bank transfer in your local currency). Since remuneration is based on time spent working, be sure to factor in all your costs, including taxes, benefits and holidays. Note that we need it now to take a decision for the next step, so please make sure that it’s your final rate. We won’t try to negotiate - we prefer to work with you at the rate you want, not any lower. But we need to know your final rate to check if it is within our budget, so you won’t be able to change it later on in the process. Note that this is not meant as a race to the bottom, but part of a process to keep things as fair as possible. See how we handle remuneration in our handbook.

Sounds good then! :+1: I’ll still give it two weeks for others to see this, but if nobody objects by then, I’ll switch this to a public thread. I’ve also included a link to this thread from

7 Likes

It’s been long enough I think – ok to make this public now?

@jill Yup! This is part of the scope of the task I have in my backlog to follow-up on this (and merge the pull request too), but we are already good to open this thread - I’ll do it now.

To follow-up on this, I have just addressed the outstanding review comments on https://gitlab.com/opencraft/documentation/public/-/merge_requests/271 and merged it. The new page of the handbook is now live at:

https://handbook.opencraft.com/en/latest/team_compensation/

Don’t hesitate if you still spot points to address, we can always open follow-up merge requests.

5 Likes