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

Comments

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

[Anonymous Coward]

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

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

[geekboybt]

While I agree mostly with what you've said, keep in mind that, as a contractor, he's been asked to provide a different service, to train the new guy, and is being compensated as both parties deem appropriate. I completely agree that the submitter shouldn't work for free, but if he's amicable to this agreement (as he appears to be) then there's no reason he can't continue. He's made his objections about hiring a newbie to do it, but it's their code to do with as they please.

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

[assertation]

Basically, be a professional, be pleasant, do what you are obligated to do, but don't volunteer to go further.

Sounds about right.

If someone is replacing you, they can figure the "beyond obligations" stuff out for themselves.

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

[the_B0fh]

Geek boy has it right. You don't have to train him in comp sci, but showing him the ropes about the app is within scope.

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

[VAXcat]

And, if you're friendly about it all, you can count on years of providing support to the new guy, which should bring in a lot of money.

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

[Fluffeh]

Can't agree with this more. We had a similar experience withinmy company when a lot of the in-house support and dev guys were replaced with (much) cheaper contractors. They did the entire handover nicely, showed the new guys the ropes and moved into other roles or other companies. The new contractors of course are giving the quality of service as is being paid for - so many of our systems are suffering constant delays, SLAs are being missed and there is a strong push from within the business side to re-hire some of the folks that were let go. Of course, now to get them back, the salaries will have to be extra competitive as we want those exact folks back.

Sometimes cheaper is not really cheaper. I would say do a great job of handing over the project as best you can, let the new guy take the reigns. If it works out, great, if not, the company will probably want you back in short order anyhow. You can even look at it as an opportunity. Why not offer to stay on with a retainer, let the new guy handle all the gruntwork, but offer to explain or guide him/her for an hourly fee if needed. Assuming the do improve over time, you will be able to work in a new company at your normal rate and still get a small fee from this older company.

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

[Will.Woodhull]

As a contractor you bring your knowledge and experience, and the skills you have derived from that knowledge and the wisdom you have derived from that experience, to your client.

You can only teach your client's employee some of the knowledge that you have acquired. You cannot teach him your skills, in the same way you cannot teach someone new to bicycling how not fall over. He can only acquire skills through his own experience. Similarly, you cannot teach your wisdom; like skills, that is not transferable between human beings.

You and your client need to be clear about the limitations involved in this situation. Probably you need to be talking about a different kind of contract with the client, where the employee will be doing some of the heavy lifting that you now do while he begins to gain experience, but you will continue to provide the experience and wisdom that avoids costly mistakes. This would be similar to a traditional master - apprentice approach, but with a third party (the employer) paying the apprentice.

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

[sgt scrub]

I disagree. If they are entering into an agreement that includes training he is indeed needing to "train him in comp sci". The article doesn't mention that there was a written agreement; but, if the customer is verbally specifying the desire for training there is an oral agreement. They both should take the time to write down specifically what needs to be done. It has been my experience both are going to end up very unhappy if they do not.

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

[sjames]

If the pay is by the hour, be SURE to train him in comp sci. At least fill in any gaps in his education, in great detail.

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

Be cooperative

[kawabago]

They will probably need you back when the newbie crashes and burns.

You train them

[Anonymous Coward]

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.

Re:You train them

[Trepidity]

It might even get you more contracts at the same place, despite their intent to replace you. There are pretty good odds that at some point in the future, the person you trained is going to run into some problem where they'd love to get your input on it. Unless the system is quite simple and exceptionally well documented, that's almost inevitable. So there's a good chance the company will want to pay you a nice consulting rate for some hours in the future, regardless of what they think their plan is. And if the person you train was happy with your mentorship, they'll be a good internal advocate for steering those contracts your way.

Let the new developer lead the training.

[Dareth]

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 love doing that, actually

[rebill]

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.

Re:I love doing that, actually

[Anonymous Coward]

+1

Another way to look at this: Your value to the client goes up a huge amount when you're no longer a liability.

I begin documenting my projects for the inevitable client take-over as soon as possible, and the hand-off process is great all around.

I am almost always kept around as a senior resource ( this is more fun ) or as someone to escalate to, but when I'm not, I consider it a job well done and move on.

Not being able to move on, update skills, etc is the kiss of death in tech consulting. Fear the golden handcuffs, not the young replacement.

Re:I love doing that, actually

[MillerHighLife21]

Totally agree. I've always gone into projects with the goal of automating things (right down to outage buffering, failover, etc) to the point that they don't need me anymore. I take it as a point of pride and my work reflects it.

If you're taking any other approach, namely one that will force your client to remain attached to you I'd have to question your ethics, motive, and ability because what you're doing is creating a dependence on you that is borderline blackmail (if that's something you're doing).

So to the original question, help with a smile on your face, show him how the more complex pieces of the code work, document where possible and generally make sure that the tools are there for the project to continue to go on without you. They're either going to recommend you to other people because of how professionally you handled the transition and what a good job they did or they're going to be calling you back shortly when new guy isn't delivering at the rate you did. Drop off a copy of Mythical Man Month when you leave. Just leave it laying around the office somewhere. :-)

As Wil Wheaton says ... "don't be a dick".

[Anonymous Coward]

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.

Write documentation

[concealment]

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).

Be a Professional

[Anonymous Coward]

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.

Re:Be a Professional

[TheRaven64]

It's a shame this is at 0, because it's exactly what I would say. If it's a major client finishing up a piece of work, you want them to consider you for future pieces of work, and that includes building their next system, or extending this one when it's beyond the ability of the person that they've hired to maintain it. And even if this customer never needs more work from you, people move between companies, and you want them to think, next time they embark on a big project, 'at my last company, we had this really great consultant who shipped us working code and then trained our in-house staff to maintain it. We should see if he's available'.

A few thoughts

[onyxruby]

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.

Re:As a contractor

[Anonymous Coward]

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.

Been there, done that

[sideslash]

As a contractor I've been through this more than once, and actually had very good experiences training / mentoring customer employees to "take over" the programming of my projects. In one case I met weekly with a guy over many months, and took him from hand-holding up to completing major releases. I don't see it as a threat, because if you're already sharing the source code (which I always do), then you're explicitly offering that the customer can take over the job in the future. So -- assuming that mentoring is a service you want to offer -- do the best job you can, and have fun. And it is a tremendous amount of fun to teach when you are good at what you do, have some communication skills, and also have a beginner student with decent aptitude along with a serious attitude toward learning. I had all of those. /toot-own-horn

Good luck, hope it goes well for you!

High road

[Concern]

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.

I would have phrased it as

[Anonymous Coward]

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.