With this in mind I decided to try to create a transparent system at work to handle salaries. The problems I see with the way traditional salary is handled, especially the lack of transparency, include:
- It combines performance with remuneration,
- Programmers are notoriously bad at valuing themselves, communicating it with others and ensuring that they are adequately paid during a job interview or while employed,
- It prevents an objective assessment of what your roles and responsibilities are in the organisation,
- It lacks an acknowledgement of what you skills are worth in the job market,
- It creates two groups: management and developers. This allows a combative attitude to be created and is used to justify why developers shouldn't trust business people and management,
- People tend to find out anyway.
Some of these points I'll admit are difficult to solve whether it's a transparent system or not. However, the last two points, which I think are especially toxic, can be solved with a transparent system. In a closed salary system, people are encouraged to secretly find out what other people are worth and to provoke comparisons between each other. The time periods are often long and the information often incorrect. If a system is transparent you can solve that problem by making the information accurate and positive.
People tend to ask, "Why does Mary earn more than me?" I think I'm a better programmer/analyst/whatever than she is. Was it just because Mary started when the company had more money?
People tend to ask, "Why does Mary earn more than me?" I think I'm a better programmer/analyst/whatever than she is. Was it just because Mary started when the company had more money?
Joel Spolsky is probably one of the key influences that I've seen on having transparent salaries. For example, "Why I Never Let Employees Negotiate a Raise":
"...we knew that we wanted to create a pay scale that was objective and transparent. As I researched different systems, I found that a lot of employers tried to strike a balance between having a formulaic salary scale and one that was looser by setting a series of salary "ranges" for employees at every level of the organization. But this felt unfair to me. I wanted Fog Creek to have a salary scale that was as objective as possible. A manager would have absolutely no leeway when it came to setting a salary. And there would be only one salary per level."The Fog Creek Ladder is based on the idea of achieving a certain level of capability. The problem I had with the Fog Creek solution was that it seemed to suggest, especially in the skills level, that a programmer starts off needing help and working together and then slowly achieves the abilities to work by themselves. Whereas, where I work we wanted to do the opposite - as you get better at programming you get better at being able to explain, to listen and work with others. I think this is especially important if you want to work in an environment with living architecture.
So the inputs are simply what do you do - this should be objective and easy to see (again we're assuming a more transparent work environment where work is checked in or on a Wiki - if it's not shared you haven't done it). It's assumed that you perform well - if you're not, you're not doing your job. You can argue your role and performance separately to salary as these are assumed correct coming in.
The other input to this is local salary. As Joel has said, if salaries rise quickly or fall sharply then the employees' salary should too.
With this is mind there were three factors we used to calculate salary:
- Experience (4 bands - 0-2 rating),
- Scope of Responsibility (0-5 rating) and
- Skill Set (0-5 rating).
Experience has the least weight and is geared heavily towards moving from graduate to intermediate (three bands over 5 years) and maxing out after 15 years.
The scope of your responsibilities starts with the ability to make small technical decisions, to libraries used, and finally to cross product decisions. This doesn't mean that we have architect roles though, it means that if you are making these decisions that's what you get paid, not the other way around.
Skill set is pretty much technical abilities with an emphasis on the ability to break work up into different levels of tasks. Being able to create tasks from features, feature from iterations, iterations from epics, and charting a course across product cycles and customers.
The next part is how to we find an objective measure of salaries to match the levels we've created. I found a Queensland salary guide:
| Software | Junior | Intermediate | Senior |
|---|---|---|---|
| Analyst Programmer - J2EE | $60,000 | $90,000 | $110,000 |
| Analyst Programmer - MS.Net | $60,000 | $90,000 | $120,000 |
| Analyst Programmer - Other | $60,000 | $85,000 | $110,000 |
| Applications / Solutions Architect | $100,000 | $140,000 | $180,000 |
| Team Leader - J2EE | $90,000 | $108,000 | $117,000 |
| Team Leader - MS.Net | $85,500 | $100,000 | $122,000 |
| Team Leader - Other | $81,000 | $90,000 | $99,000 |
The main problem with these guides is the lack of acknowledgement of cross functional abilities. They tend to break out employees by traditional titles like: system administrator, database administrator, support roles, architect and programming. These are all roles that I expect everyone to be able to do. We picked the highest programmer category (MS.Net) but you could argue that it would be higher based on ability to handle iterations, customers and architecture (so maybe between $60,000 and $180,000).
Our version of Joel's ladder:
Our version of Joel's ladder:
| Experience | Average of Scope and Skills | |||||
|---|---|---|---|---|---|---|
| 0 | 1 | 2 | 3 | 4 | 5 | |
| Graduate | 0 | 1 | 2 | 3 | 4 | 5 |
| Junior | 1 | 2 | 3 | 4 | 5 | 6 |
| Intermediate | 1.5 | 2.5 | 3.5 | 4.5 | 5.5 | 6.5 |
| Senior | 2 | 3 | 4 | 5 | 6 | 7 |
The maximum score is 7 with the base values starting from your experience (0-2).
So our "developer" salary was:
| Graduate | Junior |
Intermediate
|
Senior
|
|---|---|---|---|
| $40,000 | $60,000 | $90,000 | $120,000 |
With each point (from the previous table) being weighted at $11,400 ($80,000 difference / 7 points) which means that if the points came out to a non-whole number you can calculate between those grades - a 6.3 would be $111,820 ($40,000 + 6.3 * $11,400). What might be a bit confusing is that $40,000 is really the minimum and $120,000 is the maximum.
Overall I think this is a better system than negotiating up front and then at regular intervals (usually before or after a project). It reeks of an up front heavy process. I wonder if it really needs to be? Salary seems to be one of the last things that isn't considered a continuous process - like most things in software development now are. You turn salary into another feedback process by making it transparent. Could you turn salary into an iterative process? Could you iterate on it more quickly than yearly, to possibly monthly or weekly?
While the inputs are supposed to be objective you can't say this process is value free. We've made choices over what we think is more important. As with many of these processes getting agreement maybe harder than setting up the initial process. This might as hard as trying to retroactively apply a coding standard.
The only negative I can think of is if you're a person (especially in business) that believes that everything is a negotiation and don't leave anything on the table. This is where I think the developer vs business idea comes in. I think it's an overall cultural negative - especially if these are the same people who are creating customer contracts and the like. As a developer you want to work with your customers and business people.
Update: "Psst...This Is What Your Co-Worker Is Paid":
While the inputs are supposed to be objective you can't say this process is value free. We've made choices over what we think is more important. As with many of these processes getting agreement maybe harder than setting up the initial process. This might as hard as trying to retroactively apply a coding standard.
The only negative I can think of is if you're a person (especially in business) that believes that everything is a negotiation and don't leave anything on the table. This is where I think the developer vs business idea comes in. I think it's an overall cultural negative - especially if these are the same people who are creating customer contracts and the like. As a developer you want to work with your customers and business people.
Update: "Psst...This Is What Your Co-Worker Is Paid":
Little privacy remains in most offices, and as work becomes more collaborative, a move toward greater openness may be inevitable, even for larger firms...But open management can be expensive and time consuming: If any worker's pay is out of line with his or her peers, the firm should be ready to even things up or explain why it's so...And because workers can see information normally kept under wraps, they may weigh in on decisions, which can slow things down, company executives say.
Once employees have access to more information, however, they can feel more motivated.
