Introducing Open Salaries at Buffer

software engineer 1: http://www1.salary.com/CA/San-Francisco/Software-Engineer-I-...

software engineer 2: http://www1.salary.com/CA/San-Francisco/Software-Engineer-II...

This also makes the employer less accountable to the employees. The employer can easily pay somebody significantly more or less than they contribute, and the rest of the team cannot really say anything about this.

Now, there are some cultural reasons to do this--preventing jealousy, hiding inequality. But it really feels like a social band-aid, a temporary solution hiding the symptoms but not the underlying problem. Besides, everyone ends up having a reasonable guess as to who makes more and who makes less anyhow! The same dynamics develop, just with more uncertainty.

On the other hand, making salaries public takes these problems head-on. Inequality isn't bad in and of itself; some is basically necessary. But hiding that fact doesn't really help anyone. Instead, forcing people to see it head-on, deal with it and talk about it is probably a better solution.

I really applaud Buffer and the general movement towards transparency. I think it's a very healthy cultural progression and hope it catches on more widely, so that people stop having knee-jerk reactions to salary information.

EDIT: As an interesting additional note, all salaries (beyond a token minimum) at Berkeley (and the whole UC system) are publicly available at http://ucpay.globl.org/.

I've looked up various professors at the ParLab (where I did some undergraduate research). The fact that their salaries range from ~120k to ~350k did not change my perspective of anyone and did not seem to affect the lab's culture at all.

Essentially, I'd be perfectly happy to see this outside of public universities.

The other half to get to full transparency is having clear, measurable definitions of experience, and clear milestones of how to advance in seniority.

And that relates to how this starts to resemble corporate salary structures -- the key difference being that these guys have a defined number instead of a "salary grade". but the idea of plugging positions and experience levels and seniority into a salary structure is key to almost every large company. And as a result, most of the corporate angst over salaries starts to boil down to questions like: "Why is he a programmer IV, while she is a programmer III.", "How do I advance from being a Staff Software Engineer to an Advisory Software Engineer?"

This structure doesn't necessarily remove questions (and sometimes conflict) over career advancement, it just moves the discussion away from money, and towards labels and definitions.

And as some comments mentioned, there are cases where you really want to hire someone whose salary requirements do not match your structure. You may get into sticky situations like having a great coder, but you would have to make him a Lead, or a VP to actually make him fit your structure. And maybe you don't want them to have that level of leadership, because that is not their skill set. So you end up having to decide -- Is this salary structure more important than making those hires, or are you willing to let potentially great hires get away because this structure is more important to the company than those people?

That decision is not one that I will second-guess - I would think that these types of issues and scenarios, as well as other issues raised in the comments, have probably already been debated internally before this decision was reached.

But that would be an interesting follow-up post -- to hear about what discussions and debates went on before making this decision, what the expected impacts will be, why decisions were made, and what levels of growth are expected to invoke changes in this structure.