How to turnover a utility which I manage [duplicate]

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
1
down vote

favorite













This question already has an answer here:



  • How can I prepare for getting hit by a bus?

    13 answers



A little over two years ago (about a week after being hired into my first job), I was asked to improve a system used by our office. It was supposed to be a quick and easy thing, maybe two weeks. I end up (with managerial approval), doing a total overhaul of the system and sinking about 6 months into it. I can now confidently it is my system. I have a casual understanding of programming (I'm an engineer), which I used in my overhaul. The system works, but its not error free, and it hiccups often enough that without me, it would not function. I am now considering leaving, but am concerned about leaving my office high and dry. The way I see it, I have a few options:



  1. Cut and run: Leave the system as is, if it breaks, its not my problem anymore, and I should just live with any potential negative reputation this may give me.

  2. Offer to do my best to train someone on how to work with the system: This would take time (I would need to do this well before my two weeks), and likely wouldn't fix the problem fully (I am not confident in my coworker's ability in programming)

  3. Offer to continue to work with the system even while at a new job: This option means I'll be giving up nights and weekends to fiddle around with code that someone else owns, but no one will ever be able to call me apathetic. As an aside, a friend suggested doing this and charging the company, but that sounds a lot like blackmail to me.

How do I professionally turn over control of a utility when changing jobs?




professionalism software-industry




share|improve this question












marked as duplicate by gnat, yochannah, Community♦ Mar 25 '15 at 14:18


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.










  • 3




    Could be helpful - How can I prepare for getting hit by a bus?
    – David K
    Mar 24 '15 at 20:05











  • Very helpful, thanks!
    – wnnmaw
    Mar 24 '15 at 20:13
















up vote
1
down vote

favorite













This question already has an answer here:



  • How can I prepare for getting hit by a bus?

    13 answers



A little over two years ago (about a week after being hired into my first job), I was asked to improve a system used by our office. It was supposed to be a quick and easy thing, maybe two weeks. I end up (with managerial approval), doing a total overhaul of the system and sinking about 6 months into it. I can now confidently it is my system. I have a casual understanding of programming (I'm an engineer), which I used in my overhaul. The system works, but its not error free, and it hiccups often enough that without me, it would not function. I am now considering leaving, but am concerned about leaving my office high and dry. The way I see it, I have a few options:



  1. Cut and run: Leave the system as is, if it breaks, its not my problem anymore, and I should just live with any potential negative reputation this may give me.

  2. Offer to do my best to train someone on how to work with the system: This would take time (I would need to do this well before my two weeks), and likely wouldn't fix the problem fully (I am not confident in my coworker's ability in programming)

  3. Offer to continue to work with the system even while at a new job: This option means I'll be giving up nights and weekends to fiddle around with code that someone else owns, but no one will ever be able to call me apathetic. As an aside, a friend suggested doing this and charging the company, but that sounds a lot like blackmail to me.

How do I professionally turn over control of a utility when changing jobs?




professionalism software-industry




share|improve this question












marked as duplicate by gnat, yochannah, Community♦ Mar 25 '15 at 14:18


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.










  • 3




    Could be helpful - How can I prepare for getting hit by a bus?
    – David K
    Mar 24 '15 at 20:05











  • Very helpful, thanks!
    – wnnmaw
    Mar 24 '15 at 20:13












up vote
1
down vote

favorite









up vote
1
down vote

favorite












This question already has an answer here:



  • How can I prepare for getting hit by a bus?

    13 answers



A little over two years ago (about a week after being hired into my first job), I was asked to improve a system used by our office. It was supposed to be a quick and easy thing, maybe two weeks. I end up (with managerial approval), doing a total overhaul of the system and sinking about 6 months into it. I can now confidently it is my system. I have a casual understanding of programming (I'm an engineer), which I used in my overhaul. The system works, but its not error free, and it hiccups often enough that without me, it would not function. I am now considering leaving, but am concerned about leaving my office high and dry. The way I see it, I have a few options:



  1. Cut and run: Leave the system as is, if it breaks, its not my problem anymore, and I should just live with any potential negative reputation this may give me.

  2. Offer to do my best to train someone on how to work with the system: This would take time (I would need to do this well before my two weeks), and likely wouldn't fix the problem fully (I am not confident in my coworker's ability in programming)

  3. Offer to continue to work with the system even while at a new job: This option means I'll be giving up nights and weekends to fiddle around with code that someone else owns, but no one will ever be able to call me apathetic. As an aside, a friend suggested doing this and charging the company, but that sounds a lot like blackmail to me.

How do I professionally turn over control of a utility when changing jobs?




professionalism software-industry




share|improve this question













This question already has an answer here:



  • How can I prepare for getting hit by a bus?

    13 answers



A little over two years ago (about a week after being hired into my first job), I was asked to improve a system used by our office. It was supposed to be a quick and easy thing, maybe two weeks. I end up (with managerial approval), doing a total overhaul of the system and sinking about 6 months into it. I can now confidently it is my system. I have a casual understanding of programming (I'm an engineer), which I used in my overhaul. The system works, but its not error free, and it hiccups often enough that without me, it would not function. I am now considering leaving, but am concerned about leaving my office high and dry. The way I see it, I have a few options:



  1. Cut and run: Leave the system as is, if it breaks, its not my problem anymore, and I should just live with any potential negative reputation this may give me.

  2. Offer to do my best to train someone on how to work with the system: This would take time (I would need to do this well before my two weeks), and likely wouldn't fix the problem fully (I am not confident in my coworker's ability in programming)

  3. Offer to continue to work with the system even while at a new job: This option means I'll be giving up nights and weekends to fiddle around with code that someone else owns, but no one will ever be able to call me apathetic. As an aside, a friend suggested doing this and charging the company, but that sounds a lot like blackmail to me.

How do I professionally turn over control of a utility when changing jobs?





This question already has an answer here:



  • How can I prepare for getting hit by a bus?

    13 answers





professionalism software-industry





share|improve this question











share|improve this question




share|improve this question










asked Mar 24 '15 at 19:50









wnnmaw

5251714




5251714




marked as duplicate by gnat, yochannah, Community♦ Mar 25 '15 at 14:18


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.






marked as duplicate by gnat, yochannah, Community♦ Mar 25 '15 at 14:18


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.









  • 3




    Could be helpful - How can I prepare for getting hit by a bus?
    – David K
    Mar 24 '15 at 20:05











  • Very helpful, thanks!
    – wnnmaw
    Mar 24 '15 at 20:13












  • 3




    Could be helpful - How can I prepare for getting hit by a bus?
    – David K
    Mar 24 '15 at 20:05











  • Very helpful, thanks!
    – wnnmaw
    Mar 24 '15 at 20:13







3




3




Could be helpful - How can I prepare for getting hit by a bus?
– David K
Mar 24 '15 at 20:05





Could be helpful - How can I prepare for getting hit by a bus?
– David K
Mar 24 '15 at 20:05













Very helpful, thanks!
– wnnmaw
Mar 24 '15 at 20:13




Very helpful, thanks!
– wnnmaw
Mar 24 '15 at 20:13










2 Answers
2






active

oldest

votes

















up vote
5
down vote













Is there documentation for the system? If there is a piece of code that is critical to the functioning of the business, that code really ought to be documented well enough that a competent developer could come in off the street and figure out how to support it. If there are things that hiccup regularly, there should be operations documentation that helps someone troubleshoot at least the common failure modes. If there is no documentation, it should be relatively easy to get authorization to create it on the general "what if I get hit by a bus" principle.



Businesses generally dislike having a single point of failure so they dislike having processes that only one person can support. It also tends to limit the person that supports the process since they spend more and more of their time supporting their various processes and less and less time doing more value-added work. Approaching your boss to ask to cross-train someone else on how to support this process is generally something that goes over very well-- your manager gets rid of a single point of failure, your coworker gets some additional responsibilities, you get a bit more freedom. If it happens to make it easier for you to leave, so much the better for you.



If you do leave, offering to continue to help out as a paid consultant is not blackmail, it's the normal course of business. Presumably, you only support this software now because you're being paid to do so as part of your employment. It would only make sense that to continue to support it, you'd need a continued business relationship in the form of a consulting engagement. If you are leaving the system reasonably well documented and you've offered to cross-train someone else, no reasonable person will have hard feelings if you offer to stay on as a consultant to ease the transition.






share|improve this answer



























    up vote
    2
    down vote













    You can obviously choose any of the above options, but my recommendation would be a combination of #2 and #3.



    Constructing clear guidelines for potential future support of this system isn't blackmail, especially if you've done your due diligence to train another employee on the system. Rather, you are helping your employer by giving them a clear way to understand potential future cost of ownership of the system. The perception, of course, is all about how you deliver your plan.



    Obviously this will be easiest if you have the type of job where you can reasonably and openly plan for your exit with a long notice period. If not, you may need to frame the cross-training of this other employee purely as a "hit-by-truck" insurance policy, which again, is helping your employer, not hurting them.



    Finally, one of the best ways to show your above-board intent is to document the system as it stands today, as clearly and concisely as possible. This gives them even more flexibility in the future to choose to tough things out internally or go to you for consulting support.






    share|improve this answer



























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes








      up vote
      5
      down vote













      Is there documentation for the system? If there is a piece of code that is critical to the functioning of the business, that code really ought to be documented well enough that a competent developer could come in off the street and figure out how to support it. If there are things that hiccup regularly, there should be operations documentation that helps someone troubleshoot at least the common failure modes. If there is no documentation, it should be relatively easy to get authorization to create it on the general "what if I get hit by a bus" principle.



      Businesses generally dislike having a single point of failure so they dislike having processes that only one person can support. It also tends to limit the person that supports the process since they spend more and more of their time supporting their various processes and less and less time doing more value-added work. Approaching your boss to ask to cross-train someone else on how to support this process is generally something that goes over very well-- your manager gets rid of a single point of failure, your coworker gets some additional responsibilities, you get a bit more freedom. If it happens to make it easier for you to leave, so much the better for you.



      If you do leave, offering to continue to help out as a paid consultant is not blackmail, it's the normal course of business. Presumably, you only support this software now because you're being paid to do so as part of your employment. It would only make sense that to continue to support it, you'd need a continued business relationship in the form of a consulting engagement. If you are leaving the system reasonably well documented and you've offered to cross-train someone else, no reasonable person will have hard feelings if you offer to stay on as a consultant to ease the transition.






      share|improve this answer
























        up vote
        5
        down vote













        Is there documentation for the system? If there is a piece of code that is critical to the functioning of the business, that code really ought to be documented well enough that a competent developer could come in off the street and figure out how to support it. If there are things that hiccup regularly, there should be operations documentation that helps someone troubleshoot at least the common failure modes. If there is no documentation, it should be relatively easy to get authorization to create it on the general "what if I get hit by a bus" principle.



        Businesses generally dislike having a single point of failure so they dislike having processes that only one person can support. It also tends to limit the person that supports the process since they spend more and more of their time supporting their various processes and less and less time doing more value-added work. Approaching your boss to ask to cross-train someone else on how to support this process is generally something that goes over very well-- your manager gets rid of a single point of failure, your coworker gets some additional responsibilities, you get a bit more freedom. If it happens to make it easier for you to leave, so much the better for you.



        If you do leave, offering to continue to help out as a paid consultant is not blackmail, it's the normal course of business. Presumably, you only support this software now because you're being paid to do so as part of your employment. It would only make sense that to continue to support it, you'd need a continued business relationship in the form of a consulting engagement. If you are leaving the system reasonably well documented and you've offered to cross-train someone else, no reasonable person will have hard feelings if you offer to stay on as a consultant to ease the transition.






        share|improve this answer






















          up vote
          5
          down vote










          up vote
          5
          down vote









          Is there documentation for the system? If there is a piece of code that is critical to the functioning of the business, that code really ought to be documented well enough that a competent developer could come in off the street and figure out how to support it. If there are things that hiccup regularly, there should be operations documentation that helps someone troubleshoot at least the common failure modes. If there is no documentation, it should be relatively easy to get authorization to create it on the general "what if I get hit by a bus" principle.



          Businesses generally dislike having a single point of failure so they dislike having processes that only one person can support. It also tends to limit the person that supports the process since they spend more and more of their time supporting their various processes and less and less time doing more value-added work. Approaching your boss to ask to cross-train someone else on how to support this process is generally something that goes over very well-- your manager gets rid of a single point of failure, your coworker gets some additional responsibilities, you get a bit more freedom. If it happens to make it easier for you to leave, so much the better for you.



          If you do leave, offering to continue to help out as a paid consultant is not blackmail, it's the normal course of business. Presumably, you only support this software now because you're being paid to do so as part of your employment. It would only make sense that to continue to support it, you'd need a continued business relationship in the form of a consulting engagement. If you are leaving the system reasonably well documented and you've offered to cross-train someone else, no reasonable person will have hard feelings if you offer to stay on as a consultant to ease the transition.






          share|improve this answer












          Is there documentation for the system? If there is a piece of code that is critical to the functioning of the business, that code really ought to be documented well enough that a competent developer could come in off the street and figure out how to support it. If there are things that hiccup regularly, there should be operations documentation that helps someone troubleshoot at least the common failure modes. If there is no documentation, it should be relatively easy to get authorization to create it on the general "what if I get hit by a bus" principle.



          Businesses generally dislike having a single point of failure so they dislike having processes that only one person can support. It also tends to limit the person that supports the process since they spend more and more of their time supporting their various processes and less and less time doing more value-added work. Approaching your boss to ask to cross-train someone else on how to support this process is generally something that goes over very well-- your manager gets rid of a single point of failure, your coworker gets some additional responsibilities, you get a bit more freedom. If it happens to make it easier for you to leave, so much the better for you.



          If you do leave, offering to continue to help out as a paid consultant is not blackmail, it's the normal course of business. Presumably, you only support this software now because you're being paid to do so as part of your employment. It would only make sense that to continue to support it, you'd need a continued business relationship in the form of a consulting engagement. If you are leaving the system reasonably well documented and you've offered to cross-train someone else, no reasonable person will have hard feelings if you offer to stay on as a consultant to ease the transition.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Mar 24 '15 at 20:08









          Justin Cave

          34.8k9112136




          34.8k9112136






















              up vote
              2
              down vote













              You can obviously choose any of the above options, but my recommendation would be a combination of #2 and #3.



              Constructing clear guidelines for potential future support of this system isn't blackmail, especially if you've done your due diligence to train another employee on the system. Rather, you are helping your employer by giving them a clear way to understand potential future cost of ownership of the system. The perception, of course, is all about how you deliver your plan.



              Obviously this will be easiest if you have the type of job where you can reasonably and openly plan for your exit with a long notice period. If not, you may need to frame the cross-training of this other employee purely as a "hit-by-truck" insurance policy, which again, is helping your employer, not hurting them.



              Finally, one of the best ways to show your above-board intent is to document the system as it stands today, as clearly and concisely as possible. This gives them even more flexibility in the future to choose to tough things out internally or go to you for consulting support.






              share|improve this answer
























                up vote
                2
                down vote













                You can obviously choose any of the above options, but my recommendation would be a combination of #2 and #3.



                Constructing clear guidelines for potential future support of this system isn't blackmail, especially if you've done your due diligence to train another employee on the system. Rather, you are helping your employer by giving them a clear way to understand potential future cost of ownership of the system. The perception, of course, is all about how you deliver your plan.



                Obviously this will be easiest if you have the type of job where you can reasonably and openly plan for your exit with a long notice period. If not, you may need to frame the cross-training of this other employee purely as a "hit-by-truck" insurance policy, which again, is helping your employer, not hurting them.



                Finally, one of the best ways to show your above-board intent is to document the system as it stands today, as clearly and concisely as possible. This gives them even more flexibility in the future to choose to tough things out internally or go to you for consulting support.






                share|improve this answer






















                  up vote
                  2
                  down vote










                  up vote
                  2
                  down vote









                  You can obviously choose any of the above options, but my recommendation would be a combination of #2 and #3.



                  Constructing clear guidelines for potential future support of this system isn't blackmail, especially if you've done your due diligence to train another employee on the system. Rather, you are helping your employer by giving them a clear way to understand potential future cost of ownership of the system. The perception, of course, is all about how you deliver your plan.



                  Obviously this will be easiest if you have the type of job where you can reasonably and openly plan for your exit with a long notice period. If not, you may need to frame the cross-training of this other employee purely as a "hit-by-truck" insurance policy, which again, is helping your employer, not hurting them.



                  Finally, one of the best ways to show your above-board intent is to document the system as it stands today, as clearly and concisely as possible. This gives them even more flexibility in the future to choose to tough things out internally or go to you for consulting support.






                  share|improve this answer












                  You can obviously choose any of the above options, but my recommendation would be a combination of #2 and #3.



                  Constructing clear guidelines for potential future support of this system isn't blackmail, especially if you've done your due diligence to train another employee on the system. Rather, you are helping your employer by giving them a clear way to understand potential future cost of ownership of the system. The perception, of course, is all about how you deliver your plan.



                  Obviously this will be easiest if you have the type of job where you can reasonably and openly plan for your exit with a long notice period. If not, you may need to frame the cross-training of this other employee purely as a "hit-by-truck" insurance policy, which again, is helping your employer, not hurting them.



                  Finally, one of the best ways to show your above-board intent is to document the system as it stands today, as clearly and concisely as possible. This gives them even more flexibility in the future to choose to tough things out internally or go to you for consulting support.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Mar 24 '15 at 20:03









                  phoebus

                  1,17689




                  1,17689












                      Comments

                      Post a Comment

                      Popular posts from this blog

                      What does second last employer means? [closed]

                      Image
                      Clash Royale CLAN TAG #URR8PPP .everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0; up vote -3 down vote favorite Say, for example I have worked in the following companies, Company A => 2010 - 2011 Company B => 2011 - 2012 Company C => 2012 - Till Date Company D => Have offer Now assume Company D is asking to submit documents from my second last employer. So from the list of companies given, which company would be qualified as second last employer? software-industry employer share | improve this question asked Aug 10 '14 at 5:16 Rajaprabhu Aravindasamy 559 1 6 13 closed as off-topic by Jim G., jmort253 ♦ Aug 11 '14 at 1:58 This question appears to be off-topic. The users who voted to close gave this specific reason: "Questions seeking advice on company-specific regulations, agreements, or policies should be directed to your manager or HR department. Questions that address...
                      Read more

                      List of Gilmore Girls characters

                      Image
                      The season three cast—(Back row): Lane, Michel, Paris, Emily, Richard, Sookie, Miss Patty, Kirk; Front row: Jess, Luke, Lorelai, Rory, Dean This is a list of characters for the comedy-drama television series Gilmore Girls . Contents 1 Main characters 1.1 Lorelai Gilmore 1.2 Rory Gilmore 1.3 Sookie St. James 1.4 Lane Kim 1.5 Michel Gerard 1.6 Luke Danes 1.7 Emily Gilmore 1.8 Richard Gilmore 1.9 Paris Geller 1.10 Dean Forester 1.11 Jess Mariano 1.12 Kirk Gleason 1.13 Jason Stiles 1.14 Logan Huntzberger 2 Major recurring characters 2.1 Christopher Hayden 2.2 Jackson Belleville 2.3 Mrs. Kim 2.4 Tristin DuGray 2.5 Max Medina 2.6 Taylor Doose 2.7 Dave Rygalski 2.8 Marty 3 Recurring characters 3.1 Stars Hollow 3.2 Chilton 3.3 Yale 3.4 Other 4 Notable guest stars 5 Unseen characters 6 Notes 7 References Main characters Actor Character Appearances Season 1 Season 2 Season 3 Season 4 Season 5 Season 6 Season 7 A Year in the Life Lauren Graham Lorelai Gilmore...
                      Read more

                      Confectionery

                      Image
                      Prepared foods made with a lot of sugar or other cabohydrates "Sweetmeat" redirects here. For the racehorse, see Sweetmeat (horse). Not to be confused with Sweetbread. This Kransekake is a traditional Scandinavian baker's confection. Confectionery is the art of making confections , which are food items that are rich in sugar and carbohydrates. Exact definitions are difficult. [1] In general, though, confectionery is divided into two broad and somewhat overlapping categories, bakers' confections and sugar confections. [2] Bakers' confectionery, also called flour confections , includes principally sweet pastries, cakes, and similar baked goods. Sugar confectionery includes candies ( sweets in British English), candied nuts, chocolates, chewing gum, bubble gum, pastillage, and other confections that are made primarily of sugar. In some cases, chocolate confections (confections made of chocolate) are treated as a separate category, as are sugar-free versions of ...
                      Read more