6 ms·

Unfortunately many employment agreements prohibit side projects.

by baus 11y ago

eldavido 11y ago
My experience (SF) is more like "don't ask, don't tell" If you do something blatantly competitive, e.g. launch a product that competes with your employer's product, try to use employer's customer relationships, you'll get sued. If you do something outright illegal, like steal IP, you're probably going to jail. But most managers I've worked for don't really care if it doesn't affect your day job, and in fact, might quietly encourage it as it lets you scout the new hotness and then bring it back to your day job, if it's good. I suspect the norms around this depend highly on where you work, but I think this attitude is pretty common in SF tech.
- nostrademons 11y ago
  Your manager probably doesn't care as long as you don't rub it in his face. The company only cares if you're becoming a direct competitor or try to get it to buy back IP that was created on company time anyway. However, potential investors care a lot - this sort of thing shows up in due diligence, and it's negotiating leverage that can be used against you in any potential lawsuit or acquisition. It's fine to do side projects anytime you want - it's not like the company has the ability to restrict what you can do in your free time. But if it looks like the side project may turn into something more than a side project, it may be a good idea to quit your job, throw away the code, and rewrite everything from scratch.
  - outworlder 11y ago
    > this sort of thing shows up in due diligence Everyone throws around the phrase "due diligence", but what exactly does that mean? How is this kind of thing showing up in "due diligence", assuming a side project could be at any stage? Do they interview employees? Go through their social accounts? Github repositories? Lurk at IRC chat rooms?
    - nostrademons 11y ago
      My understanding of the process (I've never been through it myself, but my wife does it as part of her job) is that the acquirer or institutional investor will request a pile of documents, including: audited financials for the company; the cap table, and any investment documents; tax returns; company bank statements & other financials; all agreements that employees have signed with the company; all agreements with partners & customers; commit logs for the repository, and oftentimes samples of actual source code; etc. Then a team of people - usually including financiers, lawyers, accountants, and occasionally domain experts like programmers for a software startup or biologists for a biotech company - will go over that with a fine-toothed comb, looking for inconsistencies. If the documentation is inconsistent or missing, you will be grilled on it. For things like missing partner or employee agreements, you will have to go back to those people and get them to sign the appropriate agreements. For audited financials, if there is an inconsistency you may have to restate earnings. If your commit logs show that some of your code was written by a person who was not an employee of the company at the time of the commit, you will be asked to produce a license or otherwise explain how you can legally use that code. If it turns out that they were an employee of some other company at the time, with IP assignment to their employer, then you'll have to go to that company and get them to sign a release or license agreement to use that code, and if they won't do that, it may torpedo the deal.
      - x0x0 11y ago
        I've done it recently as an employee of an acquired company. In addition, acquirers can (and do!) interview the developers as well. We got questions that approximated how one would take git and turn that into the running system. The acquirer also crawled through all our software license agreements; wee discovered we weren't licensed quite correctly for a commercial db, so had to rip it out in a real rush. For each customer agreement, it has to be either assignable, or you will have to go to that customer and get them to agree to make it assignable. Each customer that doesn't so agree, or each customer that is slow to respond, will have to be individually negotiated with the acquirer in the period before the deal closes. I'd imagine that one of the big risks acquirers of small companies care about is the company somehow fucked up and doesn't own, or there is a colorable claim they don't own, their source code. Having an overlap of git commits with your previous employer could cause you a lot of heartburn at minimum. And good luck getting a timely response from your previous employer that they don't own that code. Your previous employer, even if they have no intentions of being dicks, simply have no incentive to sign (and definitely no incentive to promptly sign) such an agreement.
  - x0x0 11y ago
    In CA, state law offers a bit of protection (on your own time, no company equipment, unrelated to company business) but still, following nostrademons' advice is probably best. I know of two ycombinator startups sued by founders' former employers just off the top of my head: adgrok by murthy nukala, who appears to be a complete dick; shred video by smule.
  - zo1 11y ago
    >"But if it looks like the side project may turn into something more than a side project, it may be a good idea to quit your job, throw away the code, and rewrite everything from scratch." Or, you could perhaps ask the people in charge to (on paper) waive certain provisions in your non-compete, or IP-sections in your work contract. They are human, and if it doesn't work, you would have learnt a great deal about your current employer just from trying.
pmarreck 11y ago
Because they see a side project as an antagonistic competitor to your paid time instead of something that would make you more valuable as an employee who enjoys intrinsically-motivated creation. This is a side effect of the "always-assumed-on-duty" nature of todays' white-collar workers.
TaylorGood 11y ago
Even Head of HR at my current company referenced his consulting practice at our recent Town hall meeting. Found that interesting. The rules for us: don't build in the same space.
beambot 11y ago
This is very true. Even in locales where it's nominally permitted (eg. In California w/ CA Labor Code 2870), there can be pretty severe cultural issues that deter or prevent side projects -- even at companies that are supposedly friendly to the concept. (Happened to me. I won't elaborate any further.)

Unfortunately many employment agreements prohibit side projects.

by baus 11y ago

Unfortunately many employment agreements prohibit side projects.

My experience (SF) is more like "don't ask, don't tell" If you do something blatantly competitive, e.g. launch a product that competes with your employer's product, try to use employer's customer relationships, you'll get sued. If you do something outright illegal, like steal IP, you're probably going to jail. But most managers I've worked for don't really care if it doesn't affect your day job, and in fact, might quietly encourage it as it lets you scout the new hotness and then bring it back to your day job, if it's good. I suspect the norms around this depend highly on where you work, but I think this attitude is pretty common in SF tech.

nostrademons 11y ago
Your manager probably doesn't care as long as you don't rub it in his face. The company only cares if you're becoming a direct competitor or try to get it to buy back IP that was created on company time anyway. However, potential investors care a lot - this sort of thing shows up in due diligence, and it's negotiating leverage that can be used against you in any potential lawsuit or acquisition. It's fine to do side projects anytime you want - it's not like the company has the ability to restrict what you can do in your free time. But if it looks like the side project may turn into something more than a side project, it may be a good idea to quit your job, throw away the code, and rewrite everything from scratch.
- outworlder 11y ago
  > this sort of thing shows up in due diligence Everyone throws around the phrase "due diligence", but what exactly does that mean? How is this kind of thing showing up in "due diligence", assuming a side project could be at any stage? Do they interview employees? Go through their social accounts? Github repositories? Lurk at IRC chat rooms?
  - nostrademons 11y ago
    My understanding of the process (I've never been through it myself, but my wife does it as part of her job) is that the acquirer or institutional investor will request a pile of documents, including: audited financials for the company; the cap table, and any investment documents; tax returns; company bank statements & other financials; all agreements that employees have signed with the company; all agreements with partners & customers; commit logs for the repository, and oftentimes samples of actual source code; etc. Then a team of people - usually including financiers, lawyers, accountants, and occasionally domain experts like programmers for a software startup or biologists for a biotech company - will go over that with a fine-toothed comb, looking for inconsistencies. If the documentation is inconsistent or missing, you will be grilled on it. For things like missing partner or employee agreements, you will have to go back to those people and get them to sign the appropriate agreements. For audited financials, if there is an inconsistency you may have to restate earnings. If your commit logs show that some of your code was written by a person who was not an employee of the company at the time of the commit, you will be asked to produce a license or otherwise explain how you can legally use that code. If it turns out that they were an employee of some other company at the time, with IP assignment to their employer, then you'll have to go to that company and get them to sign a release or license agreement to use that code, and if they won't do that, it may torpedo the deal.
    - x0x0 11y ago
      I've done it recently as an employee of an acquired company. In addition, acquirers can (and do!) interview the developers as well. We got questions that approximated how one would take git and turn that into the running system. The acquirer also crawled through all our software license agreements; wee discovered we weren't licensed quite correctly for a commercial db, so had to rip it out in a real rush. For each customer agreement, it has to be either assignable, or you will have to go to that customer and get them to agree to make it assignable. Each customer that doesn't so agree, or each customer that is slow to respond, will have to be individually negotiated with the acquirer in the period before the deal closes. I'd imagine that one of the big risks acquirers of small companies care about is the company somehow fucked up and doesn't own, or there is a colorable claim they don't own, their source code. Having an overlap of git commits with your previous employer could cause you a lot of heartburn at minimum. And good luck getting a timely response from your previous employer that they don't own that code. Your previous employer, even if they have no intentions of being dicks, simply have no incentive to sign (and definitely no incentive to promptly sign) such an agreement.
- x0x0 11y ago
  In CA, state law offers a bit of protection (on your own time, no company equipment, unrelated to company business) but still, following nostrademons' advice is probably best. I know of two ycombinator startups sued by founders' former employers just off the top of my head: adgrok by murthy nukala, who appears to be a complete dick; shred video by smule.
- zo1 11y ago
  >"But if it looks like the side project may turn into something more than a side project, it may be a good idea to quit your job, throw away the code, and rewrite everything from scratch." Or, you could perhaps ask the people in charge to (on paper) waive certain provisions in your non-compete, or IP-sections in your work contract. They are human, and if it doesn't work, you would have learnt a great deal about your current employer just from trying.

pmarreck 11y ago

Because they see a side project as an antagonistic competitor to your paid time instead of something that would make you more valuable as an employee who enjoys intrinsically-motivated creation. This is a side effect of the "always-assumed-on-duty" nature of todays' white-collar workers.

TaylorGood 11y ago

Even Head of HR at my current company referenced his consulting practice at our recent Town hall meeting. Found that interesting. The rules for us: don't build in the same space.

beambot 11y ago

This is very true. Even in locales where it's nominally permitted (eg. In California w/ CA Labor Code 2870), there can be pretty severe cultural issues that deter or prevent side projects -- even at companies that are supposedly friendly to the concept. (Happened to me. I won't elaborate any further.)