Are Developers Good Negotiators?
Developers come from all walks of life, and have many unique interests, passions, and hobbies. Often the only thing that developers have in common is their love for programming. It follows that some are good negotiators; others get the double digit percentage finance rate at the dealership when they go in to buy that new car.
How Does Your Company Determine Compensation?
When you hire developers, how do you decide on their salary? Do you allow for negotiations to take place? Is there a strategy in place where you offer a low value, expecting the candidate to counter with a higher number? Are you pleased when they don’t counter, and you get good talent for cheap?
The thing is, developers are the linchpin in your tech company. They make or break your products – quite literally, in fact. They’re worth a lot of money. You should be paying them what they’re worth as one of many strategies to keep them happy. If you’re low-balling developers with a salary strategy that rewards negotiation skills, you’re probably underpaying them while overpaying the developers who are good negotiators (but maybe not amazing coders).
Your underpaid talent might not feel comfortable asking for a raise to the income that they are worth. Can you guess what happens then? They leave your company for another that values them correctly. The result is that your department has high turnover, lots of churn, and high costs around replacing the fleeting talent.
Stack Ranking: Upsetting Developers Everywhere
One of the most common ways to compensate employees is by employing a stack ranking system. There are varying approaches to stack ranking, but a typical implementation of a stack rank system is as follows:
- A company employs a ranking system, often a scale of 1 to 5, to assess employees.
- These numbers often come with generic and impersonal descriptions. The scores themselves are bucketed with percentages that limit the number of employees that may receive a given grade:
- 1: Exceptional (10% of employees)
- 2: Highly Effective (20%)
- 3: Consistently Strong (40%)
- 4: Partially Effective (20%)
- 5: Not Effective (10%)
- Managers are given a fixed $X in raises to hand out for annual reviews.
- The $X budget for raises is distributed per the grading, with the 1’s getting the biggest chunks, and 5’s often getting nothing.
- Note that this is how stack ranking is used to control budget costs. You always know exactly how much money is being given out in raises.
- The 4’s are warned that they’re on the way to being fired if they don’t shape up.
- Typically, the 5’s get fired or put on a performance plan.
This system – also known by the endearing terms “rank and yank,” “forced distribution,” and “grading on a curve” – is popular because it control costs, both in terms of annual raises and also under-performing employees. It serves as a system that forces the bottom 10% (or whatever the bucket is set at) out of your company regularly. This is not a bad thing in-and-of itself, assuming that the replacements hired are any better. Of course, this is where one of the major problems becomes evident.
Why Stack Ranking Sucks
Here’s the thing: someone always has to be a 5. This system is built on the false assumption that there’s always someone who is Not Effective on your team. It institutionalizes the idea of mandatory mediocrity.
It is easy to see how ridiculous this concept is when you apply it to objects instead of people. For example, let’s review 5 cars with stack ranking: a Ferrari, a Lamborghini, a Maserati, a Porsche, and Rolls Royce. Which one is the exceptional one? Which two are under-performing and mediocre? In this all-star set, they’re all great, but stack ranking demands that one is worse than the others by a large margin.
What happens if you employ good hiring practices and recruit a team of 10 amazing developers? What if they’re all 2’s and 3’s, but you have to give out 4’s and 5’s? You end up having a difficult annual review where you find yourself apologizing and telling your developer how great you think they are. Because you really do think that. But your words are hollow, and their raise and review are the actions that speak louder; at this company they are thought of as mediocre, because someone has to be.
Have you ever had a review where the actions of your manager didn’t match their words? You’re being told what an all-star and amazing player you are on the team, how important and awesome you are, and how everything you touch turns to gold, but your review says “you’re average” and that big fat 3 rating is searing itself into your brain. You’re wondering “if my boss thinks I’m so great, why is my rating average?” That’s what stack ranking gets you. This review probably upset you, and now you’re contemplating your options. Not a great outcome for you or the company.
Stack ranking also stifles the desire of your developers to try new things, take on new roles with more responsibility, and take risks to grow their careers. This is because a 1 or 2 player won’t want to take on the risk of joining a new team, or getting a new boss, who might rank them as a 3 or lower compared to their more seasoned colleagues. Indeed, the smart play is to stay right where they are, and reap the benefits of being on the good end of this ridiculous bell curve.
My biggest concern with stack ranking is the fact that compensation is relative. Your assessed performance depends entirely upon the performance of your peers, as subjectively assessed by your manager. You might have been a 1 if it weren’t for that person who happened to claim it. Now the best you can be is a 2. But if they didn’t work there, perhaps you’d be a 1. Doesn’t seem fair (or even rational), does it?
My Personal Experience With Stack Ranking
I have had a few jobs in the past that employed stack ranking. At one of them, developers picked 3 projects to be assessed on, and then both they and their manager ranked their performance on the projects from 1 to 5. One of the projects that I picked was something that I had built from scratch with a team of 4 people. The thing we built had made the company millions of dollars that year, and I was the lead on it. Naturally, I gave myself a 1 on it. My manager gave me a 3.
I asked him how I could possibly be average at the thing which I created, was the most experienced with at the company, and which had led to millions in additional revenue. His reply was that I was awesome and not to worry too much about the grade. It was very confusing; what he said didn’t match what he wrote.
The review continued, and I ended up being given a 3 out of 5. I got a small raise. This was all conveyed to me as my boss happily told me that I was awesome, to keep up the great work, and that to keep it between me and him but I got the biggest raise on the team.
The idea of having the biggest raise made me feel less wronged… Right up until I found out that it was a lie. My team and I were at lunch a few days later when one person bragged that he got the biggest raise on the team. Another immediately said “what? I was told that I did.” I began to laugh as I realized what my manager had done. He had told us all that we received the biggest raise, and to keep it to ourselves. Perhaps as damage control for the pain that the mediocre grades had inflicted, but unfortunately for him we talked to each other. The jig was up, and now most of us were madder than we would have been had he said nothing to us at all.
A side note: leaving that job was one of my favorite resignations. When I quit, my boss was distraught, but I said (paraphrased) “hey [boss], don’t worry about it! I’m a 3 out of 5, so you should have no issues hiring any other average developer to take up the work I was doing.” The look on his face told me all I needed to know: he had now realized for himself why stack ranking sucks.
How to Properly Review & Compensate Developers
The key to happy developers is fair compensation. Fair compensation is all about transparency. At Stack Overflow, we have a transparent system for assessing employee skills and compensation, which is lovingly called Be More Awesome. There is no magic in employee compensation here, and all developers know exactly what they’re getting paid, why, and what they could get paid in the future. There are no negotiations, no bell curves, and no quotas.
Be More Awesome (BMA) is pretty simple. It is meant to measure skills; we use performance as evidence of skill. A person may rate highly on their BMA for a skill, even if they haven’t used it in the previous year. There are 4 possible grades that can be awarded for each skill:
- B: Could be more awesome. This is a good thing to work on over the next year — and your manager will help. This can also be applied for new employees who haven’t been in the company long enough to demonstrate that they deserve a higher grade.
- A: Does as expected, at our high Stack standards. Completely, utterly able to accomplish what is needed.
- A+: Does more than your team expects, even at our high level. Exceptional and noticeable skills.
- A+++: Widely recognized level of amazingness. Does and teaches. When people think of this skill, they think of you (or would if they knew you). This will be rare, even on our amazing team.
You might notice that there is no grade below a B. We don’t have C’s or lower because we believe that everyone that works here is awesome. If one of our developers were doing C, D, or F level work, we would already be working closely with them to correct it – prior to reviews.
It’s also not uncommon for people who are earlier in their programming career to receive a lot a B’s. This doesn’t mean they’re doing poorly at all. It just means they’re closer to the beginning of their career than the middle and there’s a lot of opportunity for them to grow.
The actual skills that we assess each year change, but the 2016 BMA chart for developers currently looks like this:
There are descriptions that explain what each of these categories are, and they are available for all employees to review at any time.
Once a developer is assessed on a BMA, their letter grades get converted into a numeric score by using a formula that is also published internally for all developers to review. This formula outputs a numeric score between 0.00 and 5.99 (with 5.99 being the best grade), which is then rounded down to the nearest whole number. In short, a developer can receive a score of 0, 1, 2, 3, 4, or 5.
Next we assess the years of programming experience. This is a value that falls in a range from 0 to 25. Naturally, this goes up by 1 at every annual review.
The score and years of experience are then looked up on a chart that has years of experience on the X axis and score on the Y axis, and details salary amounts at each cell. It’s worth redundantly noting that this chart is published internally also and can be reviewed by all developers at any time. Unsurprisingly, the cell that your score and experience points to is exactly what you get paid.
Make Compensation Transparent
There are no secrets or magic in our compensation system. All aspects of it are published internally for all developers to review at any time. They also get input into the changes to the BMA skills each year, well in advance of their annual review. They know the formula that we use to calculate salary. Most importantly, their compensation doesn’t depend on the performance of anyone else. Everybody can be a 5 in our system and everybody can be a 0.
Above all else, our system is fair and evaluates individual performance, not team performance. If you want happy developers and low turnover, I highly encourage you to try adopting such a system yourself. If your company is unwilling to do so, perhaps evaluate why. Are there secrets and magic in the compensation system that you don’t want your employees to know about? Why do you value these hidden metrics? Do your employees feel valued?
A happy developer is a productive developer, and while a fair system does not allow you to easily control salary costs in terms of budget (because everybody can be a 5), it does help increase job satisfaction, lower turnover, and maintain a relationship of trust with managers. And as I’ve written about before, if you don’t have the trust of your employees, you will fail.
EDIT (7/27/2016): We have published a salary calculator based on our internally transparent compensation numbers! Take a look.
PS – hate stack ranking but love Stack Overflow? Come and work with us!
Follow David Haney on Twitter at @haneycodes
Almost exactly 1 month ago today I found myself on a video call with Joel Spolsky. It feels insane to write that, even now, as it was a banner moment in my career. For me it was the equivalent of meeting a movie star who I had idolized since I was old enough to know what movies were. There had always been this Joel Spolsky guy throughout my career that I regularly read about and whose opinions on software development agreed with mine, and suddenly I was talking with him face to face. It was awesome.
Reaching this conversation was not the easiest thing I’ve done in my life. It took a few weeks and in all honesty it was a bit trying to find time to have so many interviews. How many interviews, you ask? Prior to Joel I talked with 5 or 6 other amazing people (Marc Gravell and Nicholas Larsen included). Somehow I managed to impress each of them enough to reach the end boss: Joel Spolsky.
The conversation lasted about an hour. It felt like 5 minutes to me, probably because of the excitement. Joel and I discussed the pros and cons of various software methodologies, mistakes each of us had made in our careers, some of the challenges of Dache (my open source software), and a few other topics. Then he said something awesome: “We’d love for you to come and work with us at Stack Exchange!” So much adrenaline hit me at this moment that I could have lifted a car with my bare hands. It was surreal.
A few days from now I officially start working with Stack Exchange. I feel very fortunate and excited for the opportunity. So far the Stack Exchange team have proven themselves an insanely skilled and professional organization that treat employees as human beings instead of expendable resources. I’m already loving the culture and interactions with my coworkers.
IMPORTANT NOTES: First and foremost, the commentary here consists of my views alone and not those of Stack Exchange or any other entity. This post is merely to reflect upon the interview process and discuss the aspects and traits of my career and knowledge which I feel helped me get the job. This is not a tell-all or any sort of shortcut or easy way out. If you want a job at Stack Exchange, you will have to endure the same technical and soft skills challenges that I did – the details of which I will NOT be disclosing. 🙂
So, with that disclaimer out of the way, here are my thoughts on how I got a job at Stack Exchange, and how you can too:
Ego is the mind killer, so kill the ego. Most developers that I’ve met (including some prior versions of myself) have massive egos. Egos so big that the room can barely hold them. Egos that even put the illustrious Kanye West’s attitude to shame. This is natural given that we spend all day creating things from scratch (which is a god-like quality) that often generate significant revenue for companies. We start to feel very powerful and even fawned over. We learn the entirety of the software and hardware vertical of our current job’s domain, and then make a Superman-like flying leap to conclude that we know EVERYTHING about ALL software and hardware.
Thinking you know everything is the easiest way to suck as a programmer. If you believe that you know everything, you stop trying to learn new things (since you already know them, duh). So, while you’ve mastered ASP.NET MVC 3 at your current gig, 4 and 5 came out… the catch is that your company never upgraded because it’s too risky, and so you never learned them (or cared to). Now a year or two later you’re so far behind the current development stack that you can’t even see it with binoculars. And did I mention those little things called Ruby and PHP and even Java that you’ve never written a single line of? And how about MongoDB, Couchbase, Azure, EC2, and the literally thousands of other platforms and programming languages? I should hope that by now you realize that you know a little bit about a handful of languages and hardware configurations amidst a sea of thousands… By percentage, you’ve conquered maybe 0.1% of all that there is to know about development. So have I, and that’s OK.
Don’t be a rock star developer. This is something that I did for a few years and it only hurt my career. Many companies employ a strategy of intentionally furthering the developer ego in order to make them feel valuable (often without handing out appropriate compensation). Being a rock star sounds cool, but really it’s a nasty strategy that can cultivate incredibly destructive developer attitudes. Companies seek out and hire rock stars, and rock stars have a sense of entitlement. They develop huge egos and run their mouths at meetings, interrupting and talking over others. They seem to love circular logic (they’re right because you’re wrong because they’re right). They feel that all other team members exist simply to serve their every whim… and everyone loathes working with them.
The thing is – while you may actually be a 1 in 1 million bona fide rock star developer – nobody cares. Talk is cheap and in my experience people will say nearly anything and everything to portray an image of who they want you to believe they are. If you are really good at what you do, telling people doesn’t do anything other than make them despise you… Hearing about how amazing your proprietary code is gets annoying – especially when it’s the 5th time this week you’ve said it. A good developer doesn’t need to brag about how good they are: their work speaks louder than any boastful words could. People around them will naturally do the bragging for them. Hallway conversations to the tune of “wow, he’s really smart” or “she knocked that out in hours when we thought it’d take days” will be fostered, and that isn’t a bad thing. Let people talk about you all they’d like, but maintain a sense of humility and reality. You might be the best developer on your team or even at your company, but you are still a human being and this is still a job. Nobody has been hired to serve your ego (even if their job is to serve you). Being a good developer doesn’t make you better than anyone as a person; it just makes you successful in your career. Never lose sight of the fact that thousands of other developers are great at their jobs too. What separates you from the pack is being a great developer AND modest. It is a very rare combination in my experience, and the complete package that many companies are striving to hire. So, while it’s cool that you’re the very best developer that there ever was, stop believing your own hype and telling everyone who will listen. They don’t care, and you shouldn’t either.
Know that you know enough to know that you don’t know enough. Know what you do know, and know what you don’t know, and never be afraid to say “I don’t know” when it’s the truth. A developer who isn’t afraid to say “I don’t know” in front of a room full of people is a rare gem. By being honest you create trust and credibility. You also foster positive relationships with your peers and company. Nobody will remember that you’ve never heard of Angular.js or Couchbase, though they’ll always appreciate that you didn’t waste their time or money by pretending that you did. You can’t trust a developer who doesn’t know what they don’t know.
Know your data structures and algorithms. High level programming languages such as C# abstract so much away from the modern developer that many of us have no idea what’s actually happening “under the hood” when it executes. It’s cool that you can sling LINQ everywhere, but do you know the computational complexity of what you’ve done? Do you know what a hash table is and why it is useful? Could you sort a list of things efficiently? Can you think of a scenario where a stack is the best option? Note that you don’t need to memorize things like sorting algorithms (hell, I couldn’t if I tried), but a working knowledge of data structures such as trees, hash buckets, lists, queues, and stacks combined with the rudimentary knowledge of things like sorting, searching, and caching is a very valuable skillset. It’s the difference between a good programmer and a great one. Anyone can write C#, but only those who understand even the low level operations of each deliberate method call will write good, clean, efficient code. You owe yourself a fundamental understanding of how data structures like stacks and heaps work, as well as by-value vs by-reference memory addressing. These core concepts apply to ALL programming languages. Too many developers ignore the complexity of their algorithms and just call pre-made methods without understanding the implications. Educate yourself on data structures and algorithms and suddenly you’ll be ahead of the pack.
Know why your code works and why your code doesn’t work. Have you seen this image circulating on sites like Reddit?
Despite being funny, the popularity of this image pisses me off. It claims that the essence of programming is having no freaking clue why your code does or does not run. I feel that this is unacceptable. A great developer strives for the WHY in every single thing that they do, not just HOW to quick-fix it. Code doesn’t compile? WHY? Race condition across threads? WHY? In asking “why” you further your knowledge and expand your skillset with the functional, rational “how” which allows you to become a better programmer. Most great programmers don’t repeat the same mistakes over and over, though they of course make mistakes… They just make new and interesting ones!
I remember the days of slinging shoddy code and then copy-pasting lines from blogs and sites like Stack Overflow until my code seemed to work (though I wasn’t sure if or why it did). Those days are long behind me. When my code doesn’t compile, 99% of the time I immediately know how to fix the issue. When my code has a bug, I usually know exactly how to track it down and resolve it, and in doing so I often learn how to avoid it in the future. Having no idea why your code works is like being a lawyer who has no idea why their client is not guilty: fairly useless, overpaid, and an amusing spectacle at times. Make sure that you know why your code works and why it doesn’t. In my opinion this is a basic competency of being a professional developer. It’s OK to create bugs and make mistakes – it’s not OK to make the same mistakes repeatedly.
At this point I feel that I’ve done a reasonable job of representing my skillset and core competencies. These are the things I showed to the Stack Exchange team in my interviews. I didn’t necessarily have the exact answer (or even most efficient answer) to each of their technical questions, but I was modest and never afraid to ask for help or say “I don’t know” when I got stuck. My answers involved efficient data structures and algorithms, and I was able to explain why the data structure was the best choice in solving the problem. When I created bugs I was mostly able to identify them and indicate how to fix them. In doing all of this, I demonstrated competency and confidence as a developer and fortunately ended up with my dream job.