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
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
- The person who makes less because he never asks for a
- 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
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
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
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
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:
- How many bricks were completed today?
- 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
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 10th? 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
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
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:
- 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.)
- 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
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
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."
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
- 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
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
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
- 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
- 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. :-)