Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×

Ask Slashdot: How To (or How NOT To) Train Your Job Replacement? 292

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?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: How To (or How NOT To) Train Your Job Replacement?

Comments Filter:
  • by Anonymous Coward on Tuesday March 19, 2013 @04:55PM (#43217453)

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

    • by geekboybt ( 866398 ) on Tuesday March 19, 2013 @05:00PM (#43217521)

      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.

      • by the_B0fh ( 208483 ) on Tuesday March 19, 2013 @05:07PM (#43217615) Homepage

        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.

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

          • by Mr Z ( 6791 )

            There are a lot of good points in this thread. It's worth noting that there's no direct replacement for experience. You bring N years of experience to the job, and the only thing that can bring you N years of experience is N years of doing the job. While you can teach some the broad lessons (and, I would say, teach them specifically in the context of this app; you're not a professor and you're not teaching a class), there's no replacement for experience.

            When I was fresh out of college, I could write prog

        • by Anonymous Coward on Tuesday March 19, 2013 @06:34PM (#43218455)

          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.

        • by sgt scrub ( 869860 ) <saintium.yahoo@com> on Tuesday March 19, 2013 @07:15PM (#43218807)

          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.

        • by sjames ( 1099 ) on Tuesday March 19, 2013 @07:23PM (#43218889) Homepage Journal

          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.

          • Oh, I like this suggestion. Experience and knowledge isn't a matter of secrets, it is a product of time, effort and study. If you're to train a replacement to handle your work with your competency then by all means attempt to spend the time on the education and experience it takes to match your own. It's practically a job for life. (Even if you train to today's competency, you won't catch up to the level you'll have after doing that training.)

            Unless your secret is that you're overpaid or an idiot. If that's

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

        Nowhere in TFA does the submitter state that he is being compensated, let alone that he's happy with the agreement.

        • He's a contractor. If they're not paying his hourly rate, he doesn't have to do the work.

          • by gr8_phk ( 621180 )
            And as I understand from contractor friends, you bill for "time and materials" not finished code. If you quote a deliverable you better be a good estimator and good at documenting the requirements up front, etc... To eliminate the uncertainty you bill for time and materials, and at that point it doesn't matter if they have you writing code, writing a manual, teaching, or shoveling shit.

            IMHO he's best to document and teach everything he can to make his customer happy. If you want job security through obscu
            • And as I understand from contractor friends, you bill for "time and materials" not finished code

              This depends entirely on the contract. When I hire contractors, I never agree to "time and materials". If they won't agree to compensation tied to the completion of specific milestones, then I find a different contractor.

              • by Belial6 ( 794905 )
                I have done both kinds of work. For deliverable contracts, I charge ~3X as much as I estimate it will take, and make the requirement that I have complete control of the environment for the deliverable. It only rarely taken, which is good because when you charge by the deliverable, you have to be a total hard ass about the spec changes, and if it isn't in the spec, I get to choose how it works. This tends to make both me and the client less happy with the outcome.
        • Yes. He is a contractor. That means hourly rate. He is not asked to do overtime and teach the kid on his own time.

          • by leenks ( 906881 )

            Or daily rate. And yes, some contractors do work beyond the contracted hours if they get more out of the project than just the money...

          • Yes. He is a contractor. That means hourly rate.

            Assuming he bills by the hour.

            He is not asked to do overtime and teach the kid on his own time.

            Assuming that "teaching the kid" is within the scope of the contract.

            There's a difference between 'facts' and 'assumptions' - you might study up on the meaning of the two words, as you're a bit unclear on the differences.

        • by Dahamma ( 304068 )

          Wha? Did *you* actually read TFA? (actually, summary, there wasn't even an attached article).

          For the most part it has been a happy arrangement for both parties

          He actually used the word "happy" in the summary! And said he's not worried about losing the client.

          And as far as not stating he's being compensated... he's a contractor. He does work for a client and bills them for his work, and he clearly states he's still working for the client, but one day they might end the contract to save money - which means

      • by eth1 ( 94901 ) on Tuesday March 19, 2013 @05:22PM (#43217847)

        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.

        Yeah, if you're getting paid to teach him your code, why not? Also, if, as you seem to think, they've bitten off more than they can chew, you might end up getting paid to teach him, then keep the contract anyway, when they realize it's not going to work. That might not happen if you just shove the code at them and leave.

        • by VAXcat ( 674775 ) on Tuesday March 19, 2013 @05:33PM (#43217987)
          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.
          • by bdwebb ( 985489 ) on Tuesday March 19, 2013 @07:37PM (#43218997)
            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 troubleshooting/support or implementation of early-adopted technology to accelerate technology growth at the company and he typically relies on our team to supplement his areas of weakness

            Regardless of the scenario, it is almost always the case that the trained technician then relies on a block-time agreement from our company for assistance and support at some level which provides us with some measure of recurring revenue (though not as predictable) and while it may be less, we are almost always used as a monitoring agency for established customers for a considerable amount of time after a project engagement which offsets the lost revenue from the complete managed service agreement that they no longer require. Ultimately, the loss in recurring revenue to our business is minimal compared with the time our engineers have to address more complex issues or projects and we come out looking like kings because we are not keeping our knowledge close to the cuff and trying to force the customer to stick with us in a managed service capacity. Luckily the owners of our company understand that as we continue to evolve with the market and technology trends, we still continue to remain at or near the top of the game. The technicians we have trained at each of the companies we have done projects for or have had agreements for continue to rely on us for advanced knowledge or progressive technologies, even though some of the techs may be the more motivated types.

            When it comes down to it, if your area of expertise requires keeping your knowledge secret then you're fucked. The more you hold knowledge close, the more you drive away customers and therefore their employees that will be the ones actually seeking you out in the future, the less resources you have available, the less word of mouth advertising you get, the less contacts you develop. It does not benefit a motivated, knowledgeable, professional to hoard that knowledge because, in my experience at least, those that take this approach pigeon-hole themselves into a specific subset of knowledge and are not forced to adapt and change with the marketplace. In the end, someone younger and hungrier will always be able to meet or surpass the knowledge level you have unless you keep moving forward and your old 'secrets' will be common industry knowledge...the internet is pretty neat at being a giant reference manual, even for the most technical information (as long as you know how to parse through the garbage of course.)
        • by Fluffeh ( 1273756 ) on Tuesday March 19, 2013 @05:36PM (#43218005)

          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.

    • This.

      Alternatively, you could go the Total Dick route and feed him a bunch of bullshit, just to watch the poor kid's wheels spin.


    • by assertation ( 1255714 ) on Tuesday March 19, 2013 @05:05PM (#43217595)

      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.

    • Be a Professional (Score:5, Insightful)

      by Anonymous Coward on Tuesday March 19, 2013 @05:12PM (#43217697)

      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.

      • by TheRaven64 ( 641858 ) on Tuesday March 19, 2013 @05:20PM (#43217829) Journal
        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'.
    • I'd go more with:
      Request formal performace evaluationas and professional references as a requirement for training.

      Negotiate any additional support charges (hour/day/job) for future support once existing contract is fulfilled.

      Train within reason.



    • Agreed, just be available to answer any questions. It would also be nice to show where stuff's at, if you set up a process that touches 3 servers arbitrarily, you should share, but maybe only when the need for the knowledge arises. Don't schedule a meeting for something like that, wait for a manager to acknowledge the need for training, and then do it. Basically, my point is nobody makes more for training somebody. And interestingly enough, they won't replace you if they're not confident in your replace

    • Re: (Score:2, Insightful)

      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.
    • by fermion ( 181285 )
      I would agree that you have sold the code, not the expertise that wrote the code. I also think that there is a responsibility to document what you have done. As in any professional situation a person versed in the craft should be able to figure out what is going on.

      What I would say is that contractor is exactly that. There appears to be other contracts, so I don't see what the problem is here. Be professional, answer questions, be forthcoming, show any spots where something tricky is going on, explain

    • I can't disagree more, as this [slashdot.org] poster put it - if you've done a good job on the software and a good job on the training, you'll have a happy client more likely to recommend you or consult with you in the future. You'll have a client that wants to call you for their next project, instead of being stuck calling you for support on their past projects. Don't look at it as the client trying to replace you with somebody cheaper - look at it as the client freeing up your time for more valuable and interesting task
    • 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.

      I would say exactly the opposite. I assume they are in fact paying you to train him, but assuming that they are, and that the person you've been assigned to train is intelligent and teachable-- then, do your best.

      First, training the next generation is, or ought to be, part of everybody's job; it's to everybody's advantage that the next generation be capable and competent. (They'll be maintaining the infrastructure when we're in nursing homes shaking our canes at the doctors.)

      Second, teaching people, assuming that they're intelligent and want to learn, is fun.

      And, third, you're training someone who will go on in the industry-- he won't be at your customer's place forever, you can count on it-- and if you train him to be competent and useful, he will move onward and upward and at every spot he goes, he's going to be crediting you as a really great programmer. And, the better he is, the better he makes you look./ He's not taking business away from you-- he's generating business for you.

    • High road (Score:5, Insightful)

      by Concern ( 819622 ) on Tuesday March 19, 2013 @05:48PM (#43218137) Journal

      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.

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

      If you consider yourself to be a professional, you will always do work that you take pride in. As you get older, it's amazing how small the world becomes - your reputation needs to precede you. At worst, you leave this job with everyone happy with you. At best, you have a new code monkey that sees you as a guru and future consultant and a former client who would happily recommend your work. There is nothing better for your word-of-mouth than having a brilliant protege.

      • If you consider yourself to be a professional, you will always do work that you take pride in. As you get older, it's amazing how small the world becomes - your reputation needs to precede you. At worst, you leave this job with everyone happy with you. At best, you have a new code monkey that sees you as a guru and future consultant and a former client who would happily recommend your work. There is nothing better for your word-of-mouth than having a brilliant protege.

        Not to mention someone may move to a new company or position where they need your skills and remember you as "the guy who helped us out and left us in a great position even when he knew he was training his replacement;" or have a friend who says "I need..." and recommend you. It's part of being a professional, as you correctly point out.

    • by drolli ( 522659 )

      My thoughts: Besides i dont know if the contrector also does education: Do they know in how many billable hours teaching "all secrects of your code" may result? If yes: CYA, get it in writing that you are paid for "teaching all secrets of the code" instead of "automating and stnadardizing your build/packaging/deployment processes". After the new guy tries to graps "all secrets of your code" and fails to get the first proper build, bill them for the rest.

    • I'd go much further than just giving the kid the code, docs and offering to answer questions. First off, the firm is not crazy at all to want multiple people, at least one in-house, who know the system; If and when you move on, even a junior dev with familiarity is better than a fresh contractor, the source, and the stack of docs quickly printed.

      I'd take this as an opportunity to keep the system alive after I go off to other things - I'd do what the firm and new bloke are hoping, and try

  • Be cooperative (Score:5, Insightful)

    by kawabago ( 551139 ) on Tuesday March 19, 2013 @04:59PM (#43217515)
    They will probably need you back when the newbie crashes and burns.
    • They will need you back when the newbie crashes and burns.


    • Teach him as you write documentation: Literally type notes with him watching. He will forget & probably quit before you get asked back, so you need proof that you did impart "secrets".

      But don't be surprised at some negativity to you when it all goes South. Well-known places (for new devs under new managers) to find your typed-up training info will be key to positive referrals.

  • You are obligated to only fulfill the terms of your contract. Part of being a contractor is doing things however you want as long as you are not in violation of your terms.

    • Re:As a contractor (Score:5, Insightful)

      by Anonymous Coward on Tuesday March 19, 2013 @05:13PM (#43217715)

      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.

      • by iiii ( 541004 )

        Parent post is well stated.

        There really is no benefit to becoming adversarial or doing anything to undermine the future success of the project. And there are many possible down sides, including your rep within that company and your broader rep.

        Continue to provide them the best value you can. It sounds like right now that value might be to advise them on the level of complexity of their codebase and the level of talent and experience needed to maintain and continue development on it. Even if that does

      • Moreover, if they can get someone on staff to do the work that is only worth $60/hour to them, you stand a better chance of getting the work that is worth $140/hour to them. Win-win. We have a consultant do projects because we don't have the manpower to do it internally, but he will always have work from us where it makes sense.

      • But you will never be irreplaceable.

        I'd argue that, as a company, I don't want ANY one individual, not even the CEO, to be counted as 'irreplaceable'. What if the OP was killed in a car crash tomorrow? Had a heart attack or stroke?

        The kid might only be able to do some things with the software, but he could reduce an emergency to an urgent situation as he keeps the system operating long enough for a new contractor to figure out the program.

  • You train them (Score:5, Insightful)

    by Anonymous Coward on Tuesday March 19, 2013 @05:01PM (#43217541)

    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 (Score:5, Insightful)

      by Trepidity ( 597 ) <delirium-slashdot@hac k i s h . org> on Tuesday March 19, 2013 @05:22PM (#43217851)

      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.

  • by Dareth ( 47614 ) on Tuesday March 19, 2013 @05:02PM (#43217555)

    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.

  • by rebill ( 87977 ) on Tuesday March 19, 2013 @05:02PM (#43217559) Journal

    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.

    • by Anonymous Coward on Tuesday March 19, 2013 @05:11PM (#43217685)


      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.

    • by pnutjam ( 523990 )
      Everybody has been trained by someone older and more experienced. This is how a society moves forward. If we stick to what we know and hoard our knowledge we stop learning and our accomplishments die with us. Have some kids and train some young people. It's a rewarding experience to be a mentor.
      • I wish that were true. I have never been trained by someone older and more experienced. I have been that person (not older, but more experienced). But unless you count Googling specific problem cases, then no I haven't had that opportunity.

        • by pnutjam ( 523990 )
          So you just climbed out of the womb knowing everything?
          Your parents and teachers didn't impart any knowledge to you? You never read a book to learn something, guess who wrote that book. This attitude is one of the problems.
          You sound like Craig T. Nelson, "I've been on food stamps and welfare, nobody ever helped me."
    • by MillerHighLife21 ( 876240 ) on Tuesday March 19, 2013 @05:14PM (#43217735) Homepage

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

      • I agree. Take the high road. If you show you can deliver all the way through and successfully provided the initial value, your client will remember this when they need another new system. You can also keep an eye out for the next gig once your replacement gets his stuff in relative gear. Exit gracefully and don't burn a bridge.

        That'll get you a referral more than a "figure it out for yourself kid" style as some advocate. It'll also do right by the kid who is in the position we all were in at one poi
    • so... have they ever hired you back? Yours is not my (or other contractors) understanding of how the industry works, but nice happy thoughts though.

    • Usually if a company hires someone cheap n' incompetent to replace you because you cost too much, you'll find future work in fixing what they break. If you were a dick about it an the company feels you tried to screw them, they'll look for someone else. However if you did what you were asked and did it well, they may hire you back.

      Remember as a contractor you are not an employee, but you are always a future contract hire if they like your work.

    • This this this!!!

      I'm sad this wasn't the first post. You need to look at it from the right perspective. If you do a great job on the software and a great job on the training, in the long run you've saved that company money as opposed to being a contractor who milks money out of them and leaves them unsatisfied. Most companies will remember that. They'll refer new business toward you, and you'll be first on their list when they need something new that they can't do in house. You've freed up your time to w
  • by Anonymous Coward on Tuesday March 19, 2013 @05:04PM (#43217575)

    Like this: http://dilbert.com/strips/comic/2004-02-07/

    • LOL! I've actually had this happen.Guess what.The replacement turned out to be so incompetent that the client lost his ass.Then he wanted me to come back and try to repair the damage the replacement had done.By then,I had moved on to another job that paid much better.Told him"you made your bed,sleep in it"

  • by Anonymous Coward on Tuesday March 19, 2013 @05:04PM (#43217577)

    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.

    • Yea,but when the client was a pure asshole about the replacement to begin with,I have NO sympathy.BTW he is long out of business now and serving 5-10 for attempted robbery.

      • Yea,but when the client was a pure asshole about the replacement to begin with,I have NO sympathy.BTW he is long out of business now and serving 5-10 for attempted robbery.

        Who knew that robbery was so lucrative that robbers needed IT consultants for the back-office work?

        I mean, unless he was a banker or something like that, but they don't get jail time, they get bonuses.

  • by Red Herring ( 47817 ) on Tuesday March 19, 2013 @05:06PM (#43217605)

    First, is training included? If not, well, make it worth your while. Generally when I've done (much smaller) projects, I generally make sure that the contract I sign lays out that the payment is for the code, and specifically covered training regarding the operation/implementation of the project. Bringing a fresh person up to speed on the code that I provide is not part of the contract, but can be for the right amount of money.

    Since I also work full-time at my "real" job, are you sure that this isn't just them wanting to bring the project in-house, more under their control? It might not be about the money, specifically, which means that this might open other opportunities with them on other projects, or even a full-time job with them (if you want it.) Looking at it from the point of view of my real job, there are times when I want ta project done by a contractor/temp, and there are times when I want it done/supported in house. It's usually more about the strategic vs. tactical value of the project than the pure "how much am I paying the guy" number. Make sure that you understand the motivation of the client, so you can better position your next move...

  • So jack your rates up and do the best damn job you know how to do.
  • He will absorb what he/she can and then with the new found skills find a better job someplace else. You will be called back at which point you can raise your rate. Everybody wins!
  • On your personal relationship with the client.. do you go out for beer together, understand their situation, get why they are doing this? Or do you feel like you have given your all, only to be tossed aside? You might cooperate fully, or cancel your contract and offer to start a training one at higher rates. Depends..
  • by concealment ( 2447304 ) on Tuesday March 19, 2013 @05:10PM (#43217661) Homepage Journal

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

  • by SirLurksAlot ( 1169039 ) on Tuesday March 19, 2013 @05:11PM (#43217673)

    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.

  • A few thoughts (Score:5, Insightful)

    by onyxruby ( 118189 ) <onyxruby&comcast,net> on Tuesday March 19, 2013 @05:12PM (#43217703)

    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.

  • Teach Him (Score:3, Informative)

    by Harlequin80 ( 1671040 ) on Tuesday March 19, 2013 @05:15PM (#43217749)

    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.

  • by Teun ( 17872 )
    Exactly what I am doing!

    I have evolved into a full-time trainer, travel all over the place to collect airmiles for my next holiday.
    Of course I'm hired to (help) teach smart cookies to become The Best in field, they are not competition, they are going to pay my ticket.

    Because our management is not stoopid I'm also required to pick up the phone at unholy hours to support the new guys.

  • Billable hours are billable hours. You could always charge a different rate for training as opposed to coding. However, billable hours after they replace you are at tripple the normal rate.
    • by Bomarc ( 306716 )
      I had a company call me after (trained) and let go, asking for help. When I said to RTFM, the response was "You are not a team player".

      Well duh, I was kicked off the team!

  • ... you should inform them that day rates for training are 2-3 times day rates for remote development, and start from there...

    • by Bomarc ( 306716 )
      No, don't tell them BEFORE he leaves. Save this info for when they need to call him back.
  • Is full of people who've never had a real job before... why?

  • As programmers it is our ethical duty to destroy our own job. We reuse open source code because it take less hours to reuse code than to reinvent it. We test our code, so there is less bugs, so we bill less hours to the client. We write good documentation so other people can understand our code when we leave. We use standards and design metaphors for the same reason. Training other people is the same concept. We do a good job so we can move on to other things. Things that are more interesting and worth our
  • First, if it's not already explicitly in scope for your existing contract, negotiate a "train my replacement" clause or task, at a premium over what you're already billing. Be frank with your customer that you both need to realize that they are asking you to train your replacement. You might be surprised to hear them say "no, we just want additional staff". If that's the case, negotiate for a long term contract of your own as a condition of training.

    Then, mentor the young pup. Treat him like your son

  • by sideslash ( 1865434 ) on Tuesday March 19, 2013 @05:30PM (#43217943)
    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!
  • We're people and we suck. The only thing that matters is what this employer can do for you when you finish working there.

    Are they going to be an asset for networking or as a reference? Are they going to get you more work by recommending you? Are they going to be bringing you back for more work?

    Your answers to these questions will dictate how much time you should spend supporting the new hire.

    It's just business.

  • by Arancaytar ( 966377 ) <arancaytar.ilyaran@gmail.com> on Tuesday March 19, 2013 @05:34PM (#43217991) Homepage

    If they want you to train employees instead of just code, you should insist on a new contract and negotiate a much higher rate.

  • Your job as a contractor is customer satisfaction within the bounds of the law. I've had long projects that I've completed or come close to completing, and then been asked to instrument a hand-off to a junior member. I've been paid to mentor the junior member and been called in to solve problems that were over his/her head with him/her watching while I solved the problems, answering questions as they ask. In at least one situation, the handoff was to free me up for a new project the customer was just a

  • You're a professional, so there's really only one way to approach it: professionally. As a contractor, there's always the possibility that your services will no longer be required anyway. Show them they're making the wrong choice by approaching it as you would any other work. No holding back any tricks, no keeping secrets, no letting the new guy flounder (much... he needs to get his wings). Answer as fully and thoroughly as you can when asked about anything. Your actions with this will be one of the last th

  • Watch out (Score:4, Insightful)

    by GNUALMAFUERTE ( 697061 ) <almafuerte@NOSPam.gmail.com> on Tuesday March 19, 2013 @05:57PM (#43218219)

    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.

  • As you said yourself, creating good code is not something one would expect a beginning-wage employee fresh out of college to create. At best, your replacement might be able to maintain the code already created.

    So, basically, whatever you do isn't going to be sufficient if the employer needs major changes to the code. Therefore, I guess it depends on your relationship with the contractor. If you say "here's the source code, good luck" and leave, or if you break it down "this is where the majority of the w

  • The way you train a "replacement" is the same way you train any new employee on a software team.

    Start by giving them small tasks. Let them work their way through your backlog of things you haven't gotten around to doing. Bugs are great candidates for new members of the team. Ease them into the code base. Do code reviews with them before check-ins.

    Personally, I like to do some pair programming during the first couple of days to help them set up their development environment and familiarize themselves with ho

  • I didn't think so. It's not in mine, either. Documenting is, though, so I'd let the newbie learn to read.

  • Years ago a client decided to save money by hiring a recent college graduate. I helped them in every way that I could. About two months later they asked me to help write the support documentation for the firing.

    I've been on the other side, too. I had a client early on (mid 90s) that was paying me $60/hour. They had, according to them, never paid anyone more than $7/hour before. They were explaining this to me as part of a conversation about how I was actually much much cheaper than any of the $7/hour gu

  • You say you've got other contracts. You've got a good rapport with the company, presumably a good recommendation as well. Sounds like they're by choice or by necessity moving the project to a maintenance mode rather than active development. (I'm just assuming that because you say you believe they're bringing on a junior guy to replace, not supplement, you.) Again, I'm guessing, but you'd probably rather be doing something more active, so be nice and try to teach the new guy what you know about the project.

  • by the-build-chicken ( 644253 ) on Tuesday March 19, 2013 @06:44PM (#43218545)

    So, I'm also a high earning contractor whose wages are consistently 30% above market rates, and have been for as long as I can remember...I also have (paid for myself) obtained complementary teaching qualifications so I can offer exactly what you're describing as a "value add" service to my clients. I always have a new contract waiting for me at the end of the current one, I've never been unintentionally unemployed (I like to sit on the beach a lot), I'm regularly re-hired by the same clients that have used my services previously, and usually they bid against each other for my services, I don't work very hard (can't remember the last time I even said the word "overtime") and I make buckets of money...why?

    Because I approach every single contract with the view that at any point I could get a better offer somewhere else and I don't want to burn the current bridge. Every single thing I do, be it code, or architecture, or business process modelling, or teaching/mentoring is highly documented, and at least one full time staff member has had a walk through to the point where, in a pinch, they could get by without me. And every single client appreciates my approach and recommends me wholeheartedly to their business buddies.

    "Knowledge lockin" is a petty and small way to build a career...if you have to rely on it, eventually you will have no career (I have seen it over and over again...cushy contractor locks in his position through knowledge bargaining rather than services provided and sure, he gets 5, maybe 10 very stressful years out of it...then his career is toast)

    And teaching is fun...remember, that kid you teach today is going to be the project manager signing your very hefty invoice tomorrow. Many of the "kids" I taught at one point are now in very senior executive positions...who do you think they recommend when the job has to be done right?

    And finally, the ethical aspect. My art teacher once said to me "Everything you learn in life is taught to you by someone...to die without passing that knowledge on is stealing from humanity."

    My advice, don't just teach that kid...teach the hell out of him...make it obvious that you're more than happy to do it. Understand that, once a contract is coming to an end, it's a natural and expected part of the development cycle for your client to want to fund the maintenance of the project in a more cost effective manner (and who the hell wants to get stuck doing maintenance anyway?). And go out of your way to make it as visible as possible that you understand that part of the development cycle and are enthusiastic to have done such a great job at design that maintenance can be handle by a graduate. And through all this, keep asking...referrals, referrals, referrals.

Prototype designs always work. -- Don Vonada