The question is, when going from private to public information, how best to handle it so that it isn't a source of chaos.
The question is, when going from private to public information, how best to handle it so that it isn't a source of chaos.
I often think its that the transparency is only halfway that causes many of these peer to peer problems. It also doesn't help that most white collar work these days isn't directly translatable to revenue. Its easier to tell a salesman what he's worth than a designer etc...
They definitely have the option of not offering the raise and the employee choosing to leave. If the employee isn't worth X dollars more then the company should be ok with them walking without that bump.
In the end the issue being discussed is asymmetrical info, and positions. If an employ is producing less than their cost they don't get to keep that "surplus". They get written up / fired. But if an employee is producing more than their cost, the employer gets to keep that surplus. It's an imbalance.
Asymmetrical info on salaries produces this situation. I'm not saying it's right or wrong, but it is imbalanced.
This is the crucial bit: "In a study of engineers at two major Silicon Valley companies conducted some years ago, I found that nearly 40% perceived themselves as performing within the top 5% of their peers. Ninety-two percent felt they were in the top quartile, and only one engineer felt his or her performance was below average."
Say you're the manager. Let's start off with the optimistic case: you have a good relationship with your team, are using objective but not necessarily easy to measure (to prevent gaming) criteria to evaluate your employees, and you are pretty accurate in your assessment of how valuable each person is. They aren't going to believe you. Almost everyone thinks they should be near the top. You have no way to win this unless you judge purely based on lines of code or other such measures, in which case you've actually already lost for other reasons.
And then consider how hard this is for a less experienced manager new to the team, who might not have a full picture of everything but is going to get hammered by people complaining about not being at the top of their peer pay grade.
You can go away from pay for performance, which the article notes, but do you really want to? Is that the situation you'd prefer to work in, where you know what someone makes purely because you know how much anybody with that many years tenure would make?
There are also multiple definitions of "good developer" (speed/output level vs maintainability vs project definition and architectural influence vs firefighting vs...).
That doesn't mean they're all what a company needs at a given time. This leads to another way you end up in hard managerial conversations: you're good at X, but the business has changed and Y is driving our bottom line much more than X now, but you have no interest in Y and are resentful that you aren't being rewarded as handsomely for X anymore. What do you do if you're a manager who knows the odds of X being that important again in the future are very low (maybe there's enough structure in place now with automated testing and such that firefighting is way less critical than it was when small), but the one-time-star starts complaining that their raises have gotten smaller as they've resisted coaching/directional changes for the past year or two?
And if you're completely transparent with salaries, you've got an extra problem: this person could be higher paid than some of the people contributing the most right now, and explicit specific knowledge of that will just make even more people unhappy, if you aren't in a position to simply raise everyone's else's pay to match.
Representative ranges (with room for overlap for e.g. someone peaking at one level vs just starting at the next) give you many of the benefits with far less of the ego bruising. Generally you-as-employee can get a feel for what these are after a couple years even without it being explicit, IME.
This should be open discussion whether you have transparent salaries or not. Long before it comes to salary decision, the topic of "we need more Y, learn it" should happen. Not just because of salaries. If transparent salaries force it, then it is a good thing. Not just because of fairness, but because developers often focus on the wrong thing. And because when manager opens it, sometimes it turns out there is obstacle for doing Y that can be overcome with help of manager.
I mean, really. If you valued X in the past and just merely praised people for it and now it is changing to Y, be clear and tell them. It is very unlikely that your ninja coder turns from best to worst overnight just after slight strategy change. If he was so awesome, he will be able to learn new thing fast - unless there is some kind of resentment going on in his head which usually have little to do with strategy.
Non transparent salaries dont prevent people talk, dont prevent resentment either, but you usually end up with humble/shy coders having much lower salaries then overconfident ones. And I seen that humble/shy getting really resentful when he figured it out.
I'd argue that it is a sign of a healthy company when each employee is producing more value than they are taking home in their paycheck.
I am instinctively for transparent salary information, but I'm not sure if I can intellectually back it up.