Don’t Sign That Contract! Developer Job Deal Breakers
Before I get into this, a warning: I am not a lawyer. I make software. I’m not qualified to give proper legal advice. Also keep in mind that I only have experience with employers in the United States. Laws and policies vary a lot from one country to the next, and even between one state and another.
If you have any doubts about a contract you’re being asked to sign, you should consult with somebody qualified, with experience in your region.
I frequently give career advice to developers, and once in a while I hear back from them that they could not possibly follow my advice because it would violate their employment agreement.
The problem is not the advice I’m giving. The problem is that some employment agreements are not in your best interest, and should not be signed as written.
The good news is that employment agreements are not set in stone. All legal agreements should be considered open to negotiation until they’re signed, and even after they’re signed, if you feel you have the leverage to renegotiate.
Many developers don’t seem to understand how much leverage they have. Your skills are valuable, and it’s very expensive to recruit good talent. Faced with a choice between amending an agreement and going back to the talent search, most employers would prefer to negotiate in order to hire you.
Don’t take the first draconian contract that comes your way. There is a standing demand for more than 100k JavaScript developers just in the United States.
You have choices. You have leverage.
There are a few clauses you really need to understand, because they could have a big impact on your career and your future possibilities.
Even if you don’t mind all the clauses in an employment contract, it could still be useful to test the flexibility of your employer-to-be. An employer who is unwilling to negotiate may also more likely to be litigious and aggressive about protecting the employer over being flexible with the employee.
You don’t want to work for a litigious, inflexible employer.
We’ll start with the obvious.
The Non Compete Clause
A typical non compete clause will look something like this:
Employee agrees, for a period of _<n>_ months/years after employment with Employer, not to work __<on a competing product>__.
For employers, it’s often better if the non-compete clause is broad. For you, it’s better if the non-compete clause is very specific, or if it doesn’t exist at all. My second development job had an interesting non-compete clause. I don’t have the contract anymore, but I remember being shocked by the audacity of it. It looked something like this:
Employee agrees, for a period of 2 years after employment with Employer, not to work in a role related to software development, database administration, web services, or web hosting.
Basically, they wanted me to work in a completely unrelated job role and field for two years following my employment. First of all, I sincerely doubt that the contract as stated would be enforceable (in many places, there are laws established to protect employees against anti-poaching agreements), but I explained that I definitely would not sign a contract asking me not to code for 2 years, no matter how good their intentions were. I struck out the clause, got it initialed by the hiring manager, and took the job.
The employer is protecting themselves from the doctrine of inevitable disclosure. It goes something like this:
No matter how good your intentions are, it is impossible to compartmentalize the knowledge and experience you have gained from prior employment.
As such, you will inevitably disclose information if you do similar work for a new employer.
In other words, work experience makes you more valuable to a new employer. No kidding?
What this clause attempts to sweep under the rug is that there is a big difference between general skills & knowledge and protection-worthy intellectual property. If you are learning about proprietary IP, of course you shouldn’t share that proprietary IP with a new employer.
It is reasonable for a company to ask you not to work on a directly competing product for a reasonable period of time (maybe up to a year, definitely less than 3).
What does directly competing mean?
- The two products are essentially the same, or very similar.
- The new role is nearly identical to the previous role.
- The trade secrets are valuable to both employers.
If the employer insists on a non-compete agreement, you should insist that these points are explicitly spelled out, rather than left vague.
In other words, if they want the clause, insist that they spell out:
- The specific job role you’ll perform
- The specific product category you’ll work on
If the employer won’t budge on their broad definition of “competition” or an overly aggressive cooling off period, move on.
Bullet dodged.
IP Ownership & Work for Hire
In the United States, by default, you own the intellectual property you produce. When you accept a role with a company, you usually accept a “work for hire” agreement. That means that the employer owns whatever work you produce for them.
The problem is that “for them” is a bit fuzzy, and unlike “work for hire”, “for them” is definitely not a legally defined phrase. What the law defines is an employer/employee relationship, and there are various factors that influence whether or not you’re considered a legal employee for the purpose of determining IP ownership.
- Who controls the work? Does the employer determine the requirements, specifications, the means of production? Does the employer supply equipment or facilities?
- Who controls the worker (employee)? Working hours, work location, method of payment, etc…
- Employer operation: Do they withhold taxes for the work? Is the work considered part of your regular job?
These things can influence whether or not you have control over code you write — in some cases, even if you write that code on your own time.
If you want to be able to write code that you own for side projects or open source (and I believe every developer should), you need to make sure that the contract does not state that the employer owns code you create during your time off.
Even without that clause, the employer could still end up with control over your IP.
Make sure your side projects are:
- Produced on your own equipment (not the company laptop).
- Produced away from the company facilities (not in the company office).
- In no way or part paid for by your employer (do it on your own time & your own dime).
- Not in competition with your employer.
- Does not use unauthorized code owned by your employer (OSS code is okay).
Stock Options
At a typical startup, founders are under pressure to keep the burn rate low, which means that many tech startups pay below market and try to entice you with generous stock options.
If you’re banking on compensation, it’s a much smaller gamble to go with a well established company. Matching 401k contributions and a generous employee stock plan are much less risky, and you’ll typically have a much more realistic idea of the value of the stock compensation.
You should also be aware that startup stock options are not the same as owning stock. You have the option of buying stock at some agreed upon price after it vests (usually a little at a time over a period of 4 years, beginning with 25% after the first year). To understand how much you’ll need to pay to exercise your options, look for the exercise price or strike price in your employment offer and multiply that by the number of shares in the offer.
That’s how much money you’ll need to have saved in order to make your options worth anything.
In other words, a startup asking you to take below market pay in exchange for better stock options is really asking you to take below market pay in exchange for what will likely be worth $0, and even if it does become worth something someday, you’ll still need to have enough money to purchase your options. There are sometimes financing options available for that, but there is no guarantee you’ll be able to find financing to buy all your stock options.
My recommendation: Consider the value of a pre-IPO company’s stock options to be $0. Find a well funded company willing to pay market rates. The often-recycled founder line is that they want somebody who’s not in it for the money. My answer to that is you want to work for a company who values developers and takes the interests of their employees seriously.
My exception to this rule is if you are a cofounder with real ownership equity in the business. In other words, if you’ve built much of the product yourself, and you have a job title like CTO, and you really feel like the company is your baby. Then it’s OK to take a $50k salary while you turn nothing into something.
To founders: Don’t buy the BS line. Employees want to feel valued and appreciated. It’s not about the money. It’s about showing loyalty to your employees before you ask it of them. If you want them to give you 100%, you need to start by giving them 110%.
It’s never a good idea to pay regular employees below market rates.
To find out what the market rates are, take a look at Indeed.com’s salary search. To find out average salaries for individual companies, take a look at GlassDoor.
Eric Elliott is the author of “Programming JavaScript Applications” (O’Reilly), and “Learn JavaScript Universal App Development with Node, ES6, & React”. He has contributed to software experiences for Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC, and top recording artists including Usher, Frank Ocean, Metallica, and many more.
He spends most of his time in the San Francisco Bay Area with the most beautiful woman in the world.
