Slashdot Mirror
Ask Slashdot: How To (or How NOT To) Train Your Job Replacement?
An anonymous reader writes "I am a contract developer from a major U.S. city. My rate has never been the lowest, but it's nonetheless very competitive considering the speed and quality of the work I have always delivered, as well as the positive feedback I've received from most clients. In the past ~3 years, I have been working on a sizable project for a major client. For the most part it has been a happy arrangement for both parties. However, for various reasons (including the still ailing economy), starting this year they hired a fresh college graduate in-house, and asked me to teach him all 'secrets' of my code, even though they have the source code by contract. The implicit (although never openly stated) goal is of course for him to take over the project and hopefully reduce cost, at least in the short-term. I say 'hopefully' because I am pretty sure that, because they are unfamiliar with the software industry, they underestimated what it takes to make quality, production-ready code. I am not afraid of losing this particular client, as I have many others, but I want to ask Slashdot: how do you handle this type of situation — training someone whom you know will eventually replace you at your job?"
Give him the source code. Have him go over it. If he has any specific questions, answer then succinctly and accurately. But keep in mind that as a contractor you have no obligation to share any of your coding "secrets" with anyone, or teach anyone else how to code. Don't let your ego and desire to brag about how clever your coding solutions are make you forget that you are under no obligation to train anyone to take your place (no matter how much junior may flatter you).
You've given them the deliverables, you've presumably fulfilled your contract. Nowhere in said contract does it say anything about training other coders, I presume. Be professional and polite (don't refuse to answer questions they have about the code, for example). But also be firm about the limitations of your contract (it doesn't include answering questions like "Hey, can you teach me how to do this neat trick like you did?" and "Can you teach me how to do good memory management?").
They will probably need you back when the newbie crashes and burns.
I am always in-favor of being a trusted agent. This way you might get a lead on the next contract as someone who can be trusted.
If you actually are willing to take on the job, then I would suggest you let the new developer lead the training. See if the new person is self motivated and willing to learn. Guide the conversation where it needs to go, but make the new developer do the homework and show they got the prerequisites.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
My primary goal as a contractor is to "put myself out of a job". It can be scary to let go of an existing income stream, but no job is a guarantee. If I walk out of a site with a happy customer, they have an incentive to hire me back ... and I get to work on something new (to me), rather than being stuck maintaining the same code for years.
There are risks, but if your replacement flames out, they can always come back to you, later.
Chivalry is not dead, it's just frequently misspelt. - M. Langley
Your reputation is worth more than your ego. Be kind, be polite, and helpful ... to a point. Make a 30/60/90 day 'grace period' to answer "hey, can you remind me..." questions. Do this via email so it's all documented - use the excuse of "this way, you have it for reference".
You don't need to bend over backwards for your 'replacement', but as a contractor, your reputation and network are paramount.
You're on a per-hour, right?
You're going to walk him through the code; answer questions; answer the phone; bill a minimum for each. This is just good consultant practice. After that, you're on a per-hour basis to fix what he can't. No problem there, because these are the conditions under which you formed the contract.
However, you might want to pitch the writing of some documentation so he has a roadmap to your code and a description of how each (major) function/routine works. That's more hours for you, and less helplessness for him; this is important because when you're on another contract, you really don't want to take a couple hours out to put out fires at a dead-end gig (for you).
You do it well. You've obviously already determined that they're planning on cutting costs by getting an in-house developer to take over, and I'm assuming you know that means they're not planning on keeping you on that particular project forever. So rather than doing a half-assed job and leaving the newly-minted dev with the codebase, a handshake, and "good luck!" do them a favor and help them learn everything they should know to do a great job. You really have nothing to lose by training the new guy well; you've got other clients lined up, if you do a good job this client may have you come back in the future (when the economy has more fully recovered) and do more work for them, and you'll have built another relationship with a developer who remember that you took the time to help them out.
God, schmod. I want my monkey man!
Your a contractor. You should have lots of business ahead of you if you try and be professional with each and every client. Teach these developers as well as you can and to the best of your ability. (Unless you dislike training others enough you don't even have a rate you'd be willing to charge...) The people you have done business with in the past will likely want to do business with you again if you are professional and priced correctly. This includes the developers you train. They may end up wanting to hire you when they are in another job later.
Don't be a jerk. Be honest with your customers, too. If the developers have limitations try and express what they will be able to do well without over selling them.
If you can't be replaced you can't be promoted. If you can't be replaced you can't move on to something better without hurting your client. If your hurt your client by your leaving you will be remembered in a bad way.
This can be categorized into 'how to kill the goose that lays the golden eggs'.
Developers get fired all the time - and yes the company, the manager, the new developer will all go through a period of fighting fires. But you will never be irreplaceable. At the end of the day, they dont wanna keep paying $100/hr for ever, they will hire a $80K developer for sure.
If you are good and try your best to at least give the new developer some idea of how to do things, they may call you back for other business. Otherwise, they will remember you for screwing them over. IT industry is a big world, but slowly reputation does travel.
So tell them how much time it will take in addition to what you have allocated for development, and then copy the development manager and send the developer the docs & source code and ask him to ask you questions anytime. Set aside some time for one-on-one meetings to help him understand the code if possible. Keeping the development manager in the loop about training is probably the most important part of this deal.
If they want you to train employees instead of just code, you should insist on a new contract and negotiate a much higher rate.
I don't agree that you should get legalistic about what is and isn't in your contract. If you're writing software, answering questions about it and helping others understand it is part of the basic standards and practices of the profession. If you're a contractor, training up internal resources to take over your project is totally ordinary.
They've been a client for years. Take good care of them. If they want to move the role full-time, in-house, that's a good growth step for them.
If you're the kind of contractor who's hostile to that, and looking for ways to resist and debating what's in your contract, or being unprofessional when it comes to transitioning your role, expect not to be welcomed back, and don't look for them to give a glowing reference.
If you act like a pro, and take good care of them, then you're helping your reputation and chances for future work.
Tired of Political Trolls? Opt Out!
You might get lucky, but here is my experience with this issue:
- You act nicely, and teach the noob the "secrets" of your code
- You go away, the noob didn't understand shit, he gets lost.
- He eventually will either screw up big time, or just fail to produce new deliverables
- He gets pushed, blames you (he'll either say your code sucks, or he'll say you are keeping "secrets", or in any other way trying to protect your job by preventing him from doing his.
You'll end up forced to tell the customer to STFU and GTFO, or you'll be doing work for free.
My recommendation:
If you have fully documented the code (both inside the code, and in a standalone documentation that explains everything from coding style to APIs), tell the customer everything any competent coder might need is in the docs, and remain available for any specific questions the coder might have, under a pre-arranged hourly rate.
If your product hasn't been fully documented, send them a quote for full documentation, and go back to the previous stage.
WTF am I doing replying to an AC at 5 A.M on a Friday night?
You're a contractor. Make a new contract.
You're obviously not going to do this for free, so approach it like any of your other services for hire. Work out how much time they want to dedicate to it or just get the to agree to a suitably high hourly rate for your new services, which are now essentially tier 2 support. Be sure to include enough of a 'get out free' clause so that if the new guy rips the code/configuration/hardware to shreds, you're not obligated to clean up his mess. Then just rake it in.