![[A picture of private offices at Fog Creek Software]](/i/newdesign-header.jpg "Joel on Software")
Wanted: Product Engineer - Ruby on Rails at Kickball (Palo Alto, CA). See this and other great job listings on the jobs page.
Joel on Software
Feedback on Programmer Compensation
Here's some feedback from my original programmer compensation article. Based on this feedback, I rewrote the policy: the new one is here.
Your level 13 and 14 seem a little odd, especially 14. Firstly, creating new programming languages doesn't sound like a very good indicator of exceptional quality or intelligence, though I think I know what you were intending. For instance, you and I clearly know a great many very bright people. How many general purpose languages are there?
Also - the 10 years plus fits a great many people - like myself. If anything, those are the people with the CTO-like skills. Level 13, CTO-like skills with 5-10 years of experience...well, that's partly why so many "dot coms" are "dot going away."
Personally, I like performance-oriented compensation. And companies that are slow to hire and quick to fire stand a better chance of insuring they have credible, reliable technology staffs.
I'll probably have some more useful comments later.
- David Geller
Neat. I like the egalitarian and transparent nature of it. If I was still coding, I'd mail you a resume right now.
Of course, you've removed almost all individual incentives, which may or may not be ok.
Might I suggest a radical approach when it comes to the stock options? Silicon Valley craziness has made granting stock de rigeur, but it doesn't really accomplish what it's meant to. Usually, only founders and top management own enough stock to make them care deeply about the company's fate and problems. With later-term employees, they own a bit to make them feel franchised, and can be incented through promises of more.
Unfortunately, it's with the early employees that stock options tend to fail. They have too much for subsequent grants to make much of a difference, and too little for them to be committed to the same extent that management or founders are.
Also, if you mis-plot the risk curve that determines how quickly option grants scale down, there's almost nothing that you can do to rectify the situation later (short of granting a boatload of options to the later people and destroying your stock structure forever).
I'd suggest a different approach, that doesn't apply forever - profit sharing. You can share a very large percentage of the company's profits when the company is young, and slowly bring the percentage down over time as the company matures. At the end of the day, it amounts to the same thing, as the discounted profit stream is the equity value of the company. However, you avoid irrational temporary market swings, and more importantly, if you make an allocation mistake, you're only stuck with it until next year, not forever.
The situation that you're trying to avoid is having someone mediocre but early sitting on a ton of options whereas someone who has joined much later but is doing a great job has far less stock. Best intentions aside, it happens ALL of the time, unless you've been a genius about keeping the risk / reward ratio sensible.
Of course, options have positive tax benefits over profit sharing, but you get my drift.
- Naval Ravikant
No - don't hire consultants - you are definitely on the right track. The only thing that worries me a bit is the 'years of experience' yardstick although the fact that you are linking it to technology exposure is good. Exposure and experience do not necessarily make a better programmer but they certainly do help as long as the person has the extra abilities to be a lateral thinker and a 'solutions' person.
People who do/try different things could also have the edge over those who exclusively program - for instance, I reckon that my 10+ years as an analyst programmer working on different systems certainly helped me be a better dba.
Also be wary of the person who has had superficial exposure to heaps without being expert in any - they abound.
I am sure that you know where you are going with this and will succeed admirably. You should know your market and what you need to pay/offer to get the right people.
- Dale Goopy
I think your level system, the bonuses (as percentage of income), and the stock option scheme are quite solid. Your levels seem to be well thought-out: I can think of few people who would not fit either within one category or between two categories.
However: your startup package exhibits a flaw. By inflating the appearance of compensation rather than actual compensation, you draw certain types of individuals, don't you think? Consider your case of the new college hire. She (to pick a random gender) is offered a position for $70k / year by a competitor. You counter with $60k / year, plus $15k startup. "Woo-hoo!", she thinks, "I'm rich! $5k extra!" After two years, howver, the competing job would have grossed her $140k while yours grossed her $135k, and this delta increases by 10k / year. She is probably one of three types of people, it would seem:
- She can't do elementary math.
- She is more interested in the short term (< 24 months) than any sort of long term.
- She plans to grab you for the cash and ditch you after a year.
Do you really want any of these people working for your company?
Also, your equality of salary increases the granularity of your system. This generates a stair-step: an employee knows not to expect a raise (at least one unequal to that your coworkers receive) until he or she crosses a certain threshhold. It leaves the employee in the situation of saying "I made level 13 eighteen months ago, so I probably have (on the average) three and a half years left until my next significant pay increase." This person may foresee greener pastures, methinks.
On the whole, I think this plan has significant merits. I do think it requires some tweaks, however.
- Joshua McGee
You seem to have come up against a difficult question of fairness, particularly when taking on new hires.
I wish I knew the answer to these questions. I think you're right on having an open and fair policy, I tend to believe that an open book is essential for fairness. I'd guess that the issue of the startup bonus incentives offered can then be influenced by the group of programmers you already have (often loosely referred to as 'the team' ;).
If (following your example) the potential new hire understands your system, but goes on to take the other position anyway, at least they may be tempted back after they're in place & get over the honeymoon period. (not that you'd want to make this a habit of the hire ;).
I think one of the big things that's missing from many organisations is that when someone accepts a position, there's a whole plethora of lifestyle issues to be covered. Where the applicant can see that the new workplace welcomes their lifestyle, and offers a balanced merge between the lifestyle and work, then you're bound to have them being settled in working productively sooner.
- Ray Goopy
Hello Joel, excellent site BTW! Great articles, I wish every place had your ethics.
I think the salary ranges should be based on the market and location. For instance, I live where 40k a year is a nice salary. I have been recently offered a job in San Francisco for 74k but up there that isn't very much.
Or, are you basing the salary on your area?
Also, you mention college grad. Does that mean all your levels require some college?
As far as signing bonus, if I were going to re-locate a signing bonus is very important.
Just thought I would provide some input.
- Scott Burton
I don't think I agree with giving everyone in a particular level the same salary. No two people have the same contribution towards a company's success, so why should their salaries neccessarily coincide? I feel that this policy will simply frustrate the more productive members of your staff.
- Sid
Some comments:
- I found it interesting that I didn't fit anywhere in your chart, with 23 years of programming behind me. Some of us have spent more time teaching and mentoring than writing new computer languages. IMO, that's a good thing.
- You've left out one important part of programmer compensation, in my experience. Give every programmer a conference and training budget. Geeks want to go hang out with other geeks. Let them decide if they want to blow the budget on a Geek Cruise, attend JavaOne, or stay at home and buy a copy of every ORA book ever published.
- I'm also a fan of a tools & toys budget. Let each geek decide themselves which is more important: a new nerf gun, a fancy trackball, or a better set of speakers? Each can be an major productivity booster for the right person.
But then, after 13 years in the corporate world, I've found I'm much much happier being freelance, so what do I know? <g>
- Dori Smith
six different levels, Level 9 through Level 14
I assume you got these levels from somewhere else you've worked.
Why not just cut through the obfuscation and make 'em 0-5 (or 1-6 if you feel bad about someone being a zero)? If you're keeping slots open for administrative, QA, and janitorial types, why not just put 'em in another class entirely?
You've got interns on the list, and you've got team leaders, but you have no spot for a senior programmer who has no desire to lead a team. There are lone-wolves like this who simply don't work and play well with others. Maybe you're not interested in hiring them, but if you are, you should account for them somewhere.
You also don't seem to have a place in your matrix for a teacher. By that I mean a mid-level to senior programmer whose strength is being able to teach others (including more senior people) skills they don't already have. Especially if you're planning on hiring interns at any point, you'll need this sort of person. A good teacher may not be extremely productive in developing new code.
Another one you've omitted is the professional maintenance programmer. The person who comes in and can debug a complete dog's dinner of code. The person who can see that there are three ways to fix code: 1) massive rewrite; 2) minor rewrite of a function or two; or 3) one-line change with a heavy comment about how someone might wish to rewrite the code later. There are very good reasons for each of the approaches, and knowing which to pick isn't something everyone is good at. For that matter, some folks are much better at debugging, while others are born architects. The skill sets needed for the two positions are very different. How do you reconcile the two? If you're being hired guns, it's quite possible the person with better debugging skills will actually bring in more revenue to the company. I've seen this overlap with the teacher position more frequently than other types of programmer.
Compensation consists of:
You left out time off (though you may consider it part of benefits). The reason I'm running my own business is that no company was willing to hire me on the terms I was looking for. I was looking for a job that was roughly full-time (but in fewer, longer days per week) for about 3/4 of the year. I'd have been willing to take 3/4 (or even slightly less) of full-time salary in order to have the time to enjoy things other than work. In most companies, the only way to do that is to work a year or two, and then either take a leave of absence or quit, knowing you'll have to look for a new job when you return.
Benefits are equal for all full-time employees.
I think a better solution is to have a shopping-bag concept of benefits. Employees get a certain amount of benefits, and can apply them to different types of benefits. A single employee will spend less on health-insurance, but may want to spend more on the health-club or a tuition-reimbursement program. A married person with children will need to spend more on health insurance and day care, but may not have time for the health-club. There are a lot of variations, and one size does not fit all.
One thing I've been pondering is simply punting on fixed benefits and saying "You have n% of your salary to use on benefits. You can allocate it among the following: health-insurance, dental insurance, 401K, ESPP, vacation time, discounted hardware purchases, tuition reimbursement, valet service, tax preparation, etc..." That can be tricky tax-wise, but it's even trickier for the employee to figure some of that stuff out. Spend a few extra $$ to have the corporate accountant figure out how to make it work, and save the employees the hassle.
Stock Options....
Feh! on stock options. They interest me little if at all. If the company is publicly traded, a good ESPP is more interesting. If the company is not publicly traded, stock options are worthless scraps of paper, and may actually cost me money in taxes for a net-negative. Of course the company may go public and do well, but it also may fold before reaching IPO.
And if we're having trouble hiring because of low salaries, we'll raise the salaries for everyone, even the people we've already hired.
One way of looking at salaries is asking yourself: "What would I have to pay to contract this programmer back six months from now after she leaves because we don't pay her enough now?"
The answer to that question can be pretty illuminating. One company I quit was simply unwilling to pay to contract me back after I left, even though they've had two problems I could have walked in and fixed rapidly. Instead, they wanted the security of having someone on-staff who had spent the time to figure it out. Good for them.
Another company that wouldn't meet my desired salary has since contracted me for almost six months worth of that salary for two months work. I suspect they're regretting their decision, but they do have more flexibility now.
as a company, we are very concerned with equity and fairness in salaries. We think it will be extremely valuable to maintain salaries, bonuses, and benefits for programmers at equal levels rather than negotiating individually with everyone and then having people upset that they are not getting a "fair" salary
I think if you truly want to be equitable, you're going to find out that there will be enough special cases, that your pay-parity will quickly evaporate. I've mentioned a few, but there are more that I'm sure I haven't thought of. Being fair is a good ideal, but because of the special cases, equal pay is unlikely to be fair.
- Dave Polaschek
In the company I work for, we do negotiate salaries, which I agree with you it is wrong. But I have one problem in your scheme. Let's say you have 2 developers 1 year experience, same exact level, but one is amazingly smart and fast, the other one is slow, fast and slow means time to finish a certain task in a certain amount of time without major bugs, etc.. etc..., how can you differentiate between those, in this scheme you can't because they will take the same salary and the same bonuses, I see that the motivation to excel is not there... I agree with the same salary scheme for the level, and the startup bonus, but the drive for each person to excel is important too. This might be achieved by an indvidiual bonus or other ideas... What do you think ?
- Ahmed Badr
Editor's note: I don't really believe in individual bonuses or performance incentives, because I've heard a lot of research that says they don't work:
Incentive Pay Considered Harmful
But, to answer your question more specifically, if I really had one programmer who was simply much more productive than usual and wrote code much faster, we would probably just bump them up a level even though they don't meet the other criteria. I don't want the criteria to be hard-and-fast, just general guidelines. - Joel
I think that you're totally on the right track, and identifying your levels as mere guidelines is key. I would give the levels names, fun or serious. Numbers make me think of government pay scales, and leave less flexibility to change them later (unless you like decimals or re-classifying everyone).
I do have to disagree with using large startup bonuses to bridge an offer gap. It creates a mercenary ethic from the start. If a salary of X doesn't make me happy now, as an "unknown risk" to your team, I'm going to be less happy with it down the road once my value to the team has been well-established. I would cap the total startup bonus at $10k and extol the value of the benefits package. Vacation time to me is worth at least twice it's straight salary value, and it's a benefit that most American companies (esp. tech!) are stingy and inflexible with.
(I'm working with a guy who wasn't able to use all of his vacation time last year, a serious no-no in Germany, so he's wound up with 8 weeks for this year. Being on our American payroll, I have serious vacation envy! Not enough for me to switch payrolls, but you can be sure that it will be the only compensation matter discussed at my next review ;-)
- Bryce
Look at Steve McConnell's stuff at construx.com. He has various programmer levels etc. etc. Looks like it's similar to what you've already shown, so maybe you've already been there. We're a pretty small shop with 25 or so programmers and recently went to a three-level basic structure: engineer, Sr. Engineer, Principal Eng. Early feedback is that's not enough granularity. We have a pretty wide range of skills in each level. Probably go to more like you're thinking in next go round.
- Chris Markle
Editor's note: Construx's stuff is exactly what I was trying to reconstruct. Steve got the idea and copied the ladder from Microsoft, and I did do, but I was trying to reconstruct it from memory! - Joel
I like the idea of having levels and paying everyone according to their level. Publishing uses this system for the first two levels (editorial assistant and assistant editor) and it creates a lot of camaraderie since everyone is getting paid the same. Once you're an editor, though, your salary is based on your years of experience and the P&L's of your books. You may want to consider using the level system for your more junior employees but having more freedom to distinguish between the senior ones.
You don't mention it specifically, but I'm assuming that it will be public knowledge what everyone's level is and how to progress to the next one. This is a key factor. I like the consenus approach about setting levels, so long as the employee gets a chance to present their side of it.
What about annual raises? I think everyone expects some sort of annual raise even if you can still hire new programmers at the same wage level as the old ones. And honestly, someone who's worked for you for a year is worth some degree more than someone with equal skills who doesn't know anything about your company or your software.
On today's topic of compensation, I really like the idea of open and fair salary guidelines. I've never truely understood why salary is such a taboo topic when we'll tell everyone how much we paid for a car or house.
Perhaps it is a bit of utopian, but one would hope that if an employer adopts an open and fair salary policy, they would fully grasp being fair and open and a corporate policy.
- David Benson
How about individual bonuses awarded directly by the employees? I can imagine a bonus plan wherein every employee is given 5% of their own salary to award to other employees. Does incentive compensation of this sort also have the same problem as other incentive compensation?
- Kevin Postlewaite
I'd like to advise you to go ahead with your compensation ideas based on my experience with companies that have done things that way. Sadly, I can't. Every company I've been in has kept these things secret. Instead I urge you to do it simply because I'd like to work at a company with those policies.
I work for Dictaphone (private), which was recently bought by Lernhout & Hauspie (public), so we're getting stock options soon, but it's supposed to be a big secret how the amounts are awarded. We got mail with our share amounts saying do not discuss this with coworkers! What's up with that? Amazingly, many members of my team went along with it! Fortunately a few of us did an "I'll show you mine if you show me yours" session, and we were able to figure out that it's simply based on salary grade. Big deal. Why not just publish that? Secrets do more harm than good.
I suppose that there will always be resentments and perceived injustices with compensation policies. You have to accept that. But keeping it open and telling everybody up front that it's open will, I believe, keep it from interfering with the work.
- John Sands
Earlier this year I was handed a tremendous challenge - to pull together a disorganized department and then design, implement, QA and ship a terrifically complex system with a do or die release date ... of three months later. I can tell you all about it some time because it worked and I learnt an enormous amount about development, management and design but what I wanted to mention here are two things the CEO did that were strong factors in the success of the project - both rather irregular.
#1 - Personal pressure and help: At the time, there were two levels of management in between myself and the CEO. Both were dysfunctional. The CEO cared more about the project than about "dis"ing the two middle managers and set up a weekly status meeting between himself and me to go over the status of the project and do risk assessment. No one wants to disappoint his/her CEO, thus, boy was I on top of the project. Also, if I was having trouble with resource issues he could cut through any red tape and make things happen for me.
#2 (relevant to the bonus question) - at the first status meeting he gave me a massive bonus (options that are currently worth about $150,000) and said that he likes to give bonuses BEFORE the success - he finds it's much more concrete motivation. Now this is a bit of a dirty trick but it sure does work. I plan to try it with my team next real crunch.
I really like your approach to salaries, though you need to have a certain amount of flexibility with the ranking. One of the biggest sources of tension we have in the department is due to people think other people are getting paid more than them. One of the biggest headaches we have when hiring is dealing with people who are good but would throw our salary scale of kilter. Your suggestion solves both very elegantly. The one question I have is what do you do with salary reviews? Over here, people expect a 10-20% raise every year (in addition to any raise due from a "rank" promotion). Would you only give people a raise if the raise in rank? Or maybe instead of a salary raise have an individual bonus at the time of the salary review that would do the same as the start up bonus?
- Anonymous
Want to know more?
You’re reading Joel on Software, stuffed with years and years of completely raving mad articles about software development, managing software teams, designing user interfaces, running successful software companies, and rubber duckies.
About the author.
I’m Joel Spolsky, founder of Fog Creek Software, a New York company that proves that you can treat programmers well and still be highly profitable. Programmers get private offices, free lunch, and work 40 hours a week. Customers only pay for software if they’re delighted. We make FogBugz, an enlightened project management system designed to help great teams develop brilliant software, and Fog Creek Copilot, which makes remote desktop access easy.