Preparing for retirement [closed]

Question

I'm going to retire within the next year or two, and I'm wondering what I can do to minimize any negative impact on my company. They have been good to me (in some ways, at least), so I want to help, if I can.

I have almost 40 years experience in one particular branch of the software industry, and I'm a recognised authority in my field. No-one knows all the things I know, but a combination of a few other people could probably cover the technical areas adequately, so no big problems there, maybe.

If I have any unique capability, it may be that I seem to be good at explaining complex concepts and situations, and making them understandable (and credible) to non-experts. For example, I am called upon, from time to time, to explain to a customer why we can't do the impossible thing they're asking. Or, I am asked to explain why our products/solutions are better than those from our competitors, which wins us big deals, sometimes. I don't know if I can teach this. I'm not even sure how I learned to do it.

My management tell me to "mentor a replacement", but they have no specific ideas about who this should be, or how I should help the person. Maybe this indicates that they don't care very much, in which case maybe I shouldn't care, either.

Any thoughts on this? Should I care? If so, have y'all seen examples of effective transition/succession programs? What do they involve?

Answer 1

It's really managements problem to ensure you leaving does not impact badly on the company. Your main responsibility is to handover in whatever fashion they want and focus on the big change in life you're about to start.

Your 'special skills' seem to come from experience, this isn't something it's possible to teach I would think. They can always call you in from retirement and pay you to help out if they need to.

As far as plans go, this is what works for me. A handover document is prepared which contains a break down of all duties that go with the role. All passwords and things like that, ip addresses whatever. This is not a transfer of all your knowledge, it's a reference for your successor. It should document all procedures that are relevant and importantly, any workarounds and modifications that you have made up over the years.

Then when the time comes for you to leave, you work with your successor for a few days, using this document as a baseline and modifying it as need be until you actually leave. This pretty much gives them a nice overview of everything and a reference to fall back on. From time to time I've been called to ask clarification on something, but very rarely have they needed me to go back in for anything. So long as the document is thorough it should go smoothly.

It doesn't take long to create this document, I'm assuming you don't have a million different roles. In the past it has taken me a couple of hours, to a day or two at most, with a bit of tweaking as I recall something left out. Possibly I have even spent more time formatting it for prettiness and putting logo's on and suchlike than actually composing the doc.

Answer 2

If possible, checkout a open source product called twiki or a similar product. Check with your company , if you can use it to document everything you know. It is searchable by topics or keywords. You can use know how to write articles which might seem complex and try to explain and tag them with keywords. This way it stays as knowledge base and is accessible to anyone. Make sure that credit is attributed to you ( if you care ).

It is very simple to use with many features.

Of course you can also try to mentor someone. The risk is they leave

Answer 3

Perhaps an example from the perspective of a company that didn't plan well would be instructive? I started working for my current company about 3-1/2 years ago as a developer on a team of two working on internal tools. We had another developer who worked solely on customer facing software who planned to retire. This developer had worked for years with no oversight, no code reviews, no test team, no unit tests, just toss it over the fence, our users were our testers (and still are).

As a result, their code was without comments, has an incredible number of useless dependencies (literally thousands) and is all but impenetrable. Three months prior to their retirement they began looking for a replacement who was eventually found. This poor soul never stood a chance and quit several months after the other person retired having accomplished nearly nothing other than moving the source from VSS to SVN in the interim. They've never hired a replacement.

They farmed the code out to one of our sister companies because they were supposed to handle customer facing code. Except they didn't have the original computer to work with that had all the dependencies that never got checked in (that now sits on my desk).

Eventually the code ended up back in our laps because the entire company depends on two of the pieces and modifications and maintenance were required. It took over a week just to resolve dependencies on the original machine, another week to be able to check out, build and run from my dev box. For quite some time, we could only get both pieces to build on my machine, we couldn't get one of them to build on my colleague's machine. A year later, it still takes weeks to do what should take a few hours even after lots of refactoring. We have plans to rewrite it from scratch and make it easy to add new devices as they come down the pike, but it's very difficult to find the time.

So, after my long story, my advice to you is to make sure your code is well documented with comments (comments explaining your thinking are golden), make sure it has no unresolved dependencies (it can be checked out of your repository onto a different machine with no problems), make sure your dev & test teams are aware of places where you believe there are weaknesses. Hold code reviews to get your successors up to speed on your code while you still have time.