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?"

Teach Him

[Harlequin80]

I know this will be screamed down by the psychotic anti-corporates on this site, but teach him.

No CS grad can compete with an experienced developer in the short term. You teach them and they will see how far short they are of being able to replace you. Take it like they had given you anyone else to train without the implied potential replacement side.

I don't get this argument on this site in particular. We scream for open source, free information, anti-copyright but the second we are asked to pass on any information of our own the response is the equivalent of closing the source, giving no documentation, and threatening lawsuits.

Re:You're a contractor. Your "secrets" are yours

[bdwebb]

This is an extremely rational viewpoint to take. I work for an MSP in our projects division implementing complex network environments and a ton of virtualization for our customers and we frequently take our projects to a managed level as the OP appears to have done as well. We have found that after a customer environment has stabilized, these customers tend to be growing in size and scope over the term of our initial managed service agreement and eventually want to take most of the management in-house as a result. Ultimately while they may be extremely satisfied they perceive a threshold at which the recurring managed services costs get close to one or two lower level technicians that they can hire to maintain and grow with the company at an equal or lower cost.

Ultimately, we are contractors and we are not obligated to train their employees but we do so willingly because not only are we being paid for the time we invest into their engineers but we actually end up being able to free up resource time when done for newer projects and we do not require a staff of hundreds to turn projects AND support every one of our recurring customers. Of course the training is out of scoope of our managed services agreement and therefore we are paid time & engineering to support and train their new staff members but when done we have about a 99% success rate of then selling block-time agreements for supporting those customers and about 75% of the time, once the block of time has run out, a new block of time is sold thus continuing a managed services style engagement but with less hands-on involvement in the day to day 'my printer is not working' style simple issues that the staff techs can then handle.

Ultimately the new technicians are either going to be motivated knowledge sponges or, more commonly, will stagnate and reach a comfortable knowledge level within their own environment and continue to rely on our company to provide troubleshooting & support for critical issues beyond the scope of their abilities. In either scenario, I see the following benefits to our company:

Motiviated Knowledge Sponge
- Is able to quickly adapt to environments and continues to expand upon knowledge level
- Has been brought into an environment where his primary resource for knowledge of his daily operating environment was our company and therefore he knows he can rely on us for critical scenarios he cannot resolve or for new project deployments
- Continues to be a close contact or resource as his career progresses, likely with other companies which garners more project work for our company
- May see the benefit of potentially becoming an employee of a company such as ours and pursue a career with us and essentially the training cost of this employee has been subsidized by a separate entity at that point. This one can be iffy because some clients don't like having their employees hired away but most times the technician has progressed to the point that he is already pursuing higher pay than his current company is willing to shell out. We can return to a managed style services agreement, gain an knowledgeable and motivated technician, and he is still associated with their company by proxy and therefore the innate knowledge he has of the now more complex customer environment allows him to interface with them more easily and resolve trouble tickets rapidly while still being used as a technical resource for other contracts or projects.

Stagnant, Satisfied Technician
- Has been brought into an environment where his primary resource for knowledge of his daily operating environment was our company and therefore he knows he can rely on us for critical scenarios he cannot resolve or for new project deployments
- Continues to be a close contact or resource as his career progresses, likely with the same company which garners more project work for our company
- Typically does not have time (or in some cases, the desire) to escalate his knowledge level to critical troubles