How to turnover a utility which I manage [duplicate]

Question

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?

Answer 1

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.

Answer 2

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.