At Fog Creek Software, the way we make sure that people are paid fairly and rewarded for excellent work is based on a professional ladder.
Historically, our ladder is based on Microsoft's professional ladder, which was adopted and publicized by Construx. Many of the guidelines you see here are blatantly copied from there, with minor modifications for the culture we are trying to create. The categories also correspond closely to standard US corporate compensation practices as documented in this book by Michael O'Malley.
Fog Creek explicitly recognizes that many good software engineers have no desire whatsoever to do "management" or to take on a formal personnel management role. One of the purposes of the Fog Creek Professional Ladder is to create a career path with promotions for engineers who simply do not want to do management stuff at all. We want to avoid the trap that many companies fall into of forcing good programmers to stop programming and start managing people, if that's not what they want to do.
For various irrational reasons, nobody likes to be a level 1 or 2, so HR departments have always historically started the numbering with a higher number. So all Fog Creek software engineers are ranked at one of several different levels, level 8 through level 15.
Our official titles will be:
(8) Technical Intern
(9-12) Member of Technical Staff
(13-15) Fog Creek Fellow
"Member of Technical Staff", a.k.a. MTS, is the classic title that all researchers at Bell Labs were given in their heyday. It's neat and egalitarian.
When we decide to hire someone, the interviewers who were involved in the "hire" decision will sit down with the candidates resume and salary history and figure out what level they will start at. After that, every six months, Fog Creek management will review the performance of everyone in the company with the goal of making sure that people are at the right level. It is most important to make sure that people are grouped in the same level with other engineers who are their true peers. At this point it might be appropriate to promote some people to a higher level. We will also compare our salaries within each level to the competitive norms to make sure we are paying market salaries, at which point people might receive a raise.
A word about performance reviews Many companies use regular, formal performance reviews as a "carrot/stick" incentive system to obtain performance. For various reasons discussed here, we tend not to like this system. In principle, managers should give their reports constant, regular feedback, positive and negative, on the quality of their work, in the "One Minute Manager" style. (If the negatives tend to pile up, we'll start logging them. Nuff said.)
Our biannual reviews are done internally by management; they are not intended as a way to give employees grades or gold stars. Their goal is simply to make sure people stay at the right level and are recognized when their work improves with experience.
Everybody is different, and their skills and aptitudes may show up in different ways. One excellent contributor might write a ton of great code; another's strength might be in getting teams to jell and work together. It's impossible to use hard-and-fast metrics to decide where someone fits in, and these kinds of metrics tend to accidentally incentivize the wrong things. Instead, we have a bunch of heuristics which tend to provide an accumulation of evidence that a given engineer belongs in a given category. When we're done applying them, we look at some of the other people in that category to determine if we got the right result. Nothing is carved in stone except the principle that within each group, people should be true peers.
Transparency Policy In the interest of fairness, Fog Creek's compensation policy is open, public, simple, and accountable. Many companies try to obfuscate the rules they use for determining compensation in hopes that they won't get caught paying some people too much and others too little. Some companies actually consider it a firing offense to reveal your salary!
We feel that in the long run, this can only hurt us through negative morale, high turnover, and destructive office politics. Therefore, the policy in this document is publicly available. People have a right to know what the levels are and what they mean. Everybody has a right to know what their colleagues' levels are.
Similarly, the rules we use to determine salaries based on levels and other factors are simply, easy to understand, and public knowledge.
Yes, that means you can figure out what your coworker is making. So what? People in public service, the army, the police, and unions can all figure out what their coworkers are making. This transparency policy is a good thing that forces Fog Creek management to keep things fair.
Here are the heuristics we use in determining what level someone is at.
Years of experience
We don't care too much about degrees, because they don't correspond all that well with skills for software engineers. A lot of newly-minted PhDs are sorely lacking in practical software engineering experience that some BAs with one year experience may have.
Most people fall into four rough categories based on the type of work the are doing. These categories are quoted from Chapter 2 in O'Malley.
- Strategic. These people sit around thinking "lofty thoughts about markets, products, the competition, and the like. They determine the general direction of the company and set the short-term and long-term financial and non-financial objectives of the company." Level 14 or 15.
- Tactical. The people who have to figure out how to execute on the strategist's ideas and "send the troops into battle". Level 12-13
- Operational. The people who "make things happen in the right way, at the right time, with the right people, at the highest quality, etc." Level 11-12
- Executional. These people actually - eep! - do the tasks. Level 9 -10
- Learning. My own category for interns who are basically learning how to do things. Level 8.
See the book for guidelines on deciding where someone fits.
These categories are stolen from Construx, who, in turn, stole them from Microsoft (so there).
- Someone who is learning the basic principles of software engineering on an internship basis, and who works under close supervision and is not expected to write production code. Level 8.
- Someone who works under some supervision and occasionally writes production code. Level 9.
- Someone who has some background in software engineering and is qualified to write production code without much supervision, although they probably aren't designing anything. This person will be expected to learn the software development lifecycle practices, methods, conventions, and standards of the computer industry. They understand and practice the skills of The Joel Test. Level 10.
- Someone who is familiar with industry practices and therefore can work independently as necessary. This person proposes design approaches for review and agreement from peers and his or her supervisor. This person has worked on one or more shipping projects, and has experience in each of the basic software development lifecycle steps needed to ship a product. This person is very competent in nearly all code-centered, detailed-design centered, and task-centered areas, and demonstrates additional competencies in other software lifecycle areas. Teamwork skills are excellent. Level 11.
Someone who has consistently had major success during their participation in all aspects of small and large projects and has been essential to those projects’ successes. This person has a track record of consistently rendering clear technical judgment and routinely considers architecture-level and project-planning issues. They ensure that projects are conducted in ways that benefit the project objectives, the people participating in the project, and Fog Creek’s long-term interests. They are innovative, consistent, and contribute beyond the assigned tasks. They are mentors to others. They actively seek accountability. They have achieved mastery of The Joel Test. Competence extends to architecture, user interface design, project planning, and other project-level issues. Teamwork skills are excellent. They are committed to a self-study program, reading books and journals. Level 12.
Someone who has been critical to shipping a world-class product. This person takes total ownership for all aspects of their project and makes many unique contributions. This person’s decisions have a significant impact on Fog Creek's profitability and overall well-being. They routinely provide technical direction to other groups and people. Their competence extends well beyond project-level issues to company-level issues. Level 13.
- Someone whose areas of competence extend beyond company-level issues to industry-level issues. Teamwork skills are excellent at the project, company, and industry-partner levels. This person contributes regularly to the industry through publishing papers, making conference presentations, teaching classes, and participating in technical committees. Level 14.
- A industry-recognized leader within the software engineering field. This person consistently works to design and produce groundbreaking, world-class products, or in advanced research. Level 15.
Fog Creek will maintain a simple schedule of salaries based on level. We don't really know how to divide people up with more granularity than our ladder, so, for purposes of fairness, there is no salary variation within a level. However, we will have:
How do we know what the right levels are for salaries? There are two ways. One, we can subscribe to surveys and try to track how we compare. More importantly, we can try to get a feel for the salaries that we have to offer people in order to get them to join up: if we're losing a lot of new hires because our salary structure is insufficient, we have to raise salaries; similarly if we never have a problem getting people to accept an offer, it's ok for salaries to stagnate for a while until the market catches up. (It goes without saying that it's never a good idea to lower salaries.) Once we are hiring on a regular basis, I think we'll be able to figure out a metric like "percentage of people that decline our offer primarily because the salary isn't enough", and decide what an acceptable number for this metric might be.
One thing I suspect is that our great benefits (see below), especially our six weeks of vacation, means we will be able to pay 5-10% less than other employers who have run-of-the-mill benefits.
Bonus plans have too many problems.
They've become like tips in restaurants: everyone expects one, so they can no longer be used well to reward good performance. They are too indirect: year-end bonuses just are too far removed from the actual work to serve as a useful inducement. And they tend to create as many negative feelings and politics as good morale.
So we don't have bonuses. Instead we have:
This is a way to reward the whole Fog Creek team collectively when we have good years. Profit sharing is at the sole discretion of management. Each year, Fog Creek management will determine what total dollar amount should be awarded for profit sharing. It might be 0 in fallow years. It could be a lot more. This amount will be prorated according to salaries and percentage of the year that people worked, so every employee will receive a part of the profits amounting to an equal percentage of their salary. Profit sharing is based on the performance of the entire company, not the individual. (Also, there is no penalty for quitting the company before profit sharing is paid: if you do this, you’ll still get your prorated profit share for the part of the year that you worked. This policy is to prevent getting a wave of people quitting every January and screwing up our lives).
Benefits are given equally to all full-time employees. (We may end up with categories like intern and temp with more limited benefits). Some employees may get more "value" out of their benefits than others (e.g., if they use the health clubs).
We have a long menu of benefits that we want to offer. I should mention that Fog Creek is just starting, we're a new company, and we don't have a lot of cash. That means that these benefits haven't kicked in yet. They will as soon as we can afford them, but I don't want any misunderstandings :) As time goes on and our cash position becomes stronger, these benefits will start to kick in.
Stock Options are weighted heavily to compensate the people who take the most risk, namely, the people who join Fog Creek when it's just a wee tiny company and we're all jammed into one tiny office and we can't afford to buy your kids braces and sometimes you have to change the Poland Spring yourself.
As the company grows, the initial package of stock options offered to new hires will be lower and lower. At any given time, stock option awards are equal based on level. Once a year we'll grant people more stock options.
Stock options are not intended to replace salary. I hate companies that say "we're only going to pay you half what you're worth, but the stock options will make you a zillionaire when we go public!" Fog Creek might not go public. You might not become a zillionaire. But you still get some stock options, so that if we are a huge success and we do go public, you won't be left out.
Generally the startup bonus will be about 10% of a new hire's salary and comes with the first paycheck. If you leave within 12 months for any reason, you have to pay it back.
In order to remain market competitive at all times, we are constantly reevaluating our salary structure. If we notice that we're having trouble attracting people because our compensation is not competitive, we'll raise the base salaries -- which affects everyone in the company, not just the new hires. This is intended to prevent "salary compression" or "salary inversion": that awkward state where market salaries have gone up and new hires are earning more than experienced hands, which is simply not acceptable.
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.