Slashdot Mirror
Security Plans for When Your Senior Developer Leaves?
An anonymous reader asks: "Our CTO, responsible for all hardware and networking setup, who also coincidentally happens to be our senior (and only) developer, has just resigned to go work for the competition. We are not a software company, but he's written proprietary code that we use on a daily basis to work. What interim measures should we be taking to ensure a smooth transition to the next person hired to take over? What can we do about security, since this person designed and implemented all current security procedures? What about ensuring that we have all the intellectual property to which we're entitled? As one co-worker put it: 'His resignation was a surprise to us, but it definitely wasn't a surprise to him.' If he wanted to leave some hard-to-find malicious timed-release back-door-opening code running, it's certainly within his means. We don't expect any malicious action, and can rely on a reasonable level of co-operation and documentation before he goes, but I want to get a sense of what others have done in this situation."
We don't expect any malicious action
Well then you shouldn't have made life so difficult for your CTO. I mean, everyone has their price, PAY IT!
Oh wait, you want team players. Well then who's idea was it to cut his pay, deny funding to the latest project, or take photos at his last "business trip". Certainly not his...
Antiquated competence won't be a job skill forever.
I'm guessing you've already hired someone to take over at this point. I say this because hopefully anything technical that may need to be done to insure a smooth transition won't be performed by your former CTO. This also leads to a less hostile work environment where the CTO doesn't feel you're worried about him doing something damaging.
Assuming that you already have some sort of data backup performed on a semi-regular basis, my first step would be to keep a static copy somewhere in storage. A snapshot like that might prove useful later should something be 'waiting' for him to leave.
As for the proprietary code, if you haven't already worked out the legal ownership issues involved with it, you're a bit late. The less you have in writing already regarding that, the more you should be considering a replacement setup. At the least, you should be requesting documentation for everything that doesn't have it already.
We make DSL equipment. Shortly after a layoff last year, all of our test stations at several contract manufacturers stopped working almost simultaneously. It seems one of our test engineers had programmed them to phone home to his PC at headquarters to make sure everything was ok. Thank goodness it wasn't one of the linecard software guys or we could have had thousands of lines out of service.
Trouble? Yes, we've had our Phil.
Another suggestion - depends on how important your uptime is, but ... as you walk him out the building the last time hand him his bonus - if the systems maintain their existing uptime percentages (nobody is 100% uptime, but pretty close) for one year - with his occasional cooperation if necessary (assistance via phone or VPN access or whatever) - then give him his usual bonus for that year, or some arbitary amount of cash ($5,000? $10,000?)
Consider it a very important support contract with a limited lifespan (a year should suffice.) Unless he is really, really pissed or his new company is paying him double what he was making with your company - he will go for it and be a pretty eager helper when the chips are down.
If he declines that offer you guys are hosed, because he declined it for a reason.
Glonoinha the MebiByte Slayer
Just follow the termination procedure. You do have one, right?
This isn't a termination, of course, but should be handled the same way.
A contract manager stole her NDA/NC out of a cabinet she had a key to. She also stole a few developers' NDA/NCs and hired them. She's set up a few minutes away. She competed (in one case sucessfully) for our contracts, claiming she got all of our developers and that we're going out of business (neither of which is true -- I'm the only qualified developer on the project she managed to steal).
She left a huge trail of slime on the way out...
No idea what you should do. I'll see how our management handles it. But I think they learned at least one big lesson: Offsite backups of contracts with employees.