Hiring someone you can trust...
August 27, 2009 7:55 AM
Over the last few years a couple of partners and myself have been building a small business that tries to make money using computers to trade in the stock market. Technically, we do black-box prop trading. Its been an uphill climb these past few years, but we are now at the point where we are considering hiring someone. This person will be a programmer/developer that will help with existing projects and help us grow in new directions. We are currently faced with a big dilemma. Whomever we hire will have to be given full access and will be exposed to our trade secrets. This kind of business lends itself to the temptation of impropriety. This person could take what we have and either sell it or assuming they break the barrier to entry use it for themselves. They could probably do this without getting caught as well, with the effect being that our secrets lose their value.
We wouldn't mind hiring someone remote either. We have outsourced pieces of projects to various developers already. But these have been non-proprietary projects in the sense that they didn't contain specific trading information. This is our first foray into taking someone on that will have access. My question then is how do we minimize our risks when it comes to this hire? What recommendations, experience or thoughts do you have?
We wouldn't mind hiring someone remote either. We have outsourced pieces of projects to various developers already. But these have been non-proprietary projects in the sense that they didn't contain specific trading information. This is our first foray into taking someone on that will have access. My question then is how do we minimize our risks when it comes to this hire? What recommendations, experience or thoughts do you have?
You need a lawyer and a well-drafted NDA/Non-compete agreement. As a precursor to a dedicated employee, you might want to consider a consulting company; I used to work for one specializing in the financial markets (generally Excel/VBA development), and had several financial clients in hedge fund/investment banking field, some on long-term contract where I'd be on-site full-time for months at a time. Generally any of the consulting firms specializing in this field will have the proper legal documents and agreements in place with regards to non-disclosure of proprietary company information.
There's lots of expertise in this field (and hungry programmers) in the NYC metro area, so I don't expect you'll have difficulty finding someone. Good luck!
posted by reptile at 8:12 AM on August 27, 2009
There's lots of expertise in this field (and hungry programmers) in the NYC metro area, so I don't expect you'll have difficulty finding someone. Good luck!
posted by reptile at 8:12 AM on August 27, 2009
Ditto deadmessenger but from a team perspective, you need to make them feel like a part of the overall goal of the company and not "that developer". Trust is more than a signed piece of paper and it goes both ways.
Lawyer up and all that but also set up an environment where they truly wouldn't want to screw you over.
posted by like_neon at 8:13 AM on August 27, 2009
Lawyer up and all that but also set up an environment where they truly wouldn't want to screw you over.
posted by like_neon at 8:13 AM on August 27, 2009
You may need more than two attorneys, since you're dealing with algorithmic trading. Check with financial specialists or even datacenters for any agencies and trade associations which may help you before committing to hiring this employee.
posted by Smart Dalek at 8:14 AM on August 27, 2009
posted by Smart Dalek at 8:14 AM on August 27, 2009
Whomever we hire will have to be given full access and will be exposed to our trade secrets.
I don't think you designed your software architecture quite right, there.
I have worked at/for some paranoid financial software houses with proprietary secrets and/or code and/or data that were secured by using disconnected "development boxes". Multiple developers using strong version control / source management can work on independent parts of a large software system, each only requiring access to "their own" components. They only "see" output.
It requires a lot more infrastructure, with additional expensive engineering needed (especially after the fact) to make the necessary layers and connective tissues... especially to do things like joint builds and compiles, but it works in that it then requires a coordinated conspiracy (more than one of your developers would have to be in cahoots) to defeat.
I am told this is how joints like Apple and Microsoft manage the most precious parts of their code bases, but I don't have any experience with that. Maybe another MeFly can answer anonymously.
posted by rokusan at 8:19 AM on August 27, 2009
I don't think you designed your software architecture quite right, there.
I have worked at/for some paranoid financial software houses with proprietary secrets and/or code and/or data that were secured by using disconnected "development boxes". Multiple developers using strong version control / source management can work on independent parts of a large software system, each only requiring access to "their own" components. They only "see" output.
It requires a lot more infrastructure, with additional expensive engineering needed (especially after the fact) to make the necessary layers and connective tissues... especially to do things like joint builds and compiles, but it works in that it then requires a coordinated conspiracy (more than one of your developers would have to be in cahoots) to defeat.
I am told this is how joints like Apple and Microsoft manage the most precious parts of their code bases, but I don't have any experience with that. Maybe another MeFly can answer anonymously.
posted by rokusan at 8:19 AM on August 27, 2009
Lawyers will only help after the fact; someone walks with your models, sells them to another firm, you're damaged, perhaps potentially out of business so sure, sue away. Collect what you can.
But segregation is a much better approach, one I've used in the past.
I'm not sure exactly what type of modeling you're doing, but this is key to any type of complex financial modeling - analytics are useless without data.
If someone has full access to your model - and that's likely as modularisation, while attractive from a Software Engineering perspective imposes performance constraints and thus often isn't done on a desk - then you simply keep details regarding the data set's used to calibrate that model away from them.
Modeling is simple, calibration is a bitch. Especially so if the model incorporates multiple factors and if those factors aren't well behaved. Where you get the data from to calibrate is a driver of your models predictive power. Someone else would probably choose to calibrate differently, and then there goes the r squared.
When I was working for one of the credit ratings agencies we'd segregate our analytics this way, simply because our competitive advantage was data; we had so much more of it, history across credit & business cycles, dozens of factors, sliced and diced in so many ways that it didn't matter who had our models, without the data to calibrate the analytics their performance was suboptimal (we were looking at default probabilities and improving estimates of default by linking back to about two dozen factors, and not all publicly available).
Besides, how long will your competitive advantage hold? If you're deploying your first gen model, I'm sure you've got ideas for a second gen that will increase your r squared, your predictive power. Once the competition starts to sleuth out what you're up to you're gonna have to move on to more advanced analytics anyhow.
Don't waste time and money with the lawyers.
posted by Mutant at 8:23 AM on August 27, 2009
But segregation is a much better approach, one I've used in the past.
I'm not sure exactly what type of modeling you're doing, but this is key to any type of complex financial modeling - analytics are useless without data.
If someone has full access to your model - and that's likely as modularisation, while attractive from a Software Engineering perspective imposes performance constraints and thus often isn't done on a desk - then you simply keep details regarding the data set's used to calibrate that model away from them.
Modeling is simple, calibration is a bitch. Especially so if the model incorporates multiple factors and if those factors aren't well behaved. Where you get the data from to calibrate is a driver of your models predictive power. Someone else would probably choose to calibrate differently, and then there goes the r squared.
When I was working for one of the credit ratings agencies we'd segregate our analytics this way, simply because our competitive advantage was data; we had so much more of it, history across credit & business cycles, dozens of factors, sliced and diced in so many ways that it didn't matter who had our models, without the data to calibrate the analytics their performance was suboptimal (we were looking at default probabilities and improving estimates of default by linking back to about two dozen factors, and not all publicly available).
Besides, how long will your competitive advantage hold? If you're deploying your first gen model, I'm sure you've got ideas for a second gen that will increase your r squared, your predictive power. Once the competition starts to sleuth out what you're up to you're gonna have to move on to more advanced analytics anyhow.
Don't waste time and money with the lawyers.
posted by Mutant at 8:23 AM on August 27, 2009
I agree that signing them on NDAs and related documents is a prerequisite. But it is really not a way to make sure you can trust them as they are only enforceable if you actually catch them and can prove the act or infringement. Non-compete agreements are also not particularly useful. In any case legal precautions are necessary but but don't really help in finding someone who will likely not transgress to begin with.
posted by blueyellow at 8:35 AM on August 27, 2009
posted by blueyellow at 8:35 AM on August 27, 2009
Give them an ownership stake.
Hire someone with no interest in the stock market.
Hire someone you know/trust.
Also:
Lawyer it up.
posted by blue_beetle at 8:46 AM on August 27, 2009
Hire someone with no interest in the stock market.
Hire someone you know/trust.
Also:
Lawyer it up.
posted by blue_beetle at 8:46 AM on August 27, 2009
You are correct that an NDA and other contractual provisions will only help you after the cat is out of the bag. If the person you hire is 'judgement-proof' (in the sense of not having many assets to go after), the fact that you can sue them into the ground is going to be small consolation once they've misappropriated your secrets.
I think the key is making sure that they don't want to steal your stuff. You need to make sure that they feel like they're part of the team, and that their success is premised on your success as a company, and not that they're just being used as disposable manpower or that they're a mercenary.
If you can, I might think about hiring someone who's a solid developer but comes from outside the finance field. That might make them less interested in taking your idea and using it themselves. If you need someone with a finance IT background then this may not be possible, but if you don't specifically need those finance skills, someone who doesn't really care to understand the inner workings of your trading system might be better.
But, bottom line, you need to compensate this person very well and give them some sort of ownership stake. If they're going to have access to the crown jewels, they need to feel like they're getting a better deal working for you than they'd ever get by cutting and running. You also need to really build a good personal relationship with them; make sure that they're included and feel like they're part of a team, and don't turn into the maligned, bitter "IT guy" who does all the work but watches the suits take the glory. Relatively inexpensive perks like free meals/sodas or not being a total dick about expense reimbursements and vacation/sick time go a long way, too.
The worst thing you could do is be all stick and no carrot. That just creates an adversarial relationship, which is the last thing you want. The law limits what you can do to your employee—you can't have them hunted down and killed—so there's a limit to how much fear you can put into them. They have to want to not screw you.
I'd look for someone relatively young, un-cynical, without a mercenary attitude, who's looking to be part of a team and not just for a 9-5 and a paycheck. Don't hire anyone if you get even the tiniest bad vibe; if either partner wants to veto a candidate, let them do it and don't question.
posted by Kadin2048 at 9:28 AM on August 27, 2009
I think the key is making sure that they don't want to steal your stuff. You need to make sure that they feel like they're part of the team, and that their success is premised on your success as a company, and not that they're just being used as disposable manpower or that they're a mercenary.
If you can, I might think about hiring someone who's a solid developer but comes from outside the finance field. That might make them less interested in taking your idea and using it themselves. If you need someone with a finance IT background then this may not be possible, but if you don't specifically need those finance skills, someone who doesn't really care to understand the inner workings of your trading system might be better.
But, bottom line, you need to compensate this person very well and give them some sort of ownership stake. If they're going to have access to the crown jewels, they need to feel like they're getting a better deal working for you than they'd ever get by cutting and running. You also need to really build a good personal relationship with them; make sure that they're included and feel like they're part of a team, and don't turn into the maligned, bitter "IT guy" who does all the work but watches the suits take the glory. Relatively inexpensive perks like free meals/sodas or not being a total dick about expense reimbursements and vacation/sick time go a long way, too.
The worst thing you could do is be all stick and no carrot. That just creates an adversarial relationship, which is the last thing you want. The law limits what you can do to your employee—you can't have them hunted down and killed—so there's a limit to how much fear you can put into them. They have to want to not screw you.
I'd look for someone relatively young, un-cynical, without a mercenary attitude, who's looking to be part of a team and not just for a 9-5 and a paycheck. Don't hire anyone if you get even the tiniest bad vibe; if either partner wants to veto a candidate, let them do it and don't question.
posted by Kadin2048 at 9:28 AM on August 27, 2009
Consider adding a "liquidated damages" clause to the employment contract that spells out the $$$ value of the secrets. This makes what the employee has to risk from disclosure more concrete and may make it easier to enforce (check with your atty). However, this may scare off good candidates.
posted by cosmac at 11:48 AM on August 27, 2009
posted by cosmac at 11:48 AM on August 27, 2009
> Multiple developers using strong version control / source management can work on independent parts of a large software system, each only requiring access to "their own" components. They only "see" output.
> But segregation is a much better approach, one I've used in the past.
Introducing modularization to something that wasn't modularized in the first place would be expensive, time-consuming, and messy... but losing control of your product is potentially far worse.
It seems like you and your partners need to do a crash program of breaking the system into modules; once that's safely done, then you can farm out the now-secured black boxes to others.
So, yeah, lawyer up if you want-- but realistically, it's probably at least as important to get the structure right; to break your system down and put some walls between its parts.
posted by darth_tedious at 12:49 PM on August 27, 2009
> But segregation is a much better approach, one I've used in the past.
Introducing modularization to something that wasn't modularized in the first place would be expensive, time-consuming, and messy... but losing control of your product is potentially far worse.
It seems like you and your partners need to do a crash program of breaking the system into modules; once that's safely done, then you can farm out the now-secured black boxes to others.
So, yeah, lawyer up if you want-- but realistically, it's probably at least as important to get the structure right; to break your system down and put some walls between its parts.
posted by darth_tedious at 12:49 PM on August 27, 2009
This thread is closed to new comments.
Bottom line is that this is NOT a DIY situation. This is time to shell out for two good attorneys - one experienced in intellectual property law, and another experienced in employment law.
posted by deadmessenger at 8:08 AM on August 27, 2009