According to Stack Overflow's 2020 survey, which covers global developer salaries, an Engineering Manager makes $92K, while the lowest-paid developer makes $43K. For the sake of simplicity, let's say that your goal is to negotiate for doubling your pay.
Be a 10x Developer
To have any hope of negotiating for double your salary, being recognized by management as a top-performer by a wide margin is a minimum requirement. Such recognition gives you leverage in a negotiation, as no manager wants to lose their top performer. In software development, we use the term "10x developer" to describe a top performer who greatly out-performs their peers.
The term "10x developer" became a dirty word among software developers who came to associate it with unsustainable practices, unrealistic expectations, and elitism. However, when looked at objectively, a 10x developer is nothing more than someone who produces 10 times the work of their peers. Therefore, the term "10x developer" relates to comparative productivity, not innate skill or ability.
One of the most common ways a developer earns the label of 10x is when they are an expert on a team of novices. Experts are masters of productivity, where beginners can barely get anything done at all. In situations such as this, there is nothing insidious or elitist at play, just a natural consequence of experience.
To achieve 10-times the productivity of your peers, you must produce 10-times the amount of work. Opinions vary on what constitutes "work," but an expert software developer should define "working" as follows:
Working is contributing deployable code that directly impacts achieving business outcomes.
This definition can be expanded as:
Contributing Code: Meaning only time spent coding is productive, with all other time being a temporary halt to productivity.
Deployable: Meaning the code has met all business requirements, has passed all code reviews, has no bugs, and is ready to be delivered to customers.
Direct impact: Meaning that the work does not merely enable other work, as does refactoring, bug fixing, or other maintenance tasks. While each is necessary, they tend to impede current productivity even though they enable future productivity.
Achieving: Meaning that the work is universally recognized as being done by everyone and is currently being used in production.
Business Outcomes: Meaning that business outcomes are the only outcomes that drive business productivity.
Now consider the following facts of the software development industry:
Most business managers would agree with this definition of "working," as that is what they are paying you to do. Therefore, they like to see people "working" and will tend to reward the hardest workers.
Most software developers would agree they spend little time "working" and are instead flooded with distractions. Therefore, to achieve 10-times the productivity of your peers, the first step is to eliminate distractions and focus exclusively on "working."
If your peers are hardly ever working, but you are working all the time, achieving 10-times their productivity is practically guaranteed. Whether this situation is fair, however, is another matter entirely. Still, it plays to your favour in gaining leverage in a salary negotiation.
Learn how to negotiate
While this might seem obvious, the fact is few people dedicate themselves to actually learning how to negotiate. They instead believe that only a lucky few are born negotiators and that everyone else has to take the first offer.
Negotiation is a skill that can be learned by educating yourself and honing your negotiating skills through consistent practice. However, the target of doubling your salary is going to require advanced negotiation skills that far surpass what is needed for typical salary negotiation.
Here are two expert negotiators whose books I recommend to make sure you have a rock-solid educational foundation in negotiation:
Herb Cohen, author of "Negotiate This!" You can also watch an old video of one of Herb's comprehensive lectures.
Chris Voss, author of "Never Split the Difference." You can watch his TED talk to get a short overview of his approach.
Cohen and Voss offer different perspectives on negotiation, which reflect the difference in how they each learned to negotiate: the former in business, the latter in law enforcement. In recommending these books over the years, I have found people with a high "emotional IQ" prefer Cohen's approach, while those who are highly analytical prefer Voss's. I believe both are perfectly valid and complementary, and therefore recommend reading both.
As with most things in life, education without practice holds little value in developing a skill, and negotiation is no different. Fortunately, a software developer has no end of opportunity to practice negotiation in every facet of their job.
Negotiate with your development team on estimates.
Negotiate with your peers on code reviews.
Negotiate with project managers on deadlines.
Negotiate with product managers on feature requirements.
Negotiate with testers on bug reports (only if appropriate).
Negotiate with architects on technology adoption.
Negotiate with managers on meeting necessity and frequency.
Negotiate with DevOps on tooling and deployment procedures.
Negotiate with office admin for better snacks in the break-room.
Once you realize every "No - that will never happen" is an opening to negotiate, you should be ready to approach doubling your salary. Suffice to say, expect to be told, "No - that will never happen" several times until you get the pay you're after.
Develop a negotiation strategy
Negotiating to double your salary will be a battle, and every battle needs a strategy. That is not to say that you should make a plan, as plans tend to be too rigid to adapt to a negotiation's fluidity. Consider the following famous quotes:
"Plans are useless, but planning is indispensable." - Dwight Eisenhower.
"No plan every ever survives contact with the enemy" - Helmuth von Moltke.
"Everyone has a plan until they get punched in the mouth" - Mike Tyson.
These all warn against creating a firm plan. Still, a flexible strategy thought-up in advance will allow you to adjust your approach quickly in the middle of a tense negotiation.
A flexible negotiation strategy should have answers to at least the following questions:
What is your win-condition?
When will you begin the negotiation?
How will you initiate the negotiation?
What is your timeline?
What is your justification for deserving double your current pay?
What are do you have to offer in exchange for double your salary?
Will you walk away if you don't get what you want?
If I were developing a general negotiation strategy for myself, here is how I might answer these questions:
Win-condition: At least double my salary or an equivalent compensation package that includes equity, bonuses, and perks such as extra vacation days.
When to begin: Shortly after a major delivery of a mission-critical feature that is universally recognized as having immense value to the business. After getting recognized by the CTO for being a top performer, I will invite them to lunch.
How to initiate: At a no-agenda "catch up" 1-on-1 lunch with the CTO where we talk about the company's vision and how I might help achieve that vision.
Timeline: I'll keep going until I get what I'm after, no matter how long it takes.
Justification: I am a strategically important resource to the business that is a bargain at twice the price.
What I can exchange: (This is tricky out of context, but whatever it is, it would be what they value the most that would cost me the least to give.)
Will I walk away: Only if I have a better offer at another company.
That said, if some twitch of body language, change in inflexion, or thinly veiled threat were to tell me I was on the wrong track, I might change any of these answers on the fly. Negotiation is a game, and if I am losing, I will change something to increase my odds of winning.
Go for it
Wait for your moment and execute your strategy. Nothing ventured, nothing gained. What have you got to lose? A company that won't pay you what you want? You already have that!
In all seriousness, while it may seem completely counter-intuitive: have fun. If you are tense and totally obsessed with winning, you will be a poor negotiator. It is always easier to negotiate for someone else than it is for yourself, so think of yourself as a dispassionate 3rd party not tied to a specific outcome. If you win, you win. If you lose, you lose. At least you can look yourself in the mirror and know you had the self-confidence to advocate for yourself.
Ultimately, it's only money, and money comes, and money goes. If you fail miserably, you probably learned valuable lessons that set you up for future success. If you get what you're after, great, but remember that money can't buy happiness.
...
Neil writes a lot more about the softer side of software development over at neilonsoftware.com. Check it out!
