Tim on Leadership

Musings on Management and Leadership from Tim Parker

Salary Salad

One of the things I do in the first year at any company, along with getting assessments in place, is checking out my team's salaries to ensure they are reasonable and fair.  This is mostly not the case, unless a company has predefined jobs and salary ranges and sticks to them (and so far only the large companies I've worked for have those).  Most companies that are small or medium have simply hired people as the need arose and negotiated a salary that seemed to fit the employee at the time.  Which results, almost always, in a mess.

To cite an extreme, I have been at two companies in the last ten years where a senior developer was paid over $100K, and a second senior developer was paid half that, both same years in the industry and doing exactly the same job.  That's simply not fair, and while a lot of people don't disclose their salaries there are rumors that circulate and cause dissatisfaction.  (And sometimes, salary information is out there: I worked at one medium-sized company where the salary spreadsheet was stored, unprotected, in an HR directory on the main server, open to anyone to copy and read!)  To cite a second example, I had one group of 100 where the intermediate developer salaries ranged from $43K to $94K. For the same time in place, skills, and job descriptions.  That's also not fair.  Even worse, I was at one company where friends of the boss where paid considerably more than those who were not friends.  Again, not fair.

Now, I'm not saying everyone should be paid exactly the same.  There are factors such as special skills, abilities, time and experience in the industry, as well as other factors that can influence a person's salary.  But, on the whole, salaries should be within a range for a particular job.  And they should be fair (yes, it's a recurring theme with me).  So, for the sake of the group, I tend to do two things to help make things fair: define job descriptions and bands, as well as set a salary range for each.

To set salaries fairly you have to ensure you are comparing people of the same skill sets and job descriptions, so coming up with a uniform set of job positions is the first step.  I work with my directors and team leads on this, so the entire group is involved.  Typically, it always ends up pretty much the same in every job: junior, intermediate and senior developers, junior, intermediate and senior QA, project managers, and program managers, as well as bands for technical writers, IT staff, and whatever else is needed.  Each gets a general set of parameters (so a junior developer has less than three years experience, an intermediate developer is three to six years, and a senior developer is seven or more years, for example), but these are guidelines and not hard-and-fast rules.  Typically, we end up with three categories each for developers, QA, tech writers, IT staff, and so on, plus a special "architect" or "guru" (we use a different term, but that's what it is) category as well. 

Once the job categories, and a job description for each, is agreed upon by the management group, each individual in the group gets assigned to one of the job categories.  Again, I do this in conjunction with the management team, and while there's sometimes a bit of a disagreement (whether someone is intermediate or senior, for example), it tends to go pretty smoothly if the job categories are properly defined.  There's some wiggle room as to where a person fits in the junior-intermediate-senior bands, which accounts for different experience. 

After every employee in my group is categorized, I then do a salary comparison to see where everyone in each category sits as far as total compensation and base salary (many companies now use a base+bonus model and both sets have to compared).  This data is then graphed and I sit with the HR people to show them the outliers (as it's those we want to address right away).  When assessments are all done, I can then come up with a scheme to adjust salaries to match bands and assessment.  This scheme is always discussed with HR and my boss, but they almost always see the logic in the plan.

This approach has helped me ensure teams are fairly compensated in comparison to each other with the same job description, and I also do a salary comparison to the industry and local city as a whole.  We don't have to pay the highest, but we do want to be between the 50% and 75% rankings to be competitive. 

Sometimes there's huge changes in compensation because of this: I remember one case especially where a senior developer was paid in the $40K area, while his colleagues were up in the $80s.  I try not to give huge salary bumps all at once, but this guy was struggling to make ends meet with his family, but he loved the company and his job.  He got a 100% increase and remains with that company today.  Loyalty should be rewarded.  Sometimes someone is paid way too much for their job band, and that requires some tough decisions.  Cut the salary increases to keep things fair?  Replace the person?  Typically, I'll have a long talk with that person, and unless he's friends with the boss (those are difficult cases!) we compromise on this salary increases each year.

In the end, in every group I've been with in the last two decades, I've tried to ensure salaries are fair, everyone has a job description and job category, everyone knows what the salary bands for their position is, and they know how they are doing (assessments).  That tends to make for a better workplace for everyone.  And things need to be fair!