Monday, August 21, 2006

Four Principles for Compensation Decisions

I think compensation decisions are one of the toughest parts of running a software company.

In fact, I'll just admit it:  I hate this part of my job.  I got into this business for the joy of building software.  Suddenly I found myself making decisions that affect how big of a mortgage somebody is allowed to have.  That's just not any fun.

For most people, the touchiest and most sensitive topics are money and sex.  I'm not expected to decide how often everybody gets laid.  Why do I have to decide how much everybody gets paid?

Well anyway.  Compensation decisions are an important part of running a software company and they need to be done well.  So I'll stop ranting (for now) and share four of the principles I try to use when working on these kinds of decisions.

1.  Secrecy is for the benefit of the employee, not the company

Lots of companies have a policy which prohibits employees from discussing their compensation with each other.  In such environments, disclosing your salary to a coworker can be grounds for termination.  That is simply absurd.

The purpose of such policies is to hide things that are unfair or illegal, such as:

• The person who makes more simply because he negotiated hard
  
  
• The person who makes less because he never asks for a raise
  
  
• The person who makes more simply because you hired her away from a high-paying job
  
  
• The woman or minority who is doing the same job as a white male but getting paid less

If these kinds of discrepancies were visible to everyone, people would get upset.  So a company has two choices.  They can either keep their salary chart clean or they can keep it a secret.

Let me stop and define my terms:

• A salary chart is simply a list of all the team members and their base salaries.
  
  
• A salary chart is "clean" if it could be posted on the wall and most reasonable people would agree that all the differences are fair.

To be honest, keeping a salary chart clean is a lot of work.  Some kinds of discrepancies just tend to slip in.  It's not that anybody wants to be unfair -- it's just often more convenient to do.  So a lot of companies just allow their salary chart to get all dingy and then institute a policy to cover it up.

At the other extreme is the notion of completely open salaries.  In some organizations, salaries are public information.  The notion is tempting.  It's a lot harder to be unfair if everybody can see you doing it.

But I don't like this idea either.  People care about their privacy.

So I think secrecy about compensation is important, but it should be for the purpose of protecting the privacy of individuals, not for the purpose of obscuring the fact that management is doing things they know to be unfair.

Keep a clean salary chart.  Manage it as if all the numbers were publicly visible.  And then, for the sake of the privacy of the individuals, keep it secret.

2.  Subjectivity is a necessary evil

Most people would probably agree that subjectivity in compensation decisions is a bad thing.  In an ideal world, compensation would always be tied to job performance in a purely objective and quantifiable manner.

I imagine that this ideal is actually available in many other professions.  For example, it must be relatively simple to measure the quantity and quality of the work done by a bricklayer with only two questions:

1. How many bricks were completed today?
   
   
2. Are they level?

But software developers are not like bricklayers.  Sometimes a developer spends ten days to fix a bug that ends up as a one-line change.  There are no situations where a bricklayer takes ten days to deal with a really difficult brick.

So how do we know what good performance is?  When that developer fixed a bug on the tenth day, how do we know she didn't just play Far Cry for 9 days and then fix it quickly on the 10^th?  During that same 10 day period, one of her peers implemented 5 new dialog boxes.  Another person wrote 2,000 lines of code to implement a new algorithm.  Another person changed 200 lines of code and made a key feature twice as fast.  Which of these developers were the most productive?  In general, it's pretty difficult to be precise.

So if we can't measure productivity in any quantifiable terms, how do we know how well our development staff is performing?  And how do we know how much each person should be paid?

The answer is that we just know, because we're developers too.  Subjectively, we can usually tell when someone is productive, regardless of how many lines of code are being checked in.  That subjective sense doesn't give us a lot of precision, but it gives us enough.

So I claim that subjectivity cannot be eliminated and should not be eliminated.  But I also admit that it can cause problems.  When subjectivity is present in any amount, the possibility for unfairness or capriciousness is introduced.  Even when we mean well, we may be unconsciously basing our decisions on factors that should not matter:

• Are better-looking developers making more than ugly ones?
  
  
• Are tall developers making more than short ones?
  
  
• Are people with a great sense of humor making more than those are quiet and serious?
  
  
• Is there anybody on your team who is making less simply because you don't like them?

For all these reasons, I prefer to have compensation decisions be made by a group of three people.  Two isn't enough, because ties happen.  Four is too many, because, well, it's just not necessary.  Three is just right.  When you have multiple opinions, you get two big benefits:

• The subjective part of the decision improves because the accuracy of the facts in play has gone up.
  
  
• A group conscience appears and makes it much more difficult for any unfairness to creep into the process.

Make all compensation decisions in a group of three people.

3.  Supply and demand still matter

The strongest factor in determining salaries is basic economics.  Although many other factors are in play, supply and demand are still the most important thing in determining how much each position gets paid.  Software developers get paid more than receptionists.  Why?  Because, with no disrespect to receptionists, the fact is that there are more people in the world who know how to greet visitors at the front desk than there are people who know how to parallelize an algorithm so it will work on a quad-core CPU.

For each developer, the forces of supply and demand produce a "market rate", which I will define as the base salary which could be reasonably expected by any developer with similar skills, similar experience, and similar education, in a similar position.

So I would like to make a claim that many people will consider obvious:  I assert that we must never let a person's salary get too far away from their market rate.

You should periodically be asking yourself two questions:

1. Could I replace this employee for a significantly lower salary?  (Be realistic.  If you find yourself saying "yes" very quickly, you may be underestimating the challenges.)
   
   
2. Could this employee get a significantly higher salary if s/he left and worked somewhere else?

Note that these questions seem somewhat cold.  I am not saying that you should ask yourself these questions and then immediately act on them in what appears to be the obvious way.  Just ask the questions.  They should serve as a reality check, never as a trigger for rash action.

I'm just saying that you never want to find yourself in a situation where you know you could replace an employee with someone who is paid significantly less.

And this works both ways.  If you're going to use supply and demand to justify a lower salary, you darn well oughttabe be using it to justify higher salaries as well.  You never want to find yourself in a situation where your employee knows they could work for somebody else and get paid significantly more.

Although I believe this principle to be very important, I'll confess that its application is very difficult.  The problem is that there is no precise notion of "market rate".  We know that programmers get paid more than receptionists.  But programmer salaries cover a very broad range, for many reasons.  If a software company wants to make sure they are paying competitive market salaries, how do they know what numbers to use?

Beware:  Bad salary data is easy to find.  I define "bad data" as salary data which was gathered outside my city and then adjusted for the cost-of-living index of my city.  I find that this kind of salary data often makes no intuitive sense.

I live in a twin-city in central Illinois.  Champaign and Urbana are legally separate cities, but they are really just one city with a line down the middle.  Folks who live here tend to talk and joke about the differences, but in most ways, these two cities are darn similar.

Nonetheless, the published cost-of-living indices suggest that living in Champaign is a lot more expensive than living in Urbana.  I just found a salary calculator on the web which says that a $100,000 salary in Urbana is equivalent to a Champaign salary of $121,445.  That's just patently false.

I concede that my situation is an anomaly because of the twin-city thing.  But my observation is that salaries computed with this method very often just don't match up well with reality.

The only good salary data is actual salaries gathered for actual people in your area.  When I want to verify that our base salaries are competitive in our area, I just call my counterparts at other software companies in town and ask them to trade numbers.  Even then, it's easy to end up with apples-to-oranges comparisons, but this kind of data is much better than taking national averages and adjusting them for cost-of-living numbers that somebody pulled out of their butt.

Anyway, understanding market rates for salaries can be hard, but I stick with my advice:  Don't let your developer salaries get too far away from your best understanding of current market rates.

4.  Profit sharing is not inherently wrong

Several people have observed the problems with incentive compensation:

• Mary Poppendieck:  "In the same way, once employees get used to receiving financial rewards for meeting goals, they begin to work for the rewards, not the intrinsic motivation that comes from doing a good job and helping their company be successful. Many studies have shown that extrinsic rewards like grades and pay will, over time, destroy the intrinsic reward that comes from the work itself."
  
  
• Joel Spolsky:  "Giving somebody positive reinforcement (such as stupid company ceremonies where people get plaques) implies that they only did it for the lucite plaque; it implies that they are not independent enough to work unless they are going to get a cookie; and it's insulting and demeaning."
  
  
• Edward L. Deci:  "It appears that money -- perhaps because of its connotation and use in our culture -- may act as a stimulus which leads the subjects to a cognitive reevaluation of the activity from one which is intrinsically motivated to one which is motivated primarily by the expectation of financial rewards.  In short, money may work to 'buy off' one's intrinsic motivation for an activity.  And this decreased motivation appears (from the results of the field experiment) to be more than just a temporary phenomenon."
  
  
• Seth Godin:  "Money, it's been shown time and time again, is a demotivator. I'm not talking about a fair or even generous salary. Being a cheapskate is no way to find a great employee. But once people have joined your team, incremental money--bonuses and the like--usually demotivate people."

These articles are kind of scary.  Intrinsic motivation is a precious thing.  It is sobering to think that well-intentioned employers can destroy it.

And yet, I believe articles like these can be misread.  As far as I can tell, these articles do not say any of the following:

• Managers should never acknowledge the excellent efforts of someone on their team.
  
  

• An employee should never be thanked or appreciated for their work.
  
  
• A company should never give its staff any money beyond their base salaries, regardless of how profitable the company is.

So even after reading worrisome articles like these, we have thrown caution to the wind.  For the last several years, SourceGear has made a habit of paying quarterly bonuses to our staff.  The amounts of these bonuses vary with the quarterly profit of the company, but most people consider them substantial.  In a typical quarter, an average bonus for one individual might be $3,000.  Sometimes they have been considerably higher.

The last thing we want to do is crush anybody's intrinsic motivation.  I think we mostly do these bonuses in the right way and for the right reasons:

• The bonuses are not incentive pay.  We don't dangle them like a carrot to try and get people to do things.  So although we call them "bonuses" that's not really the right word.  We are simply taking a share of the profits each quarter and distributing it to the staff.
  
  
• These bonuses are not for the purpose of getting our staff's compensation up to appropriate levels.  We try to make sure our base salaries are very competitive.  We could stop the bonuses at any time and our staff would still be compensated fairly.
  
  
• We do not pay these bonuses because the staff deserves them or is entitled to them.  Like I said, we pay competitive base salaries.  Strictly speaking, that's what employees are entitled to receive.  When the company makes a profit, the only people are strictly entitled to that profit are the stockholders who own that company.

Despite all this, I will acknowledge that these bonuses cause problems.  For example, even though we deliberately avoid using these bonuses to motivate people, we have occasionally observed people that seem less motivated right after we hand out the checks.

Furthermore, we know that once the ball is rolling it is going to be painful if it stops.  Even though we routinely remind everyone that these bonuses are not guaranteed, people have come to expect them.  Eventually there may come a quarter when we don't pay a bonus.  When that happens, people are going to be disappointed.

So why do we do this?  Why do we pay these bonuses when we have no obligation to pay them and they sometimes seem to cause problems?

The simple answer is we do this because we want SourceGear to be the kind of company that is generous with its staff.  No matter how many articles about psychology I read, empirical data consistently tells me that people appreciate money.  :-)